Until, at least, all major modern OSes come with a built in scriptable headless browser engine, which would be a game-changer. Something-like-electron-or-sciter where you don't have to download the runtime for each individual application.

Also, of course, not a walled garden: the windows "modern apps" store can sort of do this I think, but there are lots of good reasons not to go down that path.

Ah, yes. Internet Explorer, they called it. Built right into the OS. A game changer. Funny how the meaning of something (goodness/badness/motives/...) can change as circumstances change.

Edit: This comment is wrong - looks like IE did fit this description before my time. :-)

It was a good browser at the time, and helped move the OS X platform forward. Perhaps even a vital part of the software support available at release.

But it wasn't IE6.

All that corporate ActiveX, DCOM software could not be deployed on it.

Microsoft grew multiple platforms to address this, for 20 years, but that's another story (that may also be relevant to the article).

If software like this is FOSS, relies on open standards, and is designed architect independent it can be run on virtually anything. Including something which is rising in popularity.

Google didn't exist or wasn't evil yet and finding things was quite difficult specially at dial-up "speed".

One of the main advantages of shipping your own browser like Electron or SciterJS is that it's a fixed, stable target where you can be a lot more confident about browser compatibility because you're only supporting a single browser + version.

Browsers are catching up of course but... Who would thought that the thing for reading pages will need access to your file system or make screenshots...

#3. UI engine must have natural and effective means to use native code - to be embeddable and extendable by hosting application.

In native app world you don't need WebAssembler for example - you can run native code you need natively.

It does! Most browsers are written in "native code" and use it to do layout. When you use an <input /> field on a website, you get a natively rendered UI widget with native OS behaviour!

Consider that you need add <word>...</word> element that will implement natively MS Word editing area. This will allow you to define MS Word editing chrome in HTML/CSS but keep core editing functionality native and effective.

Consider implementation of <tabs> native element/behavior: https://github.com/c-smile/sciter-sdk/blob/master/include/be...

This is a demo of how native code can extend DOM - adding native "drivers" of app specific DOM elements. Yet there are other examples of native behaviors: https://github.com/c-smile/sciter-sdk/tree/master/include/be...

Essentially native behavior can do anything that built-in elements can do, even drawing on the same surface that the rest of DOM is using.

Good luck with achieving anything like that in browsers, or in Electron, or with WebAsm or whatever.

What should you do if you need your app to run on W2000 for example (IE 6.0 anyone?) ?

Sometimes people do need that: https://sciter.com/necromancing-sciter-on-windows-2000/

https://news.ycombinator.com/item?id=24786527

I wonder if the author actually contacted those companies. That is less than $3K from each of those customers listed.

Or perhaps not. Perhaps some companies will see the value in getting more people to commit code to this product - which will likely happen if it goes open source.

If the project ever fizzled away they would probably just maintain it themselves, or migrate to Electron. Actually, it's not like these AV companies are known for their high quality product, so it wouldn't surprise me if they would just let it bitrot until there are exploitable holes.

Compact and manageable UI layer is the first. Full Sciter build for one platform/target is 50 seconds or less. Electron/Chromium builds are about tens of hours as I've been told.

Yet this https://sciter.com/from-skeuomorph-to-flat-ui-evolution-of-o...

is the same app that uses the same UI engine since 2007.

UI maintenance all these years is the matter of updating CSS declarations. Yet you always know that it will be HTML/CSS people that can do your UI in future.

[snip reasons]

But why AV companies specifically?

AV/security specific reasons:

First serious customer was Symantec with their Norton Antivirus. Norton AV 2007 was their first version that used Sciter (named HTMLayout then). And Norton AV was market leader at that time.

Symantec did first security audit of Sciter source code.

You (AV vendor) have UI engine that fits most of UI requirements (lightweight, supports i18n by nature, flexible to screen resolution, HTML/CSS is well known in UI) and, which is most valuable, secure. So decision is quite obvious.

Yet, psychological aspect.

AV product must look modern at any time. User may not trust AV app that looks outdated - that rises suspicion that it is not adequate to recent threats - so it must look modern. Therefore ability to modernize UI by CSS without touching anything else (happens at least once per year) is the key requirement. UI systems/frameworks that use designs nailed down to pixel grids are too expensive on the long run in such circumstances.

And they outwardly profess to be in an uncomfortable position due to Blink's stranglehold over the hearts and minds of developers. Electron plays a major role there. Something like this would go further to support the Mozilla mission than anything they've done themselves (and done to themselves) over the last ~3 years...

Warning: opinions and unresearced statements ahead

Considering the contract they landed earlier this year many of us would be really happy to fail so successfully financially.

That said: Of course on the technical side they've given away much of their previously huge edge on extensibility, gained some performance (or so I hear, I never had issues with the old Firefox) and some security (again: from what I hear). Oh, and spent some major goodwill from the security community on stupid gimmicks.

Here's to hoping they can pull something off (for example by sponsoring this project or something, I don't know) to make themselves relevant again and stay relevant by again capturing the power user / enthusiast niche.

Because right now we are starving for better alternatives, there isn't exactly much to be enthusiastic about at the moment IMO: browsers just get more and more complex and enable more and more crazy applications.

This is worded as if it's a retort to the previous comment, but... how is it supposed to be?

The claim is that Mozilla's marketing program is overbudgeted and useless, not that Mozilla is "financially [un]successful". Even if you subscribe to the philosophy that multi-million royalties -> success, there's no contradiction. The only way that would be a contradiction is if the marketing team is the one that "landed" that deal. (And that deal isn't even new. Mozilla and Google have had similar deals forever.)

> The claim is that Mozilla's marketing program is overbudgeted and useless

My point was that maybe they are targeting their marketing at someone else than end users (Google? Regulators?).

And that I think it is frustrating and a bad idea in the long run.

I'm not sure I understand your comment. This is an Electron alternative. Is it common for companies to release modified versions of Electron? I admit I don't work in this space, but I thought the point of Electron is to make it possible to distribute a web app as a "native" app. Why would a company dig into the source code and develop a modified version of Electron rather than simply use it as a tool to distribute their app?

If we were talking about LGPL this wouldn't be a question because of the linking exception, but with the GPL no company would want to risk being forced to release their source code. Anyone with a legal department would opt for the commercial licence

Companies do C/C++ linking to Electron itself in a web app? I'm sorry, but I've never heard of such a thing. Do they also do C/C++ linking to the browser for the web app version fo the app? Web development must really have changed in recent years.

That's one of the selling points of Electron, write your frontend in whatever JS framework your frontend devs want to use, provide hooks through node modules to your application where the heavy lifting is done using whatever language/runtime you want.

> Do they also do C/C++ linking to the browser for the web app version fo the app?

If a web version can exists (Electron apps cover spaces that web apps can't), and it's identical to your Electron app, then your Electron app never needed to be written in the first place.

Yes. Specifically to bridge into native functionality.

> Do they also do C/C++ linking to the browser for the web app version fo the app? Web development must really have changed in recent years.

There might not be a webapp (if the core functionality requires native code). Or it may exist but have a different tech stack involved where the native code can't be used.

EDIT: I wouldn’t mind being wrong.

It's a bit bleak indeed.

The "open-sourcing the sciter" post [0] has gained almost no traction, news coverage [1] etc. This hn thread is the first time I heard of this kickstarter myself.

I think with a bit of marketing, the goal is absolutely reachable. Also there are plenty of grants and foundations that support open source projects. It's likely that with the right application they'll donate the needed amount, but usually they work quite slowly. Likely won't happen in the remaining 53 hours.

[0]: https://terrainformatica.com/2020/09/07/open-sourcing-the-sc...

[1]: https://www.google.com/search?q=sciter+open+source&tbm=nws&s...

1. It's a GPL release. 2. None of the rewards are happening in some far-future date. It's all in October (of which there is 15 days left).

Essentially, the proposition is that we the community pay and they will relicense it to GPL. If we pay more then they licence to BSD.

Using Kickstarter to pay for essentially finished goods isn't really the point of the system, and won't really work without a marketing campaign. Now, if grassroots were behind this, then a paid marketing campaign wouldn't be necessary... but the actual customers of ScriterJS, are commercial companies already paying for a licence and won't benefit from a GPL release.

Elsewhere in this thread, people talk about the goodwill the companies will gain if they pay for this project to be open sourced. However open source goodwill is only generated by popular projects, who market their sponsors. The lack of marketing around the kickstarter, would make companies think that their sponsorship won't receive much PR as well.

Lastly, one must ask why the company behind ScriterJS doesn't simply open source it themselves for goodwill and let a community grow organically to support it (via donations or code)? While no one can guarantee on-going support indefinitely, the way this projects release is being positioned makes me think its going to be an abandoned code-dump.

All said, it looks like a commercial company wants to dump their product. If they can get enough money, they'll open source it. If not, they'll just let long-tail revenue trickle in for the next few years to get the same sum of money.

Yes, that's the Blender model, but unfortunately without any publicity.

a) It's $100k for GPL. $200k for MIT. I expect the latter is much more interesting to most people but there's no way to pledge for only that.

b) It's still web based. I think the large file size of Electron apps is only part of most people here's objection to them. There's also the general slowness, jankyness, lack of coherence, bugginess etc.

Still, I would have expected more interest than this.

I'm not sure what the answer is, but I wouldn't assume there's no interest out there!

There must be tons of companies that could benefit from this, so it's too bad that there aren't more people pledging money for the kickstarter campaign.

If not, though, that would be a pretty big deal.