This is almost certainly going to be proprietary, so it's nothing to hold your breath over.
Ekioh makes enterprise software for set-top boxes. They do know their browser rendering, though: they stripped Webkit down to have a 24mb memory footprint.
Nevertheless perhaps it has a chance to conquer the market if it's so good otherwise. I love free software but have to admit a browser (or whatever an app) doesn't have to be open-source for this.
I honestly don't know what you might be thinking of Chrome doing that 'enables' AMP. If you said Google Search enabled AMP, by only allowing AMP documents in the carousel for example, I would agree. But I can't think of any Chrome-specific features that AMP depends on, and I believe Google (and Bing) currently serve AMP to Firefox, Safari, Edge, etc.
As opposed to having Chrome, which contributes to Google's ownership of the whole internet? Google does what it wants and developers write for Chrome. Users of Firefox find websites that won't work because someone used some Chrome extension to the spec.
People writing software are no match for behemoth.
At the very least Chrome allows forking (and has happened in practice multiple times), so a competitor need not start from scratch. That's will always be an insurance.
There's hardly any point forking if most or all websites are tested for Chrome and its idiosyncrasies, and don't work well on other browsers. We have seen that playing out for sometime.
It means we can’t end up in an IE6 scenario, where the caretaking company loses interest in developing the browser, and we are all stuck using old technology forever.
Someone can simply fork it, with all its idiosyncrasies, then build new versions with new features.
Do you want a browser that natively supports a language other than JavaScript? Chromium is a great starting point.
Well, I think the argument was more about Webkit, then Chrome itself. Even flow here does not use a JS engine written from scratch - they use SpiderMonkey.
PS: As a webkit-based Chrome alternative, Brave browser does really well.
IE6 was the best browser by far when it was released.
We got IE6 partly because of that: why to work on something, that is the best in the market. So the team was disbanded.
When alternatives started to appear, one of them, and quite popular in some areas was Opera–also closed-source browser. Despite being closed-source they cared a lot about the Web Standards and many of the biggest advocates worked for Opera.
People can run legacy open-source code, too. I fail to see how open-sourcing IE would have solved the old versions. For a better example, look at python 2.7. Open-source legacy code every one's stuck with, drawn-out deprecation dates, etc. Old Java versions are the same thing.
https://twitter.com/_Piers_/status/991328398910816256 says it's actually more than a year old. There is no download link on the OP, so I guess it's safe to assume it's only available to people who pay for their enterprise needs.
So, sounds interesting, but not for the public masses.
I was indeed wondering the same: a new render engine seems like a huge and risky investment (even Microsoft gave up on the existing one they have, that says something). If it really is from scratch, it probably just supports only the most popular features, which would cut complexity and give a large performance boost by itself.
Alternatively: Chrome 1.0 was also super fast compared to the competition. And I remember switching from a full browser on Android to my custom browser that was like 10 lines of code around a webview element, which was really an order of magnitude faster. If they modified an existing render engine and wrote their own browser UI, that could also deliver this speed boost.
So this seems relatively doable to me, but you get fewer features.
Let's see if they make this available for a broad audience and if, in five years when they accumulated all the features, it's still faster.
I was curious, did some research. They do mention Servo in some places[0][1]. They also have their own white papers[2][3], & blog posts outlining their approach, things like how to make borders with triangles[4]. Fun stuff!
Quote: Back in 2012, Mozilla’s Servo project had started hitting headlines about multithreaded, parallel algorithms, and we decided to see if we could do similar, initially targeting our historic market of STBs[0]
Quote: Some of our early thinking was shaped by the parallel web page layout research done by Meyerovich & Bodík. That research also influenced the Servo project which was started by the Mozilla foundation around the same time that we started developing our multithreaded browser.[1]
The Mozilla Gfx blog regularly posts updates. They have been porting subsystems from servo to firefox, and making substantial progress on a regular basis.
VR is only part of the focus, we're still working towards a general purpose browser, it's just a slow and long process.
Webrender is being actively worked on and is in the final stages of integration into Firefox (I believe it's enabled by default for some combinations of GPU and OS already). Servo's experimenting with a new layout system written from-scratch to be modular as well, and that's making good progress.
(We're rewriting the layout system because the original one, while it proved that parallel layout was doable, wasn't very maintainable/extensible given that it was written through experimentation while the language itself was changing a lot. We now know how to do parallel layout, and writing a clean, modular, maintainable system will enable us to fill in all the missing features)
Pretty interesting. Conventional wisdom is that the web standards have become so complicated that it's prohibitively difficult to introduce a totally new browser that fully supports modern CSS and JS. Sounds like this one does.
Naming could be better or more differentiated -- "Flow" is already used in the closely related space of front-end development and javascript (flow typing).
It doesn't matter. There's thousands of basic words occupied by some more or less relevant Javascript tool or framework. Don't let that get in the way of naming your products.
As well as a FTP app for macOS, Sharing service for the Opera browser, Microsoft Flow, Samsung Flow and so on. While it's a word used all over the place, i would try to name it to something more ”unique”.
Will it have its lunch eaten by tools and techniques for lightweight web apps on Webkit/Quantum? Svelte made a headstart making 200k laggy Webkit devices snappy again while these guys will be selling proprietary licenses.
Frameworks like Svelte focus on reducing the time spent running JavaScript. This project focuses on reducing the time spent on layout and rendering.
Theoretically they'd complement each other, but in practice I imagine UIs for super-resource-constrained set-top boxes are already written in pretty efficient JavaScript.
These things are actually pretty related: JS isn't particularly slow as a language; it only gets slow on the web because every time JS code touches the DOM/CSS a part of layout and style needs to be recomputed.
I don't think there's that much to improve with current browsers anymore. 8 years ago maybe. Now you have web workers with shared memory, typed arrays, GPU acceleration for canvas and CSS, web assembly with SIMD. It's already possible to utilise all the cores and GPU in 2D. Not even mentioning 3D WebGL and incoming WebGPU. Websites are fast enough already(with ad blocker).
I believe that document.write prevent a lot of parallelism.
Also as always, SIMD are underutilized.
There is also transactional memory, heterogeneous computing, SYCL, etc...
"Who's using document.write for anything these days?"
It doesn't matter if anybody use it, someone could use it, as such browser must adapt to this possibility and be performance constrained.
"what do you mean document.write prevents parallelism?"
I don't remember the details but it force some critical browser operations to be sequential.
Ekioh makes enterprise software for set-top boxes. They do know their browser rendering, though: they stripped Webkit down to have a 24mb memory footprint.