Hacker News Reader

Comment by badsectoracula | Hacker News Reader

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.

View on HN

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.

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.

Reply on news.ycombinator.com