Comment by pritambarhate | Hacker News Reader

Comment by pritambarhate | Hacker News Reader

>> We needed something in between a huge, all-in-one browser toolkit and a bare-bones HTML UI renderer that only supports a tiny subset of HTML/CSS spec.

>> We started over with WebKit, stripped it to the bare-minimum, then rebuilt it from scratch with an eye towards embedding.

This is very similar to the origin story of Flutter. [1] In the end Flutter team just abandoned the HTML based UI idea and went with their own component system. As per the podcast, the core team doesn't have any plans to bring Flutter to the desktop development. I wish they would do it, that way we can get a performant alternative to Electron.

[1] https://softwareengineeringdaily.com/wp-content/uploads/2018...

Edit: Found the actual quote from the podcast:

>> We allowed ourselves, I think it was a week or two and we just tore Chrome apart and see how fast we could move on our benchmarks. Allowing ourselves to break compatibility to the web. The end result was we were 20 times faster on some of the benchmarks that we cared about and obviously, the end product wasn’t the web, it didn’t render all web pages, but it taught us that there was a lot of potential to do things better, faster, if we worked on something that was beyond the web.

That's really interesting! Thanks for sharing.

There's actually been several HTML UI projects that "break compatibility with the web" in varying degrees, with some breaking almost completely (eg, Sciter and libRocket) for the sake of simplicity and performance.

The goal of Ultralight was to see if we could strike a balance between modern HTML5 compatibility (eg, actually being able to render the Alexa Top 50) and reducing size and complexity for use in an embedded use-case.

I think we've struck a good balance so far but can go much farther. We plan to support much more of the web platform while still remaining small by use of shared modules (eg, for WebAudio/Video) so users can pick and choose how big of a distributable they want based on feature support.

As an aside, I took 2 years off just to explore if this was possible, partly funded by my previous work on Awesomium. This project is the result of that research and development.

Do you support JavaScript? I always got the impression that that’s one of the most resource-heavy parts of the modern web, but at the same time it’s hard to render many modern webpages (webapps?) without it..

Yep! In fact we expose JavaScriptCore API directly to users so your native code can call directly into the VM. Check the samples in the SDK.

I hope you add https://codesandbox.io/ to the list of websites that you aim to explicitly support! They use VS Code's editor (Monaco) internally, which does not work in WKWebView on macOS.

> I wish they would do it, that way we can get a performant alternative to Electron.

Qt / QML is an existing performant alternative to Electron.

How are their licensing terms?

GPL, LGPLv3 or commercial.

...and if you don't like C++

https://github.com/pauldotknopf/Qml.Net

I love Flutter. It's super dumb that they are not pushing hard to every platform (you could render to the web and basically get the desktop for free!). I would love to use it for a desktop app, or maybe on the web.

Someone else could do it. After all, Electron wasn't started by Google.

Not to dismiss work done by the Electron team but Electron essentially wraps Chromium via CEF, so, tangentially it was made possible by Google.

And Chromium came from -> WebKit (Apple) which came from -> Konqueror/KHTML (KDE)

Haha, I totally wrote that up but deleted it at the risk of sounding too fastidious.

You probably mean pedantic. 'Fastidious' concerns attention to detail, not level of detail.

no, pedantant is what you are doing: correcting above comms

We've reached peak Hacker News.

I wonder if there's a limit to thread depth.

homie electron doesn't use CEF in any way

I love Flutter, too.

There are other ways to get the same juice, though.

I love MOAI, for the same reasons as I love Flutter. Except MOAI has a better license .. even if the responsibilities for using it as a non-Game GUI are pretty high. You can do it, but you've gotta have Lua-foo.

In my case, I'm going to glom Ultralig.ht onto MOAI some day soon, and see if it makes the Flutter desktop problem irrelevant...

Not only Flutter, that is how XAML and WPF came to be.

The team was lead by IE devs, which were trying to create a design how would it look like if the browser was actually designed for applications and not documents.

Also for those that aren't aware the initial design of CSS grid was based on how XAML grid layouts work.

https://github.com/google/flutter-desktop-embedding

My criticism of webkit is that it fails hard on separating concerns in code. The way JS is superglued into code base is prime example of it.

Netsurf is on other hand is an opposite:

Css parsing - separate lib

Html/xhtml parsing - separate libs

Network - fully based on external libs

Js execution - separate lib

Dom - separate lib

Layouting - separate lib

Final renderer - separate lib

It has a lot of promise

How spec compliant is Netsurf? JavaScript is "superglued" into the code base in all 3 major open source browser engines, mostly because it's also superglued into the specs.

What? WebKit doesn't contain any JavaScript implementation, certainly not glued in. Apple uses JavaScriptCore (Nitro) which wasn't even open source; before Google forked Blink, they were using WebKit with their own JS engine, V8.

I thought they were using Flutter in desktop development by way of the Fuchsia operating system.

Reply on news.ycombinator.com