Our great sponsors
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
7.css
A JS-independent, tree-shakeable CSS framework for building faithful recreations of the Windows 7 UI.
-
remarkable
Markdown parser, done right. Commonmark support, extensions, syntax plugins, high speed - all in one. Gulp and metalsmith plugins available. Used by Facebook, Docusaurus and many others! Use https://github.com/breakdance/breakdance for HTML-to-markdown conversion. Use https://github.com/jonschlinkert/markdown-toc to generate a table of contents.
-
It does support , with limited support but still.
See: https://github.com/c-smile/sciter-js-sdk/tree/main/samples/c...
Sciter also supports immediate mode painting on any element (like in DearIMGUI):
element.paintBackground = function(gfx) {
> Fabrice Bellard have created his QuickJS embeddable JS engine
Oh. That's the QEMU/FFMPEG Fabrice Bellard? That sounds definitely interesting. (Perhaps more than the actual article, haha.)
https://bellard.org/quickjs/
"custom version of React he publishes..."
It is not a a custom version of React but rather extension of DOM model by just these:
1. Native JSX support. In Sciter QuickJS was extended to support JSX literals out of the box: https://github.com/c-smile/quickjspp/blob/master/quickjs-jsx...
2. Native methods:
- Element.patch(...JSX expression...) - native VDOM reconciliation implementation.
sciter is pretty successful already - https://sciter.com/ lists a number of recognisable commercial users and estimates 340 million installs over its lifetime. i very much doubt it will go mainstream without being open sourced though; closed source is simply a mindshare killer for this kind of developer-focused project.
I’m concerned that you’re falling into the same trap here with integrating your own variant of JSX, and mulling over adding more things like hyphens in unquoted object literal keys.
JSX is popular enough that it’s safe, ECMAScript isn’t going to break it, but your alterations to JSX are already significantly incompatible: you have being equivalent to JSX("input", {"class": "search"}, null), but the JSX everyone else is using has that equivalent to JSX(input.search, {}, null). I’m not certain if your JSX syntax is supposed to be able to be used with React code or anything else that uses JSX syntax, but if yes then it’ll be broken in a significant number of cases so that it’s worse than useless, and if no, well, it’s going to be misleading, and what if JSX did get merged into ECMAScript in some form? Then you’d be incompatible with ECMAScript again.
Same deal with hyphens in unquoted object literal keys: it’s not part of ECMAScript now, but just because it’d be a syntax error now doesn’t mean it always will be. Decorators in TypeScript are a good example of things going badly wrong even when an extremely popular project is involved.
I say: if you want to go JavaScript, go JavaScript, maaaaaybe plus standard JSX conforming with <https://facebook.github.io/jsx/>, and no further. Even if what you do is obviously superior, &c. &c. I’d apply the same reasoning on your fork of CSS: you introduced it for a good reason back then, but now it’s just friction, even if it’s a little better in a vacuum (and maybe it is in parts, maybe it isn’t in other parts).
I see, in this thread, talks about what Sciter does and does not offer.
It's not the only alternative to Electron, but it might be one that offers predictable and repeatable results.
I released a small open source project on HN last week (https://github.com/Fusion/pngsource) and I wrote its backend logic in Go. I built the frontend using Tailwind (https://tailwindcss.com) and DaisyUI (https://daisyui.com) and, using Go compiler flags, I can release the app using both WebView (github.com/webview/webview) (which, yes, does require the host OS' collaboration) and Wails (wails.app) (which also does.)
On Linux/AMD64, the binary's size is 3.7M when building for WebView, and 6.8M when targeting Wails.
The way the app works is I drag/drop files to the UI, magic happens, and I use github.com/ncruces/zenity to prompt the user for a save location.
I cross-compile the apps using xgo (https://github.com/karalabe/xgo)
It's been working pretty well on Linux, Windows, MacOS. I think WebView's approach of limiting the feature set is working well as it feels more "native" than Wails (better refreshes and resize operations for instance)
However, I already have a few tickets reporting that, for instance, the app is displayed as a blank window in some environments. And it's hard to debug remotely, obviously. So, this is where Sciter may be a better option.
I see, in this thread, talks about what Sciter does and does not offer.
It's not the only alternative to Electron, but it might be one that offers predictable and repeatable results.
I released a small open source project on HN last week (https://github.com/Fusion/pngsource) and I wrote its backend logic in Go. I built the frontend using Tailwind (https://tailwindcss.com) and DaisyUI (https://daisyui.com) and, using Go compiler flags, I can release the app using both WebView (github.com/webview/webview) (which, yes, does require the host OS' collaboration) and Wails (wails.app) (which also does.)
On Linux/AMD64, the binary's size is 3.7M when building for WebView, and 6.8M when targeting Wails.
The way the app works is I drag/drop files to the UI, magic happens, and I use github.com/ncruces/zenity to prompt the user for a save location.
I cross-compile the apps using xgo (https://github.com/karalabe/xgo)
It's been working pretty well on Linux, Windows, MacOS. I think WebView's approach of limiting the feature set is working well as it feels more "native" than Wails (better refreshes and resize operations for instance)
However, I already have a few tickets reporting that, for instance, the app is displayed as a blank window in some environments. And it's hard to debug remotely, obviously. So, this is where Sciter may be a better option.
I see, in this thread, talks about what Sciter does and does not offer.
It's not the only alternative to Electron, but it might be one that offers predictable and repeatable results.
I released a small open source project on HN last week (https://github.com/Fusion/pngsource) and I wrote its backend logic in Go. I built the frontend using Tailwind (https://tailwindcss.com) and DaisyUI (https://daisyui.com) and, using Go compiler flags, I can release the app using both WebView (github.com/webview/webview) (which, yes, does require the host OS' collaboration) and Wails (wails.app) (which also does.)
On Linux/AMD64, the binary's size is 3.7M when building for WebView, and 6.8M when targeting Wails.
The way the app works is I drag/drop files to the UI, magic happens, and I use github.com/ncruces/zenity to prompt the user for a save location.
I cross-compile the apps using xgo (https://github.com/karalabe/xgo)
It's been working pretty well on Linux, Windows, MacOS. I think WebView's approach of limiting the feature set is working well as it feels more "native" than Wails (better refreshes and resize operations for instance)
However, I already have a few tickets reporting that, for instance, the app is displayed as a blank window in some environments. And it's hard to debug remotely, obviously. So, this is where Sciter may be a better option.
I see, in this thread, talks about what Sciter does and does not offer.
It's not the only alternative to Electron, but it might be one that offers predictable and repeatable results.
I released a small open source project on HN last week (https://github.com/Fusion/pngsource) and I wrote its backend logic in Go. I built the frontend using Tailwind (https://tailwindcss.com) and DaisyUI (https://daisyui.com) and, using Go compiler flags, I can release the app using both WebView (github.com/webview/webview) (which, yes, does require the host OS' collaboration) and Wails (wails.app) (which also does.)
On Linux/AMD64, the binary's size is 3.7M when building for WebView, and 6.8M when targeting Wails.
The way the app works is I drag/drop files to the UI, magic happens, and I use github.com/ncruces/zenity to prompt the user for a save location.
I cross-compile the apps using xgo (https://github.com/karalabe/xgo)
It's been working pretty well on Linux, Windows, MacOS. I think WebView's approach of limiting the feature set is working well as it feels more "native" than Wails (better refreshes and resize operations for instance)
However, I already have a few tickets reporting that, for instance, the app is displayed as a blank window in some environments. And it's hard to debug remotely, obviously. So, this is where Sciter may be a better option.
It's possible though not straight-forward. React Native Windows seems to have a version of V8 wrapped with JSI (for use in React Native) though by the looks of the project, it appears to be only used internally and not really meant for stand-along consumption: https://github.com/microsoft/v8-jsi
Related tangent: Is anyone aware of any CSS frameworks that are "native-like" and not generic web-based things?
E.g. if I want OS-style UI components + styles like a browser tab-strip or pane splitters or toolbars etc?
There are loads of things out there with UI elements, but they are web-page-UI focused.
The closest thing I know about is https://khang-nd.github.io/7.css/ but that only has a limited control set.
> we can't take some well-tested, used-by-millions library
You can.
Here is an example of Sciter application that uses RemarkableJS library (https://github.com/jonschlinkert/remarkable) as it is:
https://quark.sciter.com/quark-application-samples/hello-mar...
https://framework7.io is really well done.
Related posts
- Faster React apps coding: How to migrate from Emotion CSS-in-JS to Stylify Utility-First CSS
- How to Effortlessly Migrate from Styled Components CSS-in-JS to Stylify Utility-First CSS for Better React Development. | Stylify CSS
- How to Effortlessly Migrate from Styled Components CSS-in-JS to Stylify Utility-First CSS for Better React Development.
- Best Practices for Utility-First CSS
- Using Beautiful Material Themes from Material Theme Builder in Stylify CSS