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:
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.
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.
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
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.
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.
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.
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.
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.
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.)
$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
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.
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.
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.
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!
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.
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.
What would be strategies in case of Kickstarter campaign will fail?
In principle I can publish it for free as it is now but I definitely don't want it to be one more of abandon-ware projects that are open sourcing as the end of life.
In general OS development is significantly more costly (for the author) as closed source one - for many reasons. So OS development needs steady stream of funding.
Open source development doesn't have to be more costly than closed source, except in this case it might be if you end up believing the people who tell you that the best way to be successful is to cut off your ability of ever again getting a commercial contract out of the kinds of organizations who want to build proprietary apps on your work by publishing under a permissive license like BSD or MIT.
> What would be strategies in case of Kickstarter campaign will fail?
Publish under GPL and don't listen to those who tell you that "open source" means anything other than offering your code to folks under an open source license. Just do whatever you're already doing right now, chuck code over the wall every now and then with an appropriate license attached, and ignore anyone who isn't paying you but insists that you owe them something.
> What would be strategies in case of Kickstarter campaign will fail?
I think you chose the wrong goal here.
I don't think you really want a one-time, lump sum donation to "unlock" your code under a FOSS license.
I would think you want regular, recurring payments to keep you in the job of writing the code that pushes the project forward.
Judging from the cron job of "Electron-so-fat" posts here on HN, there may be an audience for that. And judging from the fact that you've already raised close to $10,000 to unlock the initial code, unlocking code may be a sufficient incentive to get that audience to pay you to do the work.
But to keep that number up for recurring payments I think you've got to keep on the "Farmville" route, at least if you want to get paid anywhere near the going rate. That is, there needs to be a risk not only that you abandon the project if you don't get paid, but something the audience cares about will quickly die if the payment goals aren't met. You're kind of doing that here with the MIT license being a kind of "stretch" goal, but I think you could do it more effectively on a recurring basis with the code itself.
AFAICT you can achieve the following approach with either choice of the MIT or GPL (either version). That is:
1. you work on the next feature in private
2. get it ready for a release
3. release a video of you demo'ing the feature
4. if your recurring payment goal gets met for this period, you commit the feature to the public repo
5. if not, you delete it
This complies with both licenses-- there is no requirement in either to share the source code for a binary that you haven't released yet.
I will admit it is seems strange, as there's a chance you'll have to delete useful code if the goals aren't met. But if you don't take that approach you risk continuing to develop a project for an audience that isn't willing to pay the going rate. That, and the burnout that it causes, is a much bigger problem than my suggested approach could ever be.
Besides, this is how most businesses work anyway. No drive through is handing out the food first and collecting the money second.
Why not give the new feature to paying licencees immediately and to open source 12-24 months later.
A company which is building a valuable product will not think twice whether to wait for 2 years and their rivals being faster or buying a commercial license. And everyone else just has to wait, they will get it for free one day, ignore their hate.
I have seen systems too where every new feature to an open source project had to be sponsored by big companies. If nobody is paying for it, it will never happen.
My suggestion is that the project should be open source, like Electorn or RN, otherwise will be hard to get adoption.
Revenue streams ideas:
1. Build a deployment tool, where you take care of building the apps for the different OS, basically bridge the gap from code to final binary
2. Offer support / consulting hours "from the experts"
3. Force some kind of ad/watermark/screen on the app where you can see the name of the project and website. In order to remove this you will need a key or build the project using the service I described in point 1.
Happy to chat and discuss in more details. Good luck!
Both Patreon and Kickstarter is oriented towards consumer goods but Sciter is a B2B product. Software-wise people use Kickstarter and Patreon for consumer goods like games where you need literally thousands of fans to be profitable.
Sciter is a really good quality software and I believe it can overtake QT in future, but I got a feeling you might want to go with VC funding and possibly change the business model.
"VC funding and possibly change the business model"
I was thinking about something like that. But again, realistically speaking, what would be interesting for VCs in such project to even bother about it?
I honestly don't know your business so I can't personally say it but in essence:
Do you think market(consumers) for GUI design software will increase or decrease in future? I do believe it will increase as more and more companies need in-house software. Also, it is worth noting QT has ~60 million dollars in revenue and that is definitely in the ballpark of VC backed money. You would probably have to deliver 10 million on a 1 million investment.
It mostly boils down to marketing and some quality of life improvements. Do you got a sales staff? Again, I'm in the gamedev business so I got no deep-down knowledge about GUI designer market but marketing costs are about 100% of development costs for desktop games (at the very very low end) and up to 1000% of development cost for mobile games. So in game development, marketing is the bulk of the cost, and development costs aren't all that important.
What do you think marketing costs are for GUI designers, or do you know how much QT spends on that? As an user I feel like Sciter is lacking good marketing at this stage but you can only know that and chart your way.
Please don't take any of the above advice too seriously because again I'm just a game developer, you will have to figure out this stuff yourself.
"Market(consumers) for GUI design software will increase or decrease in future?"
In regard of this, there are three types of consumer roles:
1. "readers" - all of us reading the internet, e.g. me and you reading HN now.
2. "creators" - all of us who create IT stuff and content at some extent- sites and content, browsers will never be quite adequate for that role, for many reasons. Compare desktop Word and those desperate and ugly attempts to reproduce it for browsers.
3. "app users" - you or me consuming modern applications, Slack, Skype, etc. That must be lightweight desktop apps, IMO. Sciter.JS (as does Sciter) is the best candidate for such cases.
Groups #2 and #3 are smaller but proportional to #1. As soon as #1 will grow as #2 and #3 will grow too.
So the need for desktop UI will definitely not go away in foreseeable future - only grow. And so the need of HTML/CSS in UI too - due to flexibility of Web stack and developers base.
I can think of one case where it works, the Octoprint software for managing 3D printers. The main developer Gina Häußge is fully financed by the Patreon. Though of course this is Germany, I think getting US developer salaries would be much less likely.
You probably need to be in the right niche for this model to work, I'd suspect it is quite hard to pull this off. But that goes for most ways to get paid for open source.
I think patreon would be great for your case. You already have 99 backers on Kickstarter who seemed to pledge a hefty average. It would take longer to get the Kickstarter lump sum but it would also keep generating income. If you make one you’ll have at least one patron (me)
Would depend on expenses and fanbase. Personally it seems more geared towards individuals and I've seen it do well for some. Not sure if any corporations sponsor people there or elsewhere. A lot of people like sponsoring at different tiers, like on kickstarter, which might be the key to success.
Problem is you're competing in a saturated market (Electron, React Native for Windows and macOS) and already tested your positioning once with the KickStarter campaign.
Finding a way to fund this is going to be an uphill battle, although I like the creative ideas amadeuspagel mentioned. Like anything else, find a niche somewhere (possibly related to performance/memory for clients not using React) and serve it with a modest upsell. But it's an enormous market, with entrenched competitors who don't need to make a profit on their offerings, so expect fierce competition all the way.
Wouldn't a licence like Qt do that, price for static linking.
As an open-source developer where I am not thinking to earn a single penny from apps I build why would I support the Kickstarter campaign and as a Company who want to make big why I would I support the campaign to open source it where I could just buy the source code if I want to and get an edge over others.
I don't see how the Unity/Unreal suggestion helps with open sourcing if that's a goal here. Those engines are closed source.
For obtaining revenue and building a community their model works well. Just not an open source community.
Unity is free for people and companies to use if their revenue is <$100k/year, so lots of people use it for personal projects and as early stage businesses. That gets them hooked and happy to use it, and builds a community of 3rd party add-ons and assets.
For any business whose revenue then grows to > $100k/year, the business can easily afford the relatively low license fee of Unity; they won't mind. That fee goes up with increasing revenue of the business.
yeah, I agree Sciter is a beautiful piece of software. If It goes the way of unreal engine model. that would be great. projects not generating revenue will use the product, and projects with revenue will fund for development. everyone wins. and if you wanna see source code, you pony up some cash. I'm not too hung up on seeing the code, but rather would've something that works and performs. reason, linux lags behind on desktop is cause usability is not given priority, but code being open source is.
The Unity and Unreal models aren't open source, so if you want open source as a feature, as well as revenue, you can't quite copy their models.
To get open source together with revenue, you'd need to use one of the open source business model approaches.
One of those models is "open core" where the core product is open source, and there are additional features for pay which aren't.
Another model is to use GPL or a similar copyleft license for free, and require a license fee for a more open license. Qt is a well known product that uses this (qt.io), and they also offer a revenue-based discount so that smaller businesses can pay less.
Basically we have 2 days to make Sciter open-source (GPL or MIT, depending on the amount collected).
I think landing a mature cross-platform desktop app framework which is not beholden to any browser vendors is a huge goal. It will have significant consequences for the desktop app ecosystems on all major platforms.
> think landing a mature cross-platform desktop app framework which is not beholden to any browser vendors is a huge goal.
So this adapts to different browser engines?
I think this will play in favor of Electron. Because its important to have more control, where you can customize and adapt the customize background engine.
The other thing to take into account is that Chrome itself will want to compete in this vertical, with little modifications a Javascript "application" that reuses the same browser engine you already have in your machine (BTW, I think there is something called 'Carlo' that basically achieve that).
This is a really brutal market to compete, so i'm inclined to think the opposite. Its hard to propose real value here , and if you don't do it, its hard to beat more well established propositions.
Yeah... The "1GB of data transfer --> 3kg of CO2" is high by orders of magnitude.
Computer systems and network equipment have a fixed install and fixed operational costs. I think the incremental energy cost of transferring 1GB across 5000km is on the order of 1000 Joules of energy. I think 10Gb optical transfer requires less than 10W per 100km... this probably a really high upper limit (equipment electrical power plus cooling power).
1000 J is roughly equal to 0.0003 kWh
1 kWh electrical power generation produces about 200-500g CO2 depending upon the electrical grid.
So that would work out to about 0.15grams per 1GB of data, at the most. The fixed upfront equipment costs and carbon footprint do need to the factored in as well but they are not going to amount to much.
So yeah... we talking about less than a gram of CO2 per 1GB.
I don't care to run the numbers further than this...
>The fixed upfront equipment costs and carbon footprint do need to the factored in as well but they are not going to amount to much.
In the source I gave they actually _do_ factor in the equipment costs, and turns out it does amount to more than you think.
You can't ignore the fixed operational costs, because we're not asking what's the cost of sending a single incremental gigabyte. We're asking what's the cost of transferring data, today. Total energy divided by total data volume.
> And according to the Department of Energy the average US power plant expends 600 grams of carbon dioxide for every kWh generated. That means that transferring 1GB of data produces 3kg of CO2.
Are we to believe that it takes 5kWh to transfer 1GB of data? My media server runs under 500W, so could operate for over 10 hours before hitting this and download terabytes of data. Even other machines needed to facilitate the connection can't explain a 1000x discrepancy.
My guess is that the author confused kWh with Wh at some point.
If you look at your own source (the two Figure 3 inserts from 2017 and 2018 studies), they estimate that in 2020 the kWh/GB measure would be between 0.1 and 0.01. That equates to between 60 and 6 grams of CO2 per GB, smack bang in the middle of the International Energy Agency estimate I linked to (29 grams).
The reason for the big discrepancy is your source article was written in 2016, and it referenced a study from 2012 for its 5.12 kWh/GB number, and that 2012 study used bandwidth data from 2011.
Telecommunication systems are still getting exponentially more efficient over time (see the second Figure 3), so estimates get old very quickly.
Current standards emission around here are pushing for under 95gCO2/km, which seems to eliminate pure ICE. My 2008 sports car is rated as emitting 200gCO2/km (WFH so not a daily driver mind you).
The average car around here should be in the ballpark of 150gCO2/km, so 29g would be 200m.
checkout how conformant QuickJS is with the modern ES standards https://test262.report/ (especially compared with other engines developed by big teams and companies behind them)
Fabrice Bellard is a genius, and I really don't like using this word.
Prodigies like him kind of scare me. I studied at the same place as where Adam Dunkels (behind e.g. uIP and Contiki, a networked OS requiring 30 KB RAM and 30 KB ROM despite a GUI) did and he was almost a mythological figure with stories of taking multiple classes at once with ease.
Yeah, I read about a cool tech and half the time he's behind it. When I learned about the rocketman flying near an airport a few weeks ago I was surprised it wasn't him testing his new rocket engine 3d printed in his basement! ;)
It is more amazing given that QuickJS is not a single feat but a cumulation of his older projects, each of them is great by itself:
- TCC [1]: Of course, QuickJS is not the first language implementation he's written.
- Pi calculation [2]: Once the world record holder (and opening the era of pi computation in commodity PCs), this surely inspired his next great invention:
- LibBF [3]: A good and small arbitrary-precision number library. I think LibBF is a byproduct of NumCalc [4], and he has probably seen a way to the full language implementation using LibBF later (the current version of NumCalc is indeed based on QuickJS, sharing the technique used in the current version of JSLinux [5]).
The wonders of Bellard never cease. Another discovery for me was that he wrote LZEXE in 1989~90 when he was 17. I remember this program from my childhood.
C-smile (OP) ported Fabrice Bellard's gcc code to standard C (without gcc extensions).
The Sciter engine currently uses TIScript - a language c-smile orginally developed and the kickstarter proposal is to open source Sciter as is, then replace TIScript with the QuickJS engine. (TIScript is a very nice scripting language in itself that is easily picked up by JS devs)
The standard C version of QuickJS can be compiled using visual studio on windows as can be seen in this repo: https://github.com/c-smile/quickjspp
Very much in the same vein as Duktape[0]. It looks like Duktape is smaller and has a more useful standard library, but is slower and doesn't support ES2020 features.
Duktape supports ES5, with only partial support for anything ES6+ (and not much partial support, at that).
That said - having used Duktape in production, it's a very handy little library. Small, easy to drop into projects, great way to add support for custom user scripts or to run js code somewhere outside of a browser context.
Also - insanely easy to target still, despite the lack of ES6+, as long as you already have babel somewhere in your build pipeline.
These package the operating system's native web view, which has its own set of issues like inconsistency. Sciter on the other hand is its own HTML rendering engine.
I'm hoping Chromium become componentized. E.g. I can package WebGl component only for game or I can strip out the WebGl component for normal HTML/CSS app.
An Electron alternative, that is much smaller in size. Who does not want that? Here is the chance! Only 53 hours left to go and only about CAD5000-CAD6000 achieved. Yes, I payed my share. But I got no bitcoins, so... ;-)
I think we'd be better off trying to slim down Chromium or reviving the idea of using the built-in OS WebView control (which is mostly Chromium nowadays anyway), at least that would be a standard web environment.
Helping in avoiding making Chromium the default is icing on top of the cake.
Edit: I also want a massively cut down, blazingly fast rendering engine for a subset of html that is big enough for Wikipedia. Specifically I want it to be paired with a strictly limited version of something like Javascript, only limited and with batteries included.
Dynamically updating content on user clicks should be OK, running general calculations should be hard.
> "...Some of these directions better suit Open Source development model for many reasons."
So they want $100,000 to give people the source code. Then they're saying it will suit Open Source Development (also requesting free labour from the community).... this is a red flag
Sciter has been around a while and has a good reputation amongst those who have used the SDK. The OP also has a good reputation amongst devs and hackers who are familiar with his work. Its just not well known outside those circles. Rather than a red flag I don't see this as any different to when Blender needed to raise 100K Euro to originally go open source.
This is one of my biggest pet peeves, the worst offender is companies that have a github logo on their page, you click through, and their only repos are binaries, or documentation. It's hard not to see it as intentionally misleading.
I fully agree with that. Even more, I'm not so sure that it is in accordance with Github's rules, and might (sometimes) even be in in direct violation of the license with which it is got published. Either way, it certainly feels abusive.
While I did read a lot of positive things about this particular project in several of the comments, one thing just rubs me the wrong way (and I can't shake it) .. it is the short time frame (left) until the kickstarter will run out, with the clearly stated intent to not open source if it doesn't make enough money in time. That just feels wrong on too many levels. I'm quite surprised actually, that I didn't see this pointing out by more people.
It's similar to other third-party component libraries out there. There are open source and closed source ones.
With the closed source ones you can take a leap of faith and trust the developer of the project, how it's documented, what it does, and decide whether or not to use it. If you submit to an app store, they can decide whether to approve it.
There are closed-source third-party component libraries out there that have a lot less info about the project and the creator than this one, that get distributed to end users.
GitHub has quite a large and varied audience. Some expect GitHub to have only open source software that can be vetted by examining the source code. For those it's a red flag. There are plenty of other developers for which it isn't a red flag, though.
> It's similar to other third-party component libraries out there. There are open source and closed source ones.
You're trying to side-step the fact that a random user uploaded binaries that were crafted to do god knows what to the host's computer in a way that circumvents basic auditing and security checks, and did so while hijacking/piggybacking on popular software projects.
You can try to spin this any way you want, but you need to be crazy to download and run these binaries as there is zero assurance they are not malware.
It isn't a random user. The author of the repo has quite an online presence and track record.
My top choice, all other things equal, is open source code but I know I don't read all the code and rely on a trust network.
A lot of open source code is distributed as binaries these days, in go, rust, docker, and others. Developers have an option to download the source and compile it ourselves but they don't always do it. It's convenient to be able to download a self-contained binary.
I'm not trying to spin it, just to point out that I'd have an easier time trusting this than I'd have trusting many open source projects.
"a random user" is the developer of Sciter, which is the UI engine used by practically every antivirus software on the planet. This is just a demo of his new project that combines Sciter with a JS engine. He only provided demo binaries because he is running a crowdfunding campaign to release the opensource version.
According to this SO question [1] with the OP's answer, it seems that most AVs share the Material-like design for which Sciter suits. Using Electron in AVs (among others that would only require the layout engine) would be silly.
HTML is a typesetting engine. It's not a "UI language" and never has been.
I don't know why would anyone think it's a good choice to do UI apps. The fact we use it on a web is a historical accident and causes a lot of pain and damage to the industry.
"Everyone hates on Electron" = a very vocal minority of HN folk don't like that Electron apps tend to be higher in memory consumption and executable size, but the majority of users don't really care about either of those. Same for the majority of project leads.
What users care about is "does this thing do what I need it to do on my OS in a relatively timely manner with not too many bugs and not too steep a learning curve?". What project leads care about is "is this tech well supported, cross-patform, and battle-tested, and will it be easy to hire for?".
Using established frameworks that are profit centers for enterprise-scale companies (MSFT/Google) ensures support will always be around, and the largest cross-platform bugs have already been encountered then fixed/documented. Using normal web-tech means performance will be acceptable (people have a good feel for how long things take in web), and hiring/on-boarding will be easy (we routinely have folks with only basic web dev experience building vscode and contributing fixes within a matter of hours of encountering the code for the first time).
I challenge you to try to mentally-argue one of these alternatives to a superior... I think you'll find that you don't have much to say but "look a the memory consumption! look at the download size!", but I'd be interested to be proven wrong.
someone explain to why if this was a commercial product for all these years and the _numerous_ (my god that list is impressive) clients that are using it, they need $100K to make it open source? Last I heard github is free. am i missing things?
> someone explain to why if this was a commercial product for all these years and the _numerous_ (my god that list is impressive) clients that are using it, they need $100K to make it open source? Last I heard github is free. am i missing things?
Well, it is the author's source of income. Presumably, those customers will stop paying him if the code is released under a permissive license like MIT. I'm not certain what the financial impact would be of a GPL release.
What rights are granted to the application's origin beyond what an ordinary website has in a browser? Obviously you want to grant some additional rights, but I'd prefer to grant it only the minimum necessary for my application.
Are third party origins granted special rights beyond what an ordinary website has in a browser? Embedding or redirecting to untrusted websites should be safe. Is it possible to block loading external content except from whitelisted origins?
this thread is overwhelmingly positive and lacking the disquisitive nature a ycomb thread usually has. For an oss project (that isn't really OSS) that only supports one platform and is actively looking for funding?? idk
Not to worry. He already has the sciter core running on many platforms. I guess he is just adding JS and open-sourcing it if the campaign were to go well.
Real shame, Sciter is one of the strongest options out there since its coded natively on each platform and the web engine is added on top.
That's the idea of Sciter.JS: engine with core functionality that can be configured to run browser and electron applications, just a matter of adequate compatibility layer.
Please, please stop comparing built in platform webviews and alternatives like Sciter to Electron.
You can hate on Electron all you want (I do too) but it's a totally different beast to almost all these other solutions. It's all fun and games until you realize that to get half the junk Electron throws you for free, you'll wind up building it yourself in these solutions.
Arguments like these are a lot more compelling when they include some specific features that are missing. Too often, "includes everything you need for free!" translates to "weighs down your binary with a hundred megabytes of functionality no one actually uses."
The argument has been beaten to death by every thread on the topic here, so I don't particularly feel the need to take the bait.
Your comment also implies that I'm cosigning Electron being a bloated slug of an environment; I'm not. You will never unseat it by offering a pale imitation of it in place of it, though - and these comparisons result in little more than that.
* PointerEvent for handling mouse, touch, multi-touch all with a single API
* decodeURIComponent and unescape because my backend sometimes sends ISO-8859-1 cruft and I don't want things to break because of those stupid edge cases
* web animations animate method isn't necessary but boy is it nice for a quick-and-dirty solution
* those insufferable "NS"-suffixed DOM methods because yes, I do need to create SVG elements programmatically now and then
The list goes on and on, running the gamut from "convenient kludge" to "the GUI might not work correctly without this."
The idea of the GUI developer putting up with more obstacles in their quest for a slick-looking UI because they'd like to leverage a slick-looking GUI-toolkit has got to be an anti-pattern.
It depends on the application. I did a couple of projects with Rust's web-view crate (which uses native Safari on MacOS, and native Edge on Windows). This gave me access to the full JS and the full Rust ecosystem. I think the possibilities were richer than if I had used Electron alone. For example, I was able to use the Tantivy crate, for very fast and powerful full-text search. All of this with a fraction of the executable size.
I mean, no: you can do the same stuff with Electron, and you _won't_ be saddled with the issues inherent to WKWebView that Apple still hasn't fixed years later. There are also web features that Safari notoriously does not implement that you'd have access to in Edge.
Webview2 on Windows is also going through a weird period where you can't rely on it "just working" without the end user installing a runtime.
There is a thread, long ago here on HN, where the developer who made the Slack transition from native webviews per platform (which it was, originally, and everyone conveniently forgets) to Electron. He notes it was specifically because cross-platform issues become a pain in the ass to deal with, and Electron avoids that.
There's a disconnect between the average HN commentator who builds a UI in HTML/CSS/JS, and the types of frontends that larger applications build in those languages. Cross platform stuff shows up, and it's not a great use of time when there's one runtime sitting there that does everything and looks the same everywhere.
I don't know why you are being downvoted. Personally I consider Electron to be cancer but this comment is very informative and raises some very valid points. For some reason it is 2020 and there is no fully qualified solution for cross platform desktop application development. Every option has massive downsides, gotchas, rough edges and limitations.
I think the trick may be deciding what to do on the web side and what on the Rust side. In the case I was mentioning, I used the web side only for display. All the file handling, app updates, full-text search, etc., I did in Rust, and it worked very well on both MacOS and Windows (didn't check Linux).
What prevents me from even looking at this link is the 4.5MB executable. Come on. Have you tried to download that amount of data using a spotty mobile connection?
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...