I'm excited about there being another browser engine.
I think the general idea that "writing an engine for the web is impossible in 2020" is dangerous. It can only ever lead to less diversity: that idea is a sure road to a chrome-only-web, which is far worse than the dark-IE6-ages.
I truly hope Flow finds its niche or sweet spot. Maybe embedded is that, maybe micro-computers. I truly hope a big name gets behind it, though. Maybe a game console or other OEM that needs a built-in browser. Maybe the Chino-West-economic war will force a large asian phone os to build their own browser. We'll see.
But there really is need for another browser engine. If alone to prove that writing a new one from scratch is possible in 2020.
I just imagined an alternate reality, where the kernel came packaged with its own deeply-integrated 'suggested' browser. Linux had become everything it set out to destroy.
I might be wrong (I've only used Linux since 2001) but I never felt Linus or Linux set out to destroy something but rather first to try out what was possible and later to enable more and more.
> I think the general idea that "writing an engine for the web is impossible in 2020" is dangerous.
I'm not sure what you mean by this sentence. Are you saying it would be dangerous if writing a new engine in 2020 were impossible (agree) or are you saying that making such a statement is dangerous (hard disagree).
Making a new engine in 2020 is hard. Making a new engine that becomes a sustainable, maintainable project in the medium term MAY BE impossible (Flow looks amazing but I imagine funding and maintaining it long-term will be an immense challenge). Discussing this fact, and the reasons that it is so challenging is important if we hope to avoid the dangers of a monoculture.
The statement being nothing more than Microsoft didn't want to spend $$ on their own browser engine.
Just because Microsoft has a ton of money it doesn't mean that every project they work on and every team in the company have unlimited budget.
And even if that was the case for their browser engine team, the project might stop for other reasons too - e.g. internal politics, changes in focus/goals, etc.
It isn't like Microsoft (or any big company really) doesn't drop projects that people wouldn't expect them to drop.
How about Opera, a company who's main product is a browser, who had expertise in building fast, featureful, innovative and compliant browser engines since before Internet Explorer 1.0 came out, opted to abandon the project and adopt Blink stating the maintenance complexity as their reasoning.
Not as big a company as MS/Apple, but certainly more established than Ekioh sofar.
I really hope Ekioh can succeed here long-term where others haven't.
I think you're thinking of Opera Mini, which was a (set of?) thin client(s) that ran on feature phones and rendered a proprietary lightweight binary transport (OBML) that those phones could handled. OBML was generated on a proxy server running a fully featured web rendering engine (which may have been Presto).
Opera's Presto engine was mainly used in their desktop and smartphone browsers. It was not used directly in Opera mini on feature phones.
> Raise of cheap full featured ARM CPUs made it obsolete.
Not sure what this means. How would ARM make a browser obsolete?
ARM Made opera mini obsolete because there were no more users. The people that have a phone it runs on don’t want a browser or they’d get a smartphone, the people with a smartphone don’t want it because they can use a real browser
Opera was trying to make money in a commoditized environment.
Honestly, i do not believe that Flow has much of a future as a proprietary product for providing a browser engine no matter how good it supposedly is - even Sciter presents itself as a UI engine, not a browser engine.
However that doesn't mean writing a new browser engine is impossible, it only means that it doesn't make much economic sense for a company to do so. Those two are not the same thing.
> Opera was trying to make money in a commoditized environment.
From what I can tell, Ekioh appear to be doing the same[0]
> that doesn't mean writing a new browser engine is impossible, it only means that it doesn't make much economic sense for a company to do so. Those two are not the same thing.
This is basically what I said in my first comment above: it's always technically possible, but is it practically possible. One needs a certain small amount of economic support to continue any project (no matter how small) these days. Whether it's feasible via donations/etc. or whether some kind of commercial setup is required isn't really super-relevant. The only question here is: if it's the former, can the income support employing devs to work on it, or can voluntary developer contributions maintain the project long term (for which you typically need a large community, with which you typically get further scaling & cost concerns).
It's notable also that Flow is not open source, so Opera is actually a very good comparison here (and much of the above donation/volunteer-based thoughts are not options here).
They have forced every iOS/iPadOS user to use their engine, and therefore force all web developers to adapt to them.
They aren't interested in keeping up because they don't gain anything from it and they don't loose a lot by lagging behind.
Apple is more than capable to implement stuff like push notifications but that would compete with the app store where they make money and by disallowing others from bringing a browser to iOS they don't need to.
Same here for Twitter, Mastodon, the local news (push), weather (push and geo), public transport (push, geo and backround-service) and so on.
There are apps for all of them, but especially the apps in the long tail (local news, local public transport) are bad (as in: it is clear they are budget-restrained). I don't want to fill my phone with hardly-used, crappy apps, when a link to a website will suffice perfectly.
Dear god no. These should never have been a thing in fact. Especially for untrusted websites. I should make a website that abuses them just to make my point. Their only value is getting an eyeball back on to the ads. This is one thing Apple did right.
What are you talking about? "Untrusted websites" can't send push notifications. Being able to send push notifications requires a browser-level popup dialog that the user explicitly has to opt into, for each individual website. There's no drive-by API that lets you spam random website visitors with push notifications.
I don't see how you could "make a website that abuses them just to make [your] point." No one would bother enabling notifications for your abusive website, and even if you managed to convince them to do it, they'd just turn them off for your abusive website as soon as you started spamming them.
Yup.
On my Android, each of those push-notifications come with a "configure notifications" which lets you turn them off quickly and easily.
Ironically, I use that feature for installed apps most (you're a banking app, stop bugging me with unrelated news!) and hardly ever to turn off a accidentally allowed web-notification.
The same argument is true for push notifications in native apps. For both you can accept or deny them, and some apps (like chat, email, todo) that primarily display text and give you a notification when something happens could just aswell be a web app instead.
Web push notifications does not mean any random site can spam you just because you visited it once. You have to explicitly accept it.
Same deal. It doesn't really make much economic sense for a company to make their own browser engine unless they want to leverage it for something else.
But that is not the same as saying that making a new browser engine being impossible in 2020.
I don't think it's impossible, I think it's a lot of work though. Especially for one person, it would take the right person. I could see someone like Walter Bright doing it (he created D originally by himself and other compilers).
I don't think I have the energy to do the entire DOM myself, and implement a JS engine, and CSS, and so on... Plus all the nuance of image rendering (even if you use third party libraries for this, you gotta figure out which ones to use and ensure you're doing so correctly and securely).
Set a lower standard though? HN is arguably a good website with just enough of each tech and high signal to noise ratio. How difficult to make it work in a new browser? Who cares if it renders the Facebook wall misaligned.
> In the meantime, some previously working sites have stopped working due to improvements in their content, for instance, Amazon now requires Web Cryptography to log in. This is a feature currently in progress.
I thought these paragraphs were particularly interesting:
> When I have spoken to them, their approach has been significant: they've chosen what features to prioritize based on a chosen major website, and then attempted a complete implementation of those features. An example of this is that they only implemented HTMLTableElement in the recent past, despite having supported much of the HTML DOM for a lot longer.
> Historically, many attempts at new browser engines have started by trying to systematically implement features per specification, only to find that no interesting site is yet functional even when the majority is done. By being vastly more selective and only implementing features when needed, they are undoubtedly cutting out many obscure legacy features unlikely to be used on any major site today.
> We have chosen to release on just one platform initially, and there are a couple of reasons why. The Raspberry Pi’s hardware is largely fixed – you can’t swap the CPU or GPU. Variations in hardware could cause us to get distracted by issues that really shouldn’t be a priority right now.
I like them already. Imagine if any of the crashy FOSS video editors had taken this route.
Are you suggesting that video editors only support Raspberry Pi? Or are you suggesting that they only support Intel Core 2 Duo + NVIDIA GT 640?
I don't get what you're suggesting. A video editor needs good hardware, either you can go with mac, or PC. On PC, you can not really lock yourself into one model, even the developers are gonna have a variety of different hardware.
> We have chosen to release on just one platform initially, and there are a couple of reasons why. The Raspberry Pi’s hardware is largely fixed – you can’t swap the CPU or GPU. Variations in hardware could cause us to get distracted by issues that really shouldn’t be a priority right now.
This (provided the Raspberry Pi's poularity, affordability and power - surely it would be of no use without these) actually is an extremely cool feature. You can engineer OSes and entire solutions without caring about compatibility issues now. Like in the good old days when people would invent entire HW+OS platforms like NeXT and Amiga, but now you have the HW part done for you.
Ah too bad, that breaks it for me. I aim to have the same browser on all my platforms, obviously they're not there yet as it runs only on the Pi 400 now, but I doubt they will ever support things like FreeBSD officially (even Firefox doesn't!)
So it won't be for me but nevertheless more competition in the rendering engine area is welcome.
We've been taking open source for granted for the past decade. As open source has proven difficult to monetize, we may be seeing a return to proprietary closed source software.
Whether this is a good or a bad thing depends on how it plays out. If software like Flow conforms to standards and offers a better experience, battery life, privacy, etc then it might work out well. An open infrastructure with a marketplace to pay for desired features will benefit us all.
The bad scenario is that the web continues to fracture into proprietary components. While a web not dominated by Chrome seems almost unimaginable today, it wasn't that long ago that sites that only worked in Internet Explorer were commonplace. If Flow actually becomes the dominant web browser and Flow-only websites ever become the norm, we'll all be worse off for it. That really is a far off scenario, so for now, having Flow as an extra player on the web is probably a good thing.
Flow's model isn't directly as an application, I suspect, but rather a browsing engine. Since the article mentions set-top boxes, that means deploying to fixed hardware which is usually the case for things like integrated browsers on TVs, consoles, and digital billboards or the like. And possibly video game UIs, like Coherent Labs's software.
So presumably one would license the engine to use in their device or game and integrate that cost on the end product, rather than a user explicitly paying $X to Ekioh.
One possible approach here could also be dual-licensing under both something like the GPLv3 and offering commercial licenses. That way you get the advantages of being FOSS, but also become able to sell the application to system builders.
Could this vendor beat Firefox and Chromium by disregarding legacy and edge cases? Examples from thin air: parser can be far simpler if it fails on any syntax errors in HTML, CSS and JS; hrow a fit if certain layouts or JS are resource hungry, execute preshipped Spidermonkey bytecode directly instead of parsing JS.
I'm hoping so much for something like that, personally I hope for a variation of the asm.js playbook: make sure code that follow the guidelines get
huge rewards.
Not really. People rarely if ever choose a browser because of their rendering engine these days. All current browsers seem to be limited by actual network speed than anything else.
E.g.: Apple and Google always tout how safari and chrome are fast, and maybe they are, but the truth is that the upstream from most websites is really slow, so the actual rendering speed does not matter.
Yeah about this, I never 'got' why Microsoft expected people to jump on Edge all of a sudden when they rebased it on Chromium.
Basically they admitted they can't make a decent browser that people want, then they re-skin someone else's work and suddenly expect us to want it more than the one they copied? How does that even make sense. Who would pick a mod kit over a real Ferrari.
Apart from people not caring about the engine, Microsoft has a very bad history in the browsing arena which is why I (and many others) don't trust them anymore. I don't want them to become big again in the browser market. We already know what happens then: years of stagnation, platform lock-in, no interest in security. And no, they haven't changed their tune, the same is still happening with MS Office where they still own a de facto monopoly.
Of course what plays into this for me as well is that I don't like Chrome either so I stay with Firefox anyway. But the pressure Microsoft are exerting at work to move everything to Edge is annoying.
True but compatibility was never really an issue AFAIK. I didn't use the old edge much but I knew some staunch supporters and they never complained about it :)
I always use Firefox and even though it's not perfect I've never seen it break a site unless it's done on purpose by the site itself (like Apple's business portal that refuses to support Firefox).
I realized recently that what I really want, even more than a new browser engine, is a browser that's highly portable to new platforms. Something like ffmpeg, or maybe Retroarch, which can be compiled for freeDOS or a PowerMac or Haiku if you'd like—sometimes with different features enabled, but always with enough to be useful. If someone developed a brand new platform, these projects would be relatively easy to get running.
Perhaps it's just my particular love of weird and new (and old) platforms, but my greatest fear isn't so much being stuck with a single engine as being struck on a small set of mainstream platforms in order to use the engine. I don't think it's a coincidence that the Switch and PlayStation 5 lack a user-exposed web browser; sure it would be a nice feature, but it's not worthwhile for Sony and Nintendo to keep up to date.
If we'd had today's web browsers in 2007, and Apple didn't already lead the Webkit project, would Steve Jobs have been able to create the iPhone, with a first-class web browser as a key selling point? A web browser is the single most essential application for modern life. What future innovations are we missing out on?
The Switch does have a usable web browser, it's just difficult to access. The eShop and some online features run on it, but it can be accessed and used as a standalone browser.
Sorry, I should have said user-exposed/user-visible (and I've edited). It's the same situation with the PS5.
Clearly, Nintendo doesn't consider it good enough for general use. And having played with it, I very much agree—it doesn't work on lots of sites and likes to crash a lot. I assume the PS5's browser is the same.
I'd certainly agree there. The eShop applet runs on it, and is easily the worst-performing part of the Switch - much slower and laggier than pretty much any site on the modern web.
Nice, IMO browsers have been the Achilles' heel in getting proper desktop experience out of RPi (not incl. 8GB variant) and other SBCs. I presume it has to with lack of optimizations in the browsers w.r.t to mainline Linux on ARM? As similar low spec (4GB) intel celeron fanless x86 Chromebook could offer much smoother browser experience.
Perhaps a browser such as Flow built for embedded hardware could address that.
I think the general idea that "writing an engine for the web is impossible in 2020" is dangerous. It can only ever lead to less diversity: that idea is a sure road to a chrome-only-web, which is far worse than the dark-IE6-ages.
I truly hope Flow finds its niche or sweet spot. Maybe embedded is that, maybe micro-computers. I truly hope a big name gets behind it, though. Maybe a game console or other OEM that needs a built-in browser. Maybe the Chino-West-economic war will force a large asian phone os to build their own browser. We'll see.
But there really is need for another browser engine. If alone to prove that writing a new one from scratch is possible in 2020.