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.
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.