ElectronJS alternative: SciterJS – HTML/CSS/JS in 4.5 MB executable
github.com
github.com
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...
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!
I wonder if the author actually contacted those companies. That is less than $3K from each of those customers listed.
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.
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?
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.
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.
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.
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
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.
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.
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. :-)
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.
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).
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.
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/
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.
If not, though, that would be a pretty big deal.
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.
So is the question above, any practical ideas?
Say you would need to support 2-3 members team of highly professional software developers... Is patreon realistic for that?
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.
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?
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.
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.
See Evan You (Vue.js) for example: https://www.patreon.com/evanyou
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.
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.
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.
BTW: Sciter already works inside Unreal Engine pipeline as plugin: https://sciter.com/see-sciter-lite-unreal-engine-in-theaters...
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.
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.
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!
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.
That's precisely what I did with Sciter development all these years.
"3. release a video of you demo'ing the feature"
That's what the Kickstarter campaign is all about.
"5. if not, you delete it"
Yep :)
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.
Right. That's the GhostScript funding model.
> 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.
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.
Please take part.
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.
> Note that transfer of 1GB of data produces 3kg of CO2.
This is wrong, it's closer to 29 grams of CO2 for 1GB, on average. Of course it depends on the mix of power sources used.
https://www.iea.org/commentaries/the-carbon-footprint-of-str...
It doesn't change the point of the comparison, the smaller size is still good.
[1] http://www.aef.org.uk/downloads/Grams_CO2_transportmodesUK.p...
The average car around here should be in the ballpark of 150gCO2/km, so 29g would be 200m.
> 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.
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.
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...
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.
Fabrice Bellard is a genius, and I really don't like using this word.
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! ;)
Anything else u remember about him?
- 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]).
You can actually run X-Windows, Windows 2000, FreeDOS etc in a browser using this.
His implementation of 4G LTE purely in software is also pretty amazing. https://bellard.org/lte/
His other projects: https://bellard.org/
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
(Edit to update to latest repo)
QuickJS seems interesting, but I couldn't manage to compile it on Windows (without MSYS2).
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.
Like many pointed out electron may be a beast but few important things like system tray, start on boot come inbuilt with electron.
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.
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
As far as red flags go, educate yourself: open source work is unsustainable without external sources of income: https://staltz.com/software-below-the-poverty-line.html
I wish someone did a deep dive (in English) on what this is and how to use it (with focus on disk space and runtime performance characteristics).
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.
Security, for starters.
There is no way around this.
> 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.
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.
[1] https://stackoverflow.com/questions/40325806/how-this-type-o...
That is a no-go for me.
I think HTML is the UI language that will outlive all others in existence.
It would be a mistake to use something else and then have to rewrite everything in some years.
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 and there are a bunch of commercial and free alternatives, but somehow nobody really cares.
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.
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?
which is a way to compile a Node.js executable into an exe on different platforms. Then build a thin server-layer to let bowser serve as your GUI. ?
It looks like this just vanilla javascript and displays html/web pages. Perhaps we can bundle a nodejs program alongside sciter?
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.
Some browser compatibility layer will be required though.
The plan for Sciter.JS is to provide minimal DOM implementation to keep it lightweight.
For example there is no document.getElementsByTagName method but there is document.querySelectorAll.
So if that exact method is needed anyone can add:
Document.prototype.getElementsByTagName = function(tag) {
return this.querySelectorAll(tag);
}
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.
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.
* 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.
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.