Hacker News Reader

Comment by NiLSPACE | Hacker News Reader

I'd argue that Gecko is a real WebKit alternative. It has improved quite dramatically lately, have you tried Firefox Nightly?

View on HN

The problem with in its current state as a WebKit alternative is that it lacks stable api.

We don't see any gecko based apps like we see WebKit based apps (electron, etc) because gecko is so tightly developed around Firefox.

I remember way before Electron there was XULRunner, and there were a few ridiculously bloated non-Mozilla apps that were based on it. Like Songbird[1] -- anyone remember that?

I suppose the idea was largely ahead of its time; in 2006 computers just didn't have enough RAM/CPU to get away with running a full web browser stack for every app like we (sort of) can today.

[1]: https://en.wikipedia.org/wiki/Songbird_(software)

Back then I was a big fan of the concept and I really enjoyed songbird.

I still think that building a html+javascript package, and have the default browser run it chromeless with some expanded privileges (or near chromeless) is a great approach for cross-platform apps, sadly it doesn't seem like anyone is working seriously on such an approach.

HTA (basically a HTML page launched chromelessly with elevated privileges) was a thing back around the Windows 98 era. Everyone I knew at the time universally considered it a horrible and misguided idea by Microsoft. Funny how the history repeats itself.

https://en.wikipedia.org/wiki/HTML_Application

There's Electrino, which provides the Electron api but runs whatever your OS's built-in rendering engine is: https://github.com/pojala/electrino Still in development and relatively limited, but the idea's there!

There's also Sciter, which is supposedly very mature (even more so than Electron), but as it's closed source and released under a mixed licence (there are free and commercial versions), it's not got much traction outside of commercial apps:

https://sciter.com/

OMG, I had never seen Sciter before, All I thought is a lie, ESET, Norton, Avast all were using HTML even before electron exist. I always thought theirs software was made by hand using native APIs and frameworks.

> I still think [it] is a great approach for cross-platform apps

You think so? I find that running a whole second OS for every process is hugely bloated and slow, and that we can do much, much better when there are already very good languages that run cross-platformly, they just need bindings to a good cross-platform UI toolkit.

Unfortunately, nothing looks as good on OS X as Cocoa does.

Yes. Yes I do.

Look at R studio. Wonderful IDE, runs as a safari app. Having a whole extra browser and a node backend running for each app seems a waste, but using the browser that is already running as a runtime environment seems much saner.

I do most of my work in the browser, I wouldn't mind if some of that had better integrated UI.

I also wouldn't mind writing small, easy to produce apps that will work across systems.

I'm not saying programs written in it aren't useful or doable, I just don't think it's a great approach. I think it's a last-resort approach, because there just isn't a better cross-platform toolkit available.

> I still think that building a html+javascript package, and have the default browser run it

I think the thing that kills that approach is the default browser, which on Windows is IE 12 (Edge).

Edge isn't actually that bad to work with these days. But almost no web developers will use that when they could ship Chromium / Electron just as easily and get the exact same browser on all three platforms.

Even Microsoft's own teams will sometimes make that choice (VS Code using Electron.js and not Edge, for example)

I don't think Edge is the problem: the problem is IE11 and people clutching to Windows 7 until the bitter end and whether or not to support them.

You can see bits and pieces where Microsoft's teams are also experimenting with Node on ChakraCore and Electron on Edge.

I don think it's quite the same thing though. Songbird was a XUL app with extension support and a built in browser. Aren't Electron based apps HTML based and running on Website?

They don't run on a website, they are static files (usually) served from a zip file.

Argh, sorry phone auto-corrected Webkit to Website.

True, Gecko lacks a real API for embedding. Servo on the other hand has embedding in mind from the start. There is someone from the Servo team working on it: https://github.com/paulrouget/servoshell

That's good. I don't see a point in having an app that embeds a browser to show an app. It's like having those silly Android apps that are just a wrapper around a web version of the service.

If I want to use a web version I can do it using a browser of my choosing not the one developers want.

The browser rendering environment is only half of electron. Electron (and nw.js) provide a node.js / browser hybrid. You can use native node-modules, instead of browser-based workarounds and you have the same filesystem access a native application would have. You also have hooks into platform specific menu/dock/notifications.

It is, it's just hard to track what's going on in a way. The browser saw new ideas, and rollbacks (hello ? IIRC). There's the XUL layers, Electrolysis, the actual engine. I have to admit If you clean your mind from memories of high latency Firefox GUI, it's now near chrome-fast on the UX side. Memory use is adequate if not #1. Tabs are well handled too.

Reply on news.ycombinator.com