Hacker News Reader

Comment by berkes | Hacker News Reader

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.

View on HN

I'm also holding hopes that something will rise from the ashes of the Servo codebase. It's hateful to see something with promise go to waste.

Iirc the Linux Foundation picked it up.

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.

Of course! Linux is free to anyone, even Steve Ballmer if he has a change of heart. My comment was very much intended as tongue-in-cheek.

That brings "magnificent monolith" to an entire new level: a kernel with built-in javascript interpreter, DOM, HTML and CSS renderer.

Sounds a bit like what Mozilla had in mind with their mobile OS back in the days.

A decent amount of the servo work ended up Firefox proper already.

They merged in the CSS work (stylo) a while back and Webrender is now the default 2d engine.

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

Microsoft, with the almost unlimited $$ they have, decided against their own browser engine. That made quite a statement.

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 Apple? They have their own but either aren't interested or not capable of keeping up with chrome.

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.

> push notifications

Is this really just for money? On Android I found it insufferable that websites in tabs I had closed could still pop something up on my lock screen.

Web push can pop up messages if the browser is closed and your phone's screen is off. It's well supported on most android devices.

As a user I want them in sites like Slack so I never need to install the Slack app.

> so I never need to install the Slack app

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.

I use web-apps for anything possible. Via https://f-droid.org/en/packages/com.tobykurien.webapps/ and https://progressiveapp.store/pwas

> push notifications

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.

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.

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.

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.

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.

Main selling point of Presto Opera engine was it could run on any CPU. Often on poor feature phones, without MMU, floating point arithmetic...

Raise of cheap full featured ARM CPUs made it obsolete.

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.

Can we agree it's impractical, even if technically possible?

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

[0] https://www.ekioh.com/company/#partners

Ekioh is essentially a competitor of Vewd, the former TV/devices part of Opera.

I meant that 'writing a new engine is impossible in 2020' is dangerous. I fear it is true. But apparently flow is proving it wrong.

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

I think web standards evolve faster than a single person can implement them.

They are slow to be adopted though, the fact we still got things like Babel is tribute to this simple fact.

> the energy to do the entire

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.

OOT: it has been years I since the last time I read/hear about Facebook wall

> But there really is need for another browser engine. If alone to prove that writing a new one from scratch is possible in 2020.

We have been developing one here [1]. It's a long way to go, but hey, it's open source!

And we had found it working fine on a RaPi 2 couple of years back.

[1] https://gngr.info

I presume that when you keep focusing on HTML and CSS, it can find a good niche, while being a achievable target.

Rendering of HTML and CSS is a tough task, but can be very performant and doable without any APIs and JS/ECMA.

Thanks for the work. Interesting project!

Reply on news.ycombinator.com