Flow Browser Preview on the Raspberry Pi 400(ekioh.com)
ekioh.com
Flow Browser Preview on the Raspberry Pi 400
https://www.ekioh.com/blog/flow-raspberry-pi/
17 comments
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.
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.
They merged in the CSS work (stylo) a while back and Webrender is now the default 2d engine.
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 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.
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
> 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.
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.
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.
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.
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?
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.
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).
[0] https://www.ekioh.com/company/#partners
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.
Can we agree it's impractical, even if technically possible?
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.
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.
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.
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
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.
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.
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.
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.
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.
But that is not the same as saying that making a new browser engine being impossible in 2020.
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.
> 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
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!
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!
> 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 had no idea this was a thing.
https://en.wikipedia.org/wiki/Web_Cryptography_API
https://developer.mozilla.org/en-US/docs/Web/API/Web_Crypto_...
I had no idea this was a thing.
https://en.wikipedia.org/wiki/Web_Cryptography_API
https://developer.mozilla.org/en-US/docs/Web/API/Web_Crypto_...
Here's an analysis of the Flow Browser: https://thereshouldbenored.com/posts/flow-new-engine/ by browser standards/testing veteran gsnedders here on HN, from June.
I cut out the juciest bit from the middle:
> The answer is almost certainly it cannot succeed as a general-purpose browser. Indeed, they've said themselves (emphasis mine) ...
Lots and lots of insightful commentary cut out, really do read it!
I cut out the juciest bit from the middle:
> The answer is almost certainly it cannot succeed as a general-purpose browser. Indeed, they've said themselves (emphasis mine) ...
Lots and lots of insightful commentary cut out, really do read it!
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.
> 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.
Oh. Hi. :)
> 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.
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.
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.
Is this closed or open source? I couldn’t find a public repo anywhere in the links
It is closed.
The mention Spidermonkey and a Gstreamer integration on their product page.
I wonder if they've pushed any fixes or bug reports upstream.
I wonder if they've pushed any fixes or bug reports upstream.
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.
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.
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.
No one is paying for a web browser. It doesn't matter how fast it is.
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.
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.
I am ready to buy.
Needs: FOSS reasonable rendering, runs on Linux (Gentoo), no-bs. It's mostly FF - but they still pack in BS. And I want things like uBO to work.
I keep experiment with Servo and trying to build apps to embed other renderers so already spend time-cash trying to solve "user agent" problem
Needs: FOSS reasonable rendering, runs on Linux (Gentoo), no-bs. It's mostly FF - but they still pack in BS. And I want things like uBO to work.
I keep experiment with Servo and trying to build apps to embed other renderers so already spend time-cash trying to solve "user agent" problem
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.
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.
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.
Most people don't know or care what engine is in Edge, so the message of "now more compatible" (which is probably true) sounds good.
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 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).
Rendering speed matters on weak CPUs powered by batteries. I.e. every (previous generation) smartphone.
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?
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.
https://switchbrew.org/wiki/Internet_Browser
https://switchbrew.org/wiki/Internet_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.
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.
Exciting to see another browser engine in the wild.
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.
Perhaps a browser such as Flow built for embedded hardware could address that.
If hardware variance is a distraction in a software project. As indicated by this project. Would a VM work as well or would there be shortfalls?
Interesting. great to see a new challenger in the monoplolised browser industry. wonder if they will bring it to everyday computers...
Quite daring to start a brand new browser with its own engine. I wish them the best! I'll try it out when I can.
[deleted]
:~/ekioh_5.11.4_raspberry-pi-flow_20201221_r33618$ ./flow
-bash: ./flow: No such file or directory
-bash: ./flow: No such file or directory
I, for one, welcome our new browser overlords. Not really, but great to see a new viable 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.