Hacker News new | ask | show | jobs
by ptrott2017 2067 days ago
Sciter is a very nice engine with a solid API/SDK and rock solid engineering behind it. For developers building efficient UI apps it can be a real alternative method to things like electron or as a lighter alternative to QT with QML script. However until now it was only available under commercial licence.

Andrew Fedoniouk ( a.k.a. c-smile Sciter's original developer) has a kickstarter to fund open sourcing and supporting additional development to make it more accessible javascript developers. Learn more here:

https://www.kickstarter.com/projects/c-smile/open-source-sci...

7 comments

This is the kind of project that I'd hope the Linux Foundation or similar could take an interest in financing too.

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.

"Until...all major modern OSes come with a built in scriptable headless browser engine, which would be a game-changer."

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.

I think for "all major modern OSS" to apply we need at least Windows and macOS support. Internet Explorer never fit this description.

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

People forget that when OS X launched IE was the default browser :)
IE on Mac was a different code base, different layout engine, and did not run ActiveX plugins.

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).

Plus there was an X Windows version that ran on Solaris. I'm sure making it work on Linux would have been quite possible had they wanted to.
Internet Explorer ran on macOS back when it was relevant. It got discontinued after Safari was released. Also, Internet Explorer was ported to various Unices. It just never got ported to a Linux-kernel based OS.

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.

Not only was there IE for Mac -- at the time, it was actually a pretty decent browser. Bit rotted over time, but there was a stretch when your choices were a really janky Netscape and IE for Mac, and the choice as I recall it was pretty easy.
Not only was it pretty decent, it was far more standards compliant than the Windows IE. I don't think they actually shared much code wise. At least developing for IE on Mac felt like adding another browser to test.
The first computer I bought with my own money was an iMac running at 266 Mhz (not the first gen running 33Mhz slower!), Mac OS 8 something and Internet Explorer 5 I think.

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

> Until, at least, all major modern OSes come with a built in scriptable headless browser engine

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.

#2. Browsers are for browsing - desktop and mobile application UI requires far more than that.

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.

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

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!

"It does!" at some extent that is far from being adequate for native UI needs.

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.

Exactly, but we can check for feature support and adapt accordingly. We did it for the seen for years.
What if you have no browser for the platform at all?

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/

Right, but I'm getting the sense that people may have done it for years, but all that did was engender a desire to never have to worry about compatibility again
It really is the age old debate between static and dynamic libraries.
I think macOS and Windows are covered in that regard, though with different JavaScript and HTML engines. A normalizing layer above could be an interesting approach.
They already do. Macs have Webkit, and I'm sure Windows has an equivalent.
Yesterday’s HN thread SciTer, HTML/CSS Engine, May Go Open Source via Kickstarter:

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

For $100K in total, a tiny marketing budget those companies could have shown some good will towards Open Source.

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

I agree, but companies don't work that way unfortunately. It's really hard to go ask your boss for budget to... just donate.
Also since these companies are already using the product and perhaps have even paid a licensing fee or royalty for it, it is unlikely they will want others to get it for free.

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.

Given the author wants to release Sciter under GPL, unless twice as many funds are raised, I fail to see the incentive for any company to fund this. GPL + commercial licensing model changes nothing for commercial product developers.
It would be surprising if the companies using Sciter (Norton, Avast, ESet, BitDefender) didn't have a copy of the source code with their commercial license, and the right to ship their own patched version with their software.

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.

Why is sciter so popular with antivirus companies?
For many reasons.

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.

> For many reasons.

[snip reasons]

But why AV companies specifically?

What order are those in? The top left (first one) is the best UI IMO. Lol.
Well Mozilla spends over $50 million year-over-year on non-development costs that have generally proven to be completely ineffective: their marketing budget. So a one-time $100k cost is a fraction of a percent of what they already squander on at least one program they get next to no ROI from; pay the one-time cost for this, and the marketing they get out of being the one that made it happen comes along for free.

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...

> Well Mozilla spends over $50 million year-over-year on non-development costs that have generally proven to be completely ineffective

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.

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

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.)

> 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

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.

$200k is still chump change to these companies. Probably Github has paid a multitude to that to the team of employed electron devs already, and that's just for the work of wrapping CEF with a js layer. Sciter on the other hand is an entire HTML engine. As the new evolutionary step beyond electron, I think it deserves that money. Even a million dollars would be still a deal.
I agree to both that $200k is change for many companies and that it's very well deserved. My point is that companies that use SciterJS for commercial applications already have a commercial license. Therefore releasing Sciter as a FOSS product under GPL license doesn't change anything for both existing and new players in the market.
> GPL + commercial licensing model changes nothing for commercial product developers.

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?

I would suspect that an app that depends on (and is shipped with) a GPL engine gets contaminated with GPL.

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

Native c/c++ code linking maybe? Linking with native modules may be important to some projects, and that's complicated when the GPL is involved.
> Native c/c++ code linking maybe?

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.

> Companies do C/C++ linking to Electron itself in a web app?

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.

> Companies do C/C++ linking to Electron itself in a web app? I'm sorry, but I've never heard of such a thing.

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.

Those customers probably couldn't care less about open sourcing somebody else's work.
55 hours to go and not even a third of the goal completed. I’m an optimistic guy but I don’t see this happening.

EDIT: I wouldn’t mind being wrong.

https://www.backerkit.com/projects/c-smile/open-source-scite...

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...

I don't see it happening either.

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.

> Essentially, the proposition is that we the community pay and they will relicense it to GPL

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

My suspicion is because:

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 absolutely the target market for this (I've even downloaded Sciter and tried it out before now)... and I had no idea this Kickstarter had been made.

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

yeah i just found the kickstarter when I was replying to this thread. Off to go and sign up for it now...
It's really sad because this is the first time I heard about this campaign. Had I known earlier I would have pledged sooner and spread the word around.
Did my bit to chip in. Some hope still!
It seems like there's no way this kickstarter is going to reach it's target now unfortunately.

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.

Could Sciter be used as an actual web browser too? We badly need more diversity in that space...
I'm not completely sure, but it seems like maybe Sciter is able to stay so lightweight because it implements a subset of the HTML/CSS.

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

If they're still trying to fund open-sourcing it, what is in this repo?
The repo only contains binaries for Windows (no source).