The biggest drawback is that it only supports a subset of Web APIs, even the DOM APIs. Most sufficiently large libraries that do more than pure compute will use an API that isn't supported, so you can't just import a random chart library. Of course fixing that is a sisyphean task for a single-developer project like Sciter.
I still really like it, but if you use it be prepared to either modify the libraries you use or write your own code.
Even bigger drawback is that it ain't Free, honestly. Sure, the licence allows you to use it if the users install the sciter runtime separately, but that ain't really am option beyond development imo.
Of course static linking would be nicer, but I think it's fair to charge money for that (as well as for source code access). The project has to finance itself somehow.
Incorrect. Linux doesn't care where you load a .so from. You could load it by using a path, or you could add a path to your LD_LIBRARY_PATH env var. You could even add it to your compiled binary's RPATH. All methods support relative paths. The latter requires a binary, but the first two work with nearly all scripting languages.
Also think about a software tool that costs say $100. It ain't free but that's your hourly salary Mr. Professional Developer. Using only free tools is penny-wise and pound foolish.
The trouble is that everyone wants to be a landlord these days by charging rent instead of allowing you to buy a copy of the software.
Every new feature also adds complexity and size, so it goes exactly against one of the main advantages of the project
Also, whatever you write won't then be usable in normal browsers. So it's essentially just another cross-platform UI library, with a DSL for the UI parts - of course that's still good enough for many people.
As a web dev, I agree 100%. It's a mess.
> That's not a problem, but a very big plus.
...but if your business need/use case is to port with your existing web app to the desktop with minimal fuss (and you're willing to sacrifice UX), this in no way helps (unlike Electron). If you're going to have to manually rewrite everything for the desktop anyway, why would you want to do it in the DOM, using an older HTML version, a CSS subset, and a somewhat-compatible JS-lookalike? Why wouldn't you just write it in a desktop-native UI kit?
I pretty much understand this point and see that Electron help. I would definitely write desktop-native UI, maybe just because I prefer it. And in large programs it might be somewhat expensive. But on the other hand, I found writing QT programs to be much easier than messing with web stacks.
IMO React is a response to a problem that not all websites have (complex state-dependent nested UIs). At a certain level of complexity it's worth it, at another level it's necessary, beyond that it's insufficient... but below that it can totally be unnecessary and more pain than it's worth :)
Go with what works for you and your team!
If you can't reuse the same code between web and the desktop, you might as well use a better desktop framework. This just creates a false positive lookalike that is surface-level compatible but really not reusable and maintainable, and trying to figure out which APIs are shared and which aren't would be more work than just working in a different language & environment altogether.
Was more considering it from the perspective of web-native companies wanting some offline/desktop experience too
Sciter isn't exactly a custom browser engine, because it lacks many, many APIs that browsers would use. It just happens to also use HTML & CSS, but it's not Servo-lite or Chromium-lite with V8 slapped on.
sciter is good if you are looking for make an app based biz which not depends too much on web spec.
EDIT: small app -> app biz
Not every feature needs to be supported, which feature are you referring to? Also, given the use case: what is required in your opinion? How does the shift in microsofts scope translate to the efforts to sciter? What did the shift imply?
> sciter is good if you looking for make a small app which not depends too much on web spec.
Since when is it a feature to comply to "web spec"? Why should anyone continue to comply with all new requirements? And why do you feel it is required for portable desktop applications? Why not settle on some proven essentials? And why I am talking about browser now?
Hopefully you elaborate your thoughts: I am sincerly curious about your opinion.
There are several cases why I prefer an electron: BrowserView, FileSystem api, newer css feature(Interop 2022 are greate), and all the newer js feature I use but I don't know it.
I'm a web dev, so I'm not comply to web spec but chasing it, as a web dev, I'm happy about this, so I take the web spec as granted.
If I'm building a app biz company, I may choose sciter. sciter is not "free" to use, I remember sciter used to tring allowed the static linking if the donation is good enough, but seems not reach the goal, which means can not get a static exe like https://github.com/wailsapp/wails .
BTW, I'm sorry for the small app part, small should mean adapt or bend to sciter.
> I'm a web dev, so I'm not comply to web spec but chasing it, as a web dev, I'm happy about this, so I take the web spec as granted.
Okay, now I see: As a web dev you are able to make use of all these new features. I do not know about current conveniences. FWIW is that CSS should be portable across any browser/web view. And given that browsers nowadays occupy tons of memory (even though they are written in highly performant languages) I am still impressed by sciters small shipping size.
> If I'm building a app biz company, I may choose sciter. sciter is not "free" to use, I remember sciter used to tring allowed the static linking if the donation is good enough, but seems not reach the goal, which means can not get a static exe like https://github.com/wailsapp/wails .
Thank you for the recommendation!! It appears to me that his previous attempts to market his product have left a serious impression. I do remember stumbling about sciter a while ago, neglecting it as well. But I can't recall my reasoning.
> BTW, I'm sorry for the small app part, small should mean adapt or bend to sciter.
No worries, thanks for your input!!
Chrome is new IE since June 15 2022, and happy about it. Interop 2022 is about make safari and chrome get on the same page about new css feature.
Memory, portable CSS and browser compat is about cost, if I can make whole company install chrome, that can save a ton of money investing on support unexpected browser, one time install is way cheaper than continue support. If the company is big enough, there will be no problem, like google can rewrite whole Google Doc to canvas to support cross browser. If building a sciter based app biz, that's all your investing goes, that make sense.
[Interop 2022]: Blog https://web.dev/interop-2022 Current status https://wpt.fyi/interop-2022
(he also hangs out on HN)
It supports multiplatform app development with HTML/JS/CSS and the entire engine's runtime is just about 5MB which is unbelievably small!
I further analysed how this was possible, what I found was beyond fascinating.
1. The author has wrote a compiler that supports JS with useful extensions like classes and fancy stuff, even before ES6 came into existence.
2. He had built his own layouting engine that understands HTML and CSS 3.0
Basically he's built a custom browser engine, but custom tailored for writing multi-platform apps. So it's super-fast without as much memory taxes. It's not backed by a BigCo or a huge community (I guess) and I'm not sure whether I'll pick it for a business critical app. But the way it's architected seems far superior than the shortcut approaches that Electron or most other alternatives take.
The project is not even new. It's more than a decade old which itself is amazing.
[1] https://sciter.com