[HN Gopher] Show HN: Svelte NodeGUI, a lightweight Electron alte...
___________________________________________________________________
Show HN: Svelte NodeGUI, a lightweight Electron alternative with
native UI
Author : LinguaBrowse
Score : 581 points
Date : 2021-03-05 20:10 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| fuckccp wrote:
| If you can't reuse/share a lot of web
| technologies/stacks/libraries. Why would you not go for flutter
| instead
| f430 wrote:
| How do you deal with zero day vulnerabilities? To me the biggest
| concern using browser-as-a-desktop solution is that there will be
| quite a lag between when Chrome patches zero days vs when it gets
| released.
|
| ex) nw.js, electron.
| capableweb wrote:
| > To me the biggest concern using browser-as-a-desktop solution
|
| Then this project sounds perfect for you because it's not a
| browser, it's Qt5 but called via APIs that JS developers are
| used to.
| f430 wrote:
| Isn't it rendering html5/javascript like a browser would? it
| would be great if somebody could take time to reply and
| explain things in a calm logical manner without reaching for
| downvotes
| Aeolun wrote:
| I think nobody wants to tell you since it's something that
| is easily found on the linked site.
|
| To answer your question, there is no more HTML involved in
| this than in a React Native app. The result _looks_ like
| HTML, but it's really used to compose native OS widgets.
| f430 wrote:
| my bad i saw the github but couldn't find any code
| examples other than someone smiling
| ZachS wrote:
| What sort of vulnerabilities are you worried about? You're
| running trusted code, connecting to a trusted service via
| https. Not browsing arbitrary websites. I doubt many
| vulnerabilities would affect this.
| f430 wrote:
| > trusted service via https
|
| you think that would stop a zero day vulnerability? if you
| have browser that won't be updated for a long time and its
| connected to the internet, it is a huge attack surface.
|
| Unless you were running local static file without ever
| talking to the internet.
| endisneigh wrote:
| Is there a way to have some small application that talks to the
| machine via a set of HTTP apis?
|
| I envision something where you can just use your regular web app,
| have the user install the "Desktop Connector" which would be
| listening at say, port 8000 - then your web app can talk to the
| desktop via those APIs, instead of installing an Electron or
| related.
|
| I must be missing/forgetting something crucial since that seems
| like the most straightforward solution imaginable.
| marcthe12 wrote:
| Yes it possible. The main issue basically as all app basically
| on one domain localhost so USC can be bad
| jiofih wrote:
| Chrome used to have a local socket API when chrome apps were
| still a thing.
| beaconstudios wrote:
| the HTML5 JS APIs provide most desktop functionality you could
| want to access from the browser - does that cover what you
| mean? Reading location, video & audio, interacting with local
| files, that sort of thing.
| frosted-flakes wrote:
| Stuff like global keyboard shortcuts still isn't possible
| though. And you're stuck with the browser's notification
| system.
| danenania wrote:
| There's nothing stopping you from doing this with a server on
| localhost. You just need to think a bit about security (and be
| _extra_ careful if you 're running a websocket server since
| they don't do origin checks by default).
| LinguaBrowse wrote:
| Yep, you could make an HTTP server using Express.js, and a
| minimal GUI to go with it!
|
| Of course, it could run headless, too. But there is attraction
| in making it an app that opens like familiar executables.
| julienb_sea wrote:
| I mean you are basically just describing a standard local
| development setup, so in a lot of ways this is trivial. The
| trouble would be trying to package that up in user-friendly
| manner. It's definitely more work than it's worth, in a world
| where most people have computing resources to spare on a heavy
| framework like Electron.
| ficklepickle wrote:
| Dell uses this exact technique on Windows to launch/interact
| with their driver installation tool from the web. That has
| decent UX because it comes pre-installed. But, generally, users
| aren't accustomed to this pattern and any user education
| requirement is often a non starter in many market segments.
|
| It also has security implications if you are exposing OS
| functionality to websites. I remember Dell having a bad one a
| couple years ago.
|
| There is also an antivirus browser extension that works in a
| similar way. It installs a native C++ executable that the
| extension interacts with. That has a huge security footprint.
| IIRC they rolled their own parser (HTML?, JSON?) and it went
| predictably bad.
|
| There are lots of implications to consider. I'd like to see
| progressive web apps fill this niche on the desktop. They have
| various mechanisms for persistence of data and WASM will
| increase the practical use cases. Hopefully the APIs available
| to PWAs in the future will allow all sorts of new use cases.
| jackconsidine wrote:
| Very cool, I've been following React-NodeGUI for about a year now
| and I love Svelte.
|
| I especially love the idea of Svelte (compiling to imperative
| JavaScript code), but since it's technically a "superset" of
| JavaScript, IDE support has been an issue for me. Also I've cut
| my teeth trying to find a solid UI component library. These two
| things have restricted my use of the framework to smaller
| projects.
|
| Anyone have any suggestions?
| LinguaBrowse wrote:
| In terms of IDE support, VS Code with the Svelte extension is
| the best around!
|
| A component library is a bit much to come until Svelte NodeGUI
| gets a bit more attention. Even Svelte web projects are
| underpopulated on component libraries, I believe. But it's
| worth trying out the built-in primitives first!
| omneity wrote:
| It's unfortunate but the component library situation is really
| Svelte's weak point currently.
|
| At Monitoro[0] we bit the bullet and implemented the vast
| majority of our components from scratch. Apart from the obvious
| time to develop and test, and the trailing bugs that are hard
| to solve for small closed source projects, the experience
| wasn't that bad.
|
| Ultimately what helped us the most is writing our components
| using a state machine-like pattern, mixed with TailwindCSS to
| make styling easier.
|
| In our case, the effort was worth it as we anyway needed
| several super specific components, and now that we're over the
| hill we have complete control on our UX.
|
| (Also having built component libraries/design systems before in
| different UI frameworks, doing it in Svelte was one of the best
| experiences so far)
|
| There are some efforts in the Svelte ecosystem but they're
| small and do not have much firepower behind, thus limited or of
| relatively low quality.
|
| [0]: https://www.monitoro.xyz
| jackconsidine wrote:
| Word, thanks! I think it's interesting because Svelte
| community support is pretty big. The repo's consistently been
| on Github's Trending repos for the past 2.5 years and it has
| an impressive number of stars
| capableweb wrote:
| > been on Github's Trending repos for the past 2.5 years
| and it has an impressive number of stars
|
| Wow, must mean the project is real important. I agree that
| svelte is interesting, but focusing on metrics and
| popularity is the wrong approach to new technology.
| jackconsidine wrote:
| You can't judge a technology by its popularity. But I was
| judging the _ecosystem_ by its popularity and those
| things are very highly correlated. More people
| bookmarking a project mean in theory it should have
| better 3rd party library support.
| capableweb wrote:
| You're judging the ecosystem based on the
| stars/trendiness of Sveltes repository? That feels even
| more wrong and you're doing a lot of extrapolation here.
| zeroc8 wrote:
| No suggestions, unfortunately. The lack of a comprehensive UI
| component library a la PrimeReact/NG/Vue really is a
| showstopper. Doesn't have to be free. But component providers
| do not seem to care about Svelte.
| chovybizzass wrote:
| how about deno?
| danenania wrote:
| Looks really good! At first glance, this seems like probably the
| best Electron alternative I've seen posted on HN.
|
| Apart from the consistent GUI layer, I think an underrated reason
| that many teams stick with Electron is the mature tooling for
| cross-platform builds and upgrades. It's pretty painful to DIY.
|
| It looks like NodeGUI doesn't currently support cross-compilation
| --is that something that's on the roadmap? How about
| upgrade/auto-upgrade tooling? Code signing?
| davej wrote:
| Strongly agree. Hello World apps are great but it would be even
| better to see a Hello World tutorial that can actually be
| distributed to customers. You probably also need auto-update,
| native installers, code signing (notarization on Mac) and the
| ability to build native modules cross-platform.
|
| This is a super-interesting project though.
| capableweb wrote:
| Sure, would be great if everything had everything we need at
| creation. But this is first a Show HN from a user here and
| secondly open source software, so I think you need to adjust
| your expectations a bit.
|
| Agree with your final part, very exciting and gonna be
| interesting to see where nodegui goes, especially security
| wise.
| davej wrote:
| This is awesome. Props to the authors. My comment was not
| meant to knock on this project. I'm just pointing out that
| people should consider distribution if they want to use a
| tool like this. Putting a desktop app in front of customers
| is not yet as easy as it is on the web but I'm working on
| making it better [1].
|
| [1] https://www.todesktop.com/cli
| jiofih wrote:
| Both the App Store and Microsoft Store deal with installs and
| updates, no need for custom wrappers. Not sure about Linux.
| davej wrote:
| End-users are still more familiar with a download link on a
| website for a exe/dmg installer on desktop.
|
| You also need to need to redo your subscription/payments to
| support the stores and give a percentage of your revenue to
| Apple/Microsoft. On mobile you have no option but on
| desktop it's hard to justify giving up so much of your
| profit margin when there's a popular alternative.
|
| BTW, Linux has the Snap Store.
| jiofih wrote:
| Hmm I really don't think so. You might be thinking of
| tech people, not the general public.
| heavyset_go wrote:
| All of the non-technical people I know are capable of
| installing software on desktop computers without using
| app stores.
| hanniabu wrote:
| I have a mac laptop and windows desktop and I never use the
| app stores.
| IggleSniggle wrote:
| I have used each of them exactly once. In both cases, it
| was to purchase an OS upgrade.
| jiofih wrote:
| You're the HN audience.
| m00x wrote:
| Flutter isn't a good Electron alternative? Flutter 2.0 just
| came out with desktop support for osx, windows and linux and
| will be the main GUI framework for Linux.
| heavyset_go wrote:
| > _and will be the main GUI framework for Linux._
|
| That's already GTK+ and Qt, and the big GTK+ and Qt projects
| aren't switching over to Flutter any time soon.
| IshKebab wrote:
| Not yet. Or rather, I would say you can use it for simple
| stuff, like Etcher then it is a reasonable choice. But you
| wouldn't want to use it for something like Slack yet. Some
| basic stuff like ctrl-Z in text fields does not work yet.
| Doing normal desktop things like menus and file dialogs will
| be a pain.
|
| That said, I am writing a Git desktop client in Flutter and I
| like it. But I don't expect to finish it for many years so
| hopefully by then they'll have ironed everything out.
| rudedogg wrote:
| There was a lot of criticism, especially of the Web version,
| in https://news.ycombinator.com/item?id=26332944
| porphyra wrote:
| Looks very slick, but I am extremely stressed out by the
| inconsistent font sizes and button spacing across platforms in
| the example calculator app.
| benrbray wrote:
| I think this is part of why many people stick with Electron
| instead of Qt in the first place. Nevertheless, a really cool
| idea. I will jump ship from Electron as soon as the first
| viable alternative emerges. However I haven't yet seen a
| wysiwyg text editing framework that can hold a candle to
| something like ProseMirror, so for my use case that might be a
| while.
| gigel82 wrote:
| I've been following react-nodegui since it was announced and I
| really like it. In terms of memory usage it's the cat's meow; now
| there's a question of adoption and component / UI libraries for
| the ecosystem.
|
| Perhaps a way to bootstrap that would be to align closer to
| react-native; at that point, we could use (js) components and
| libraries from react-native land.
|
| The QT licensing question is also somewhat iffy; you need to put
| front and center what that implies for users of your library (do
| they need to open source their use of react-nodegui by extension
| of QT's licensing requirements for example).
| kall wrote:
| Since you seem to be familiar with both, can you say something
| about what react-nodegui offers compared to react native?
|
| Is it just way simpler to use, like electron? Or does QT offer
| a more consistent cross platform experience? Or is it more
| mature than react-native-macos? Or for when you want to run on
| linux?
|
| All things that could be appealing to me if it did that.
| gigel82 wrote:
| react-nodegui is much simpler to use and more compatible
| because there's just node underneath, whereas react-native
| has varying js engines per-platform and a large library
| straddling the native-js bridge that reinvents things like
| Promise or XHR (it also cannot use native node modules). This
| reinvention also adds to the bloat (the calculator sample
| uses around 50Mb RAM with react-native-windows vs. 15Mb with
| react-nodegui, but it's a Store / UWP app whereas nodegui is
| win32 so it's not apples-to-apples).
|
| However, react-native does have a sizeable addon ecosystem
| including UI frameworks (nowhere near web, but definitely
| more than nodegui's zero).
|
| I didn't try react-native-macos, but I am using react-native-
| windows, which is functional enough and lets us share code
| between iOS, Android and Windows (I want to try react-native-
| macos but it looks like it doesn't get as much investment as
| windows).
| kall wrote:
| Thank you. A more lightweight model is very appealing to
| me. I just started a react-native-macos experiment, and
| it's not as smooth as iOS. The tooling alone on a multi
| platform, non expo RN app... Does react-nodegui offer
| straightforward builds like electron-builder?
| ssss11 wrote:
| Just thought it was worth mentioning that nodegui is a node & qt
| runtime. There are framework components for not just Svelte, but
| React and Vue as well... just search on github if you prefer a
| different framework.
| singularity2001 wrote:
| Is there any electron like framework which uses the native
| webview libraries (webkit etc) instead of shipping their whole
| browser for each application?
| hybridtupel wrote:
| I guess Tauri [1] is like what you are looking for. Was
| featured here a a few days ago [2].
|
| [1] https://tauri.studio/en/
|
| [2] https://news.ycombinator.com/item?id=26194990
| Schampu wrote:
| There is a WebKit based HTML renderer called Ultralight. It
| works by creating hooks and intercepting the rendering calls of
| WebKit in order to allow embedding it easily.
|
| Unfortunately the license of Ultralight is questionable, and
| it's not open-source either by bypassing the WebKit license
| (which is very questionable as well since WebKit itself is BSD-
| licensed).
|
| Having such a project as a free open-source variant would be a
| huge game changer in my opinion.
| radiKal07 wrote:
| I think Flutter Desktop is also a good alternative to Electron
| jart wrote:
| I'm seeing a lot of Qt vs. Chromium in this thread. Here's your
| mindblown.gif of the day: Chromium is based off Webkit which is
| based off KDE which is based off Qt.
| https://en.wikipedia.org/wiki/KHTML
| anthk wrote:
| On GUI's, if Go had some GUI a la inferno (no, not the crap of
| node, the one from the Unix/C/Plan9 guys), it would be the best
| thing ever on interfaces.
| capableweb wrote:
| Agree, there is a linage. But to say they are similar because
| of that is like saying Fortan and Ruby is similar because of
| the shared heritage. Still useful to compare them if you have
| to.
| jart wrote:
| Ruby isn't a fork of FORTRAN and Ruby isn't written in
| FORTRAN. The lineage from Qt to Chrome is both those things.
| It's more than heritage it's an origin story.
| rado wrote:
| Calculator demo doesn't run, makes some cmake errors.
| gigel82 wrote:
| The react-nodegui calculator example runs fine for me; on Win10
| x64 it uses 14.4Mb of RAM and spawns a single process.
|
| Really impressive resource-wise, now let's get the UI
| components / frameworks ported...
| karteum wrote:
| This looks nice !
|
| However... "Low CPU and memory footprint (...) memory usage is
| under 20 MB for a Hello World program" : I am the only one who
| still thinks this is huge ? (->
| https://tonsky.me/blog/disenchantment )
| OOPMan wrote:
| It is huge.
|
| After doing web dev for years I wrote a desktop application
| with Qt.
|
| It's not massively complex (but a lot more complex than a hello
| world) but when it's running the memory usage is very low even
| compared to 20mb
| agumonkey wrote:
| It's probably to be put against Electron HelloWorld resources
| usage. If this project manages to cut it in half then it's a
| good step. Maybe competition will cut it in half once more.
| Considering the amount of Electron based apps around it can
| save quite a few GB worldwide :)
| conradev wrote:
| On a 2560 x 1600 screen showing 8-bit RGBA, a single full
| screen buffer would be 15 MB:
|
| (2560 * 1600 * 4) / 1024 / 1024 = 15 MB
|
| So no, that is not huge for a modern GUI program.
| [deleted]
| lhorie wrote:
| That actually sounds kinda impressive, considering [0] says a
| minimal standard Qt hello world app is ~5mb and stock node.js
| is ~100MB.
|
| I'm curious what kind of magic is happening where node.js is in
| the picture yet the executable comes out at ~20MB. Is it simply
| a bundle of wrappers for most of Qt with Node.js being required
| to be installed separately? Is it purely UPX compression?
|
| [0] https://stackoverflow.com/questions/450455/minimal-qt-
| execut...
| lhorie wrote:
| Poked a bit more. It seems the 20Mb claim is indeed mostly
| only about runtime memory, and doesn't translate to
| equivalent disk usage.
|
| The entry point in ther starter kit calls qode (a fork of
| node), which talks to qt via napi (node's API for c++
| bindings). It can be distributed as binaries via the
| *-deployqt toolchains.
|
| So for distributable binary size in disk, we're probably
| looking at something in the ~100mb range with no UPX
| shenanigans.
|
| So, tl;dr not as magical as I initially assumed. The trade-
| off between "bloat" vs ability to use web paradigms feels
| like a reasonable one. Overall pretty cool stuff.
| jiofih wrote:
| A node OS X build is 13mb, 20mb on Linux.
| lhorie wrote:
| Are you looking at tar.gz files in nodejs.org/dist? Those
| are compressed. "Get info" on the actual binary on my OSX
| gives me a number closer to 80MB.
| mhh__ wrote:
| The trick is really whether 20MB is the short end of bad graph,
| or a constant offset on the end of a good trend.
| mrwoggle wrote:
| I just made hello world window in qt. It's 28 kB. edit: typo
| jart wrote:
| 28kb? You're only seeing the tip of the iceberg. I just built
| Qt Hello World myself. It's about sixty megabytes in size.
| jart@debian:~/scratch/qtproject$ qmake -project
| jart@debian:~/scratch/qtproject$ make
| jart@debian:~/scratch/qtproject$ ldd ./qtproject | grep -Po
| '(?<==> )[^ ]*' | xargs ls -alH | awk '{x += $5} END {print x
| / (1024 * 1024.)}' 59.5916
|
| That's bigger than I expected to be honest.
| jcelerier wrote:
| Aren't you also listing all the non Qt libs here ? X11,
| libinput, pulse audio, dbus, gstreamer, OpenSSL... e.g.
| here on linux for a static build of Qt (which links against
| both X11 and wayland platform plug-ins, and uses an
| embedded libpng, harfbuzz, freetype, etc...) a QWidget
| hello world comes out at 14 megabytes.
| makapuf wrote:
| Id say its fair game if building hello world links those
| gstreamer and openssl.
| jcelerier wrote:
| > Id say its fair game if building hello world links
| those gstreamer and openssl.
|
| why ? it entirely depends on how your linux distro chose
| to build Qt, not on Qt itself.
| makapuf wrote:
| OK, so _in this context_ the app is X MB. If all distros
| link those libs with libre cote and ui, for all intents
| and purposes, it takes X MB. If some dont, then lets
| discuss it (but if you _can_ link to gstreamer and
| openssl to build a hello world, the issue is not entirely
| on the distro shoulders)
| EvilEy3 wrote:
| Because application can't run without those libraries.
| It's like comparing Java application without taking JVM
| into account.
| jcelerier wrote:
| > It's like comparing Java application without taking JVM
| into account.
|
| no, it's not. The "equivalent" of the JVM would be the
| libQt5{Core,Gui,Widgets...}.so ; but here we are talking
| about the operating-system-provided libraries, so it is
| like comparing with a Java application, with the JVM, and
| also for instance all the MS Windows system libraries, or
| all the macOS frameworks like CoreFoundation, etc etc.
| fabiospampinato wrote:
| The thing is nobody actually uses hello world programs, by
| the time you build a real application the difference in RAM
| usage between that and a good Electron app for example blurs
| significantly.
| tonyarkles wrote:
| Looking at a few things on my machine right now:
|
| - Emacs (with 251 open files and IRC running): 100MB
|
| - Activity Monitor: 98MB
|
| - Word: 227MB
|
| - Spotify: 465MB
|
| - Slack: 526MB
|
| - Thunderbird (not Electron, but a similar weird browser
| hybrid thing): 663MB
|
| - Teams (which appears to be Electron): 747MB
|
| I'm not seeing too much of a blur here. The worst chat app
| (Teams) is using ~7x the RAM of my primary code editor that
| also is doing chat :).
| AZ-X wrote:
| Get-Process WINWORD
|
| PM(K) ----- 51600
| fabiospampinato wrote:
| What some people actually build with Electron doesn't
| really say much about what people _can_ build with
| Electron.
|
| You can't just compare Emacs with Spotify here, I can't
| even scroll a list in Spotify without seeing it
| disappearing on me momentarily, that says more about
| Spotify's engineers or project managers than it says
| about Electron.
|
| Teams and Slack kind of address the same problem and I'm
| seeing wildly varying numbers reported by you, without
| knowing anything about how you are using those apps those
| numbers are meaningless in my opinion, and if you think
| they are meaningful then clearly you can achieve
| different results despite addressing the same use case
| with the same technology stack.
|
| Also there's "chat" and "chat", there's a reason ~nobody
| uses IRC anymore compared to Slack, they are not the same
| thing, and it's not just that Slack is easier to use.
| jcelerier wrote:
| > What some people actually build with Electron doesn't
| really say much about what people _can_ build with
| Electron.
|
| no, it does. anyone can build incredible apps on any
| tech, given infinite budget and time. What matters is how
| the average app behaves, and for electron it is much
| worse than the average Qt app for instance.
| fabiospampinato wrote:
| That argument makes no sense to me, do you think you'd
| change your mind on Electron if access to it were
| restricted only to very intelligent and motivated people
| who made very good apps then?
|
| The average Qt app would probably be close to the average
| Electron app if Qt attracted the same kinds of people,
| i.e. Electron is basically just easier to use and/or the
| developers picking it think they are getting more value
| out of it.
| jcelerier wrote:
| > That argument makes no sense to me, do you think you'd
| change your mind on Electron if access to it were
| restricted only to very intelligent and motivated people
| who made very good apps then?
|
| but that's not the world we live in - everything has to
| be considered in that context and not in the abstract, in
| order to make any sense. Consider musical instruments -
| you can technically make great music with literally
| anything. But if, say, 80% of what people are doing with
| a given instrument ends up sucking, the problem lies more
| in the instrument than in the people, even if a very
| talented (and dedicated) 20% is able to make symphonies
| with it.
| tonyarkles wrote:
| I'll flip this around. Can you think of any Electron apps
| that aren't hugely bloated as examples of Electron-done-
| right?
| fabiospampinato wrote:
| I think vscode is pretty good.
| tonyarkles wrote:
| Heh the embarrassing thing for Teams in this case is that
| I'm signed into one team that doesn't really use it for
| anything but conference calls, while I'm also signed into
| 8 or 9 heavily used Slack groups.
| inetknght wrote:
| I disagree. I remember using lots of GUI apps within a 96MB
| budget 25 years ago -- even browsers.
|
| Electron does not provide that much more desired features
| than apps from 25 years ago.
| fabiospampinato wrote:
| You can make a very decent Electron app with roughly
| (roughly = ~2x or less) that amount of RAM too if written
| well, for that you get pretty much a codebase that you
| can use everywhere, which on it's own is _massive_.
| ficklepickle wrote:
| I've noticed Signal Desktop only uses 100mb. That is
| quite good for an electron app. A simple server-side node
| process will use at minimum ~20mb, which obviously does
| not include a browser.
|
| It's open source, I've been meaning to poke around and
| see what they are doing differently.
| fabiospampinato wrote:
| There's no secret really, just don't import junk
| dependencies like most people do and spend some time
| inspecting your memory usage every now and then, with
| very little effort you'll probably cut down on your
| memory usage significantly by doing that. With a lot more
| effort often you can probably even make something faster
| than uses less memory than a supposedly native app (if
| they spent less time than you optimizing it).
| tuxychandru wrote:
| Signal desktop runs as multiple processes. Did you add up
| all their memory consumption? On my Debian laptop, Signal
| processes consume about 700 MB of RSS in total,
| immediately after starting.
| MaxBarraclough wrote:
| > Electron does not provide that much more desired
| features than apps from 25 years ago.
|
| That's true, but advanced GUI features aren't Electron's
| selling point. It's used because it offers easy
| portability and the ability to leverage web-dev skills.
| fouric wrote:
| What does Electron offer in terms of portability that
| SDL2 doesn't have?
| alvarlagerlof wrote:
| The larger point is ease of use
| fouric wrote:
| Fine, "What does Electron offer in terms of _easy_
| portability that SDL2 doesn 't have?"
| opheliate wrote:
| Accessibility would be my immediate thought, although I'm
| not massively experienced in terms of GUI programming, so
| I could be off the mark here.
|
| With something like SDL2, I would have to interface with
| each operating system's accessibility API directly, in
| such a way that's not easily portable, unless I bring in
| a separate library. Even something like GTK has this
| problem on platforms other than Linux. With Electron, I
| know that my program will be accessible wherever
| Chromium's rendering of HTML is accessible, which is a
| lot more places than anything I'm going to be able to
| bodge together.
| MaxBarraclough wrote:
| SDL is intended for gaming and similar applications, it
| isn't intended for general purpose GUI development.
| That's what toolkits like Qt and GTK are for. These
| toolkits do compete with Electron.
|
| With the disclaimer that I don't know a lot about this:
| Electron has solid support for both desktop and mobile
| targets. I don't think Qt's mobile support is as good,
| but I might be mistaken.
| korijn wrote:
| NodeGui (which is used here) is also running on Qt.
| pier25 wrote:
| A couple of years ago we switched an Electron/Cordova
| application to the native OS Webview (WKWebView on macOS and
| iOS, etc). The UI was written with Inferno + MobX and the
| backend in Swift/C#/Kotlin depending on the platform.
|
| IIRC on macOS it consumed less than 15MB.
| bflies wrote:
| 20 compared to the typical 80mb electron footprint is 4x
| better.
| pqb wrote:
| @tonsky is right about the huge memory footprint (in terms of
| RAM) but 20MB for Hello World GUI program is totally fine today
| [0]. In my humble experience there is really hard to fit in
| below 10MB with a GUI app that only displays "Hello World"
| text, while the next 10MB are often consumed for extra
| resources like font, rendering cache or custom textures.
|
| It might a bit rude to remind that, but the same person saying
| aforementioned words about huge memory usage promotes the Skija
| [1], Java-based GUI toolkit, which is even worse in memory
| consumption than electron (jb-compose provided examples, even
| in release builds).
|
| [0] Memory Footprint of GUI Toolkits -
| https://szibele.com/memory-footprint-of-gui-toolkits/
|
| [1] Graphics for JVM - https://tonsky.me/blog/skija/
| EvilEy3 wrote:
| Compose is alpha tech. Even more alpha than it is on Android.
|
| Electron has been around what? 7 years?
| fouric wrote:
| 20 MB is less than 0.25% of my desktop machine's memory, and 2%
| of a 2010-era netbook. 20 MB, while much larger than what it
| has to be, is tiny even by the standards of decade-old
| computers.
|
| RAM is cheap and plentiful. If you don't use it, its value is
| almost zero (the "almost" comes from OS-level caching of files
| and CPU-level cache misses of code).
| reaperducer wrote:
| HN: "RAM is cheap and plentiful."
|
| Also HN: "The MacBook Pro is worthless if I can't get it with
| at least 64GB of RAM."
| square_usual wrote:
| Those don't seem contradictory to me. RAM is cheap and
| plentiful, and getting 64GB of RAM is easy, but Apple just
| doesn't want to sell that config right now. You can still
| get a 64GB config on another system.
| jbverschoor wrote:
| Everyday users don't get Ram upgrades. Many programmers
| are elitist snobs without any consideration for the end
| user
| AZ-X wrote:
| Go back to Year 2000, Jobs may laugh and agree with
| disagree. Now Year 2021, HN: "Noodle JS is centenary and
| memories are around it"
| ric2b wrote:
| > If you don't use it, its value is almost zero
|
| But the value is also zero if you're using extra for no
| benefit. Actually it's negative, because it prevents other
| programs from using it.
|
| You should try to use all your RAM, yes, _but in ways that
| are actually useful_. The OS can always use leftover RAM for
| caching frequently used files if you don't have a better use
| for it.
| badsectoracula wrote:
| > RAM is cheap and plentiful. If you don't use it, its value
| is almost zero (the "almost" comes from OS-level caching of
| files and CPU-level cache misses of code).
|
| I have fond memories of my DOS days and the simplicity
| inherent in a single tasking environment, however nowadays
| operating systems allow for more than a single application to
| run at the same time and each application should play nice
| with the system resources, so even if RAM is cheap and
| plentiful it doesn't automatically mean that every
| application should feel entitled to it.
|
| (and also even during the DOS days we had TSRs which had to
| be RAM conscious too)
| jug wrote:
| In case this discussion is still about a 20 MB RAM NodeGUI
| application, I don't think this is a comparable situation
| because DOS was really not about developing cross-platform
| applications with a Turing complete styling language. It
| was about building text mode tools that ran on x86 and
| nothing else. I swear even the "bloated" Windows 10 will
| have absolutely no trouble running a Win32 Console
| application at < 1 MB RAM consumption but that's not what
| this is about.
| badsectoracula wrote:
| My reference of DOS was tongue-in-cheek and i made it
| because it only allowed a single program to run (ignoring
| TSRs) at any time so programs using all the memory wasn't
| much of a problem.
| Klonoar wrote:
| >and each application should play nice with the system
| resources, so even if RAM is cheap and plentiful it doesn't
| automatically mean that every application should feel
| entitled to it.
|
| Yes, you shouldn't be a bad neighbor, but the OS will
| generally move things around to accommodate you as
| necessary. RAM is an afterthought for most of these
| applications for a reason.
|
| This attitude is like buying a sports car and never
| redlining it.
| michaelmrose wrote:
| At least on Linux swap is a great tool for shuffling
| things you probably statistically wont use again out
| while retaining the ability to transparently recall them
| if it turns out your system guessed wrong.
|
| If you find yourself in a situation where your OS is
| actually shuffling things around for your system to
| function you will find your performance and desktop
| experience has gone to absolute dog shit. It's entirely
| likely that the user will actually hard reboot the
| machine because they conclude it has frozen.
|
| The absolutely only way to have a nice desktop experience
| in Linux is to ensure you have enough ram for all the
| things you intend to run at once which means have at
| least 8GB-16GB of RAM and don't run too many app once
| from people who think unused RAM is wasted RAM.
| fouric wrote:
| > don't run too many app once from people who think
| unused RAM is wasted RAM
|
| The baseline memory usage of Svelte NodeGUI is 20 MB. 400
| instances of that can fit into 8 GB of RAM. Don't you
| even try to tell me that you've run 400 separate GUI
| applications at once.
|
| Let me repeat it again: unused RAM _is_ wasted RAM. This
| is a fact. It does _nothing_ when neither you nor the OS
| is using it - and the value of the OS using a byte of RAM
| for caching is tiny compared to the value of you using it
| for an application you care about.
|
| The above also has _nothing_ to do with _wasting_ RAM. If
| you 've spent any significant amount of time developing
| programs for actual users (read: not programmers), you'll
| know that development is a complex, multi-variable
| tradeoff - and one of the biggest trade-offs is RAM usage
| for performance, so if you solely optimize for minimal
| RAM usage, you'll _always_ (except for the most trivial
| of programs written specifically as a counterexample to
| this claim) end up sacrificing performance.
|
| The wastefulness of 1 GB of RAM usage varies _wildly_
| depending on whether you 're running a video editing
| program on a large file (hey, that's not that bad!) or a
| simple textual chat application. 20 MB for a graphical
| tool _is an acceptable tradeoff in the vast majority of
| use-cases_.
| badsectoracula wrote:
| > Yes, you shouldn't be a bad neighbor, but the OS will
| generally move things around to accommodate you as
| necessary.
|
| I'm not sure what you mean with that. The OS will not
| "move things around" to the point where the resource
| abuse wont be noticeable, all it can do is swap stuff to
| the disk, perhaps compress some RAM and maybe unload any
| cold code (though code doesn't that that much RAM) and
| all that take time, slowing down the system.
|
| > RAM is an afterthought for most of these applications
| for a reason.
|
| Yes and that reason is disinterest from the application
| developers for RAM usage.
|
| > This attitude is like buying a sports car and never
| redlining it.
|
| Sports cars have nothing to do with this, i do not see
| the relevance.
| oarsinsync wrote:
| > This attitude is like buying a sports car and never
| redlining it.
|
| This is a perfect analogy. To stretch it, the majority of
| sports car owners are developers. The vast majority of
| your users are not.
| Klonoar wrote:
| We can play this game, sure.
|
| The vast majority of cars on the road today have more
| than enough horsepower and can handle being redlined.
|
| Most users have enough RAM unless they're running on some
| absurdly low 4GB< device, which is just nowhere near as
| common these days.
| hypertele-Xii wrote:
| > If you don't use it, its value is almost zero
|
| Yet if you use _all of it,_ its value is also zero - to every
| other program on the same computer. Don 't be a dick; Use
| what you _need,_ not all you _can._
| fouric wrote:
| This is ridiculous. 20 MB is so far from "all of it" on any
| modern computer that it makes me question if you're using
| something from the 90's. How are you even on Hacker News?
|
| The reduction of the complex trade-off between memory use,
| CPU, disk, development environment, ease of deployment, and
| the dozen other variables that go into a choice like
| picking what toolkit to use to "don't be a dick" is so
| absurdly simplistic. It's a _trade-off_ - not a single-axis
| "good or bad" decision.
|
| Moreover, 20 MB of memory usage is going to be an
| acceptable trade-off for the _majority_ of HN users, who
| skew webdev, not embedded.
| texasbigdata wrote:
| Conversely, to the end user, if they could pick a bit more
| resources usage (knowing they can close your app, or heaven
| forbid uninstall it) versus an extra feature what should
| the dev team prioritise?
| mixedCase wrote:
| It's definitely not. It's just a different toolkit that the one
| you already have in memory, so it can't "cheat".
| afavour wrote:
| That blog post does speak to me, but 20MB for a program with a
| truly functional, modern UI doesn't outrage me that much.
|
| IMO there's a tradeoff: we could be writing all our programs in
| C, still. But it would be enormously difficult and there'd be
| way more bugs. On the other end of the spectrum we can be lazy,
| use web tech everywhere and never optimise our ballooning JS
| codebases. This feels like it's at least somewhere in the
| middle.
|
| OT but a bone to pick with that article:
|
| > Modern text editors have higher latency than 42-year-old
| Emacs. Text editors! What can be simpler? On each keystroke,
| all you have to do is update a tiny rectangular region and
| modern text editors can't do that in 16ms. It's a lot of time.
| A LOT.
|
| That isn't what my text editor is doing, though. It's doing
| autocomplete suggestions, linting code as I type... all sorts
| of things we never had a couple of decades ago and are huge
| productivity boosters. Sometimes I feel like people forget
| that.
| naikrovek wrote:
| > That isn't what my text editor is doing, though. It's doing
| autocomplete suggestions, linting code as I type... all sorts
| of things
|
| BEFORE the typed character shows up? Are you _sure_?
|
| 16ms should be an absolute upper bound for a character to
| show up. Everything else comes after.
| andi999 wrote:
| Before the second character is typed...
| spacechild1 wrote:
| No. These things should happen concurrently, probably on
| different threads. If I quickly type "foo", I don't need
| to do run autocomplete and code analysis between each
| character. That would be horrible.
| pjmlp wrote:
| I bet some of those UI coded in Delphi versions targeting
| Windows 95 would be way less than 20MB.
| qw wrote:
| Many years ago I wrote a simple Delphi application that
| used the standard rich text editor. The size was less than
| 150kB
| badsectoracula wrote:
| I might sound like those weird language evangelists, but...
|
| > we could be writing all our programs in C, still.
|
| You don't need to use C, there are other languages. For
| example a hello world in Free Pascal[0] (a natively compiled
| language with no runtime or other dependencies, which
| supports object oriented programming and has RTTI rich enough
| to implement automatic object serialization, semi-automatic
| memory management, strings that know about their encoding,
| etc) is just 32KB.
|
| Some time ago i wrote Fowl[1], a mostly complete recreation
| of the OWL toolkit that came with Turbo Pascal for Windows,
| the demo program of which is around 80KB.
|
| Of course for a more realistic (and MUCH easier to use and
| develop with) approach, you'd need something like Lazarus[2].
| A minimal application in Lazarus is 2.18MB. This might sound
| too big... and TBH it is, but the size doesn't grow too
| quickly from there. For example a profiler i wrote recently
| for Free Pascal applications is... 2.16MB (yes, smaller, why?
| Well, because i replaced the stupidly huge default icon with
| a smaller one :-P and without the default icon a minimal
| application is 2.05MB so the profiler added around 100KB of
| additional "stuff").
|
| > It's doing autocomplete suggestions, linting code as I
| type... all sorts of things we never had a couple of decades
| ago and are huge productivity boosters
|
| FWIW we had those, Visual Basic (or even QBasic) would format
| your code as you type it, Visual Basic 6 and Visual C++ 6
| would profile auto-completion (VB6 even for dynamic stuff),
| etc. Only issue with C++ was that sometimes it wouldn't work
| around complex macros.
|
| But modern editors do a bit more, still no excuse for being
| that sluggish. Lazarus does pretty much everything you'd
| expect from an IDE with smart code completion (e.g. things
| like declaring variables automatically, filling method
| bodies, etc) and code suggestions yet it runs on an original
| Raspberry Pi.
|
| Now i'm not saying that you should not be using whatever you
| are using or that you should code on a Rasberry Pi or even to
| switch to Free Pascal / Lazarus (which honestly is far from
| being free of issues), but i think that you're overestimating
| what tools do nowadays and many people are so used to running
| slow and bloated software that take it for granted that
| things should be like that and cannot even imagine things
| being better.
|
| [0] https://www.freepascal.org/
|
| [1] http://runtimeterror.com/tech/fowl/
|
| [2] https://www.lazarus-ide.org/
| jbluepolarbear wrote:
| Visual Assist Tomato wouldn't have existed if Visual C++
| did what you said. I use Rider (mostly) and I don't even
| know how I'd program without all the features it adds. Auto
| import, code cleanup, code optimizations, memory allocation
| and boxing highlights, decompile assembly, Unity engine
| integration. I remember the days using Visual C++ and
| banging away on trying to get QT to not look ugly. I don't
| miss anything about the development process from 15 years
| ago.
| pjmlp wrote:
| I use C++ since 1993, moved into Visual C++ around
| version 6.0, and never used Visual Assist, or any of the
| JetBrains products that slow down Visual Studio to
| InteliJ levels of performance.
|
| One of my key learnings with alternative languages is to
| always use the SDK tools from the platform vendor,
| everything else comes and goes, while playing catch up
| all the time.
| jbluepolarbear wrote:
| I don't understand the reasoning against modern tools
| under the moniker that they're slow. If you can type out
| a class in a 10th the time but your ide is 40% slower (as
| a hypothetical impact) that is a net gain in output. In
| reality it's not anywhere near a 40% slow down to use the
| features on computers made in the last 5 years. Anecdotal
| to this, I am a slowish typer (40 wpm) and because of
| this writing code was a long process for me. With modern
| tools I can produce a monstrous amount of code in a short
| amount of time.
| pjmlp wrote:
| Visual Studio has been pretty modern, specially when
| compared against traditional UNIX offerings.
|
| Anyone measuring typing speed as productivity measurement
| is doing it wrong.
|
| Writing code is around 50% of daily activities.
|
| Visual Assist doesn't do nothing when I have to write
| documentation, architecture diagrams, meetings to decide
| roadmap items, demos at customer review meetings,....
|
| On top of that, none of the OS SDK replacements offer
| better UI or debugging capabilities across the platform
| tooling, they just play "catch-me if you can" with what I
| can get on day 0 of each OS SDK release.
|
| JetBrains wants to be Borland, yet they don't sell any of
| the platforms, or languages.
|
| I guess Kotlin and Android marriage will help them, as
| they are trying to make it their "Delphi", lets see how
| it plays out if Fuchsia ever happens.
|
| https://blog.jetbrains.com/kotlin/2011/08/why-jetbrains-
| need...
|
| > The next thing is also fairly straightforward: we
| expect Kotlin to drive the sales of IntelliJ IDEA.
| jbluepolarbear wrote:
| I don't think JetBrains is going anywhere soon; been
| using their products for almost a decade.
|
| I don't measure my productivity by how much code I can
| write, that was just an example.
|
| The way I work designing systems and architecture, I have
| already made the solution in my head and basically the
| "coding" part is just trying to get that info out as fast
| as possible. I have a similar thing to eidetic memory,
| but I am so ADHD what gets remembered can be random or
| missing stuff. I remember all code I've ever written,
| seen, or thought about and tools that allow me to
| basically brain dump this info greatly improve my
| production, leadership, confidence, and architectural
| designs.
| andi999 wrote:
| It is about the feedback-response loop. If I type a
| character and it doesn't appear (what feels)
| instantaneous I start to feel physically sick. I have
| build up some tolerance but I think when I tried Julia
| with Atom three years ago, I gave up after 15 minutes
| (atom too much latency if I remember correctly and Julia
| as well)
| badsectoracula wrote:
| Visual Assist improves on what was already there, i never
| claimed that the functionality was the best it could have
| been (if anything i wrote the opposite) only that it
| existed.
|
| But it is also an interesting thing to mention because in
| the last two C++ jobs i had where Visual Assist was
| preinstalled on my machine, i always disabled it because
| it was slowing down Visual Studio too much and the
| functionality VS provides is more than enough - VA does
| provide a bit more, but for me wasn't worth the slowdown.
| jbluepolarbear wrote:
| Last time I used VAT was in 2013 and it wasn't an issue
| on my i5 with an ssd. I would rather put my money into
| faster hardware to keep up with the demands of modern
| tools than live without them.
|
| If you're using Visual Studio for C++ I'd highly
| recommend Resharper C++. If you develop for Unreal Engine
| Rider for Unreal C++ is literally unreal, it makes me not
| hate writing Unreal C++ code.
| abraxas wrote:
| I wrote 3D visualization apps in 1998 using FLTK and OpenGL
| and the (statically linked) binary was less than 20 MB. I
| think my desktop had all of 64MB of RAM. It was snappier than
| a modern TODO app on Electron and far, far easier to write.
|
| What on earth have we done to ourselves?
| EvilEy3 wrote:
| How much time and expertise did it take? Did automatically
| work on all OSs? Could person without tech background slap
| something like this in a weekend? Did it have accessibility
| built-in? Could you reuse it on web?
| akhilcacharya wrote:
| Easier to write? I'm curious are there any sample apps like
| this that I can read?
| abraxas wrote:
| Sure. Check out the tutorial that has remained pretty
| much the same since I used it to learn FLTK + GL 23 years
| ago:
|
| https://www.fltk.org/doc-1.3/fluid.html
|
| You pretty much draw the UI in fluid and fill out the
| callbacks. Yeah it's C++ but it's not particularly
| esoteric C++.
| cwyers wrote:
| Among other things we've done to ourselves, we've got
| higher-resolution displays, and we have GUI apps that can
| scale to different resolutions seamlessly. We have support
| for high DPI displays. We have fonts with sub-pixel
| rendering for sharper, easier to read text. Speaking of
| font-rendering, we have Unicode and internationalization
| support, so that people who read and write Arabic, Chinese,
| Japanese and other languages that don't use the Latin
| alphabet can use their native language in file names,
| dialog boxes and in anywhere else they might want to. We
| have better support for screen readers for the blind. For
| people who aren't fully blind, but have vision problems, we
| have the ability to make text and UI features larger
| dynamically to support them. We have better multitasking
| support, including process isolation to keep a badly-
| behaved application from crashing the entire computer. We
| have better security at the OS level to prevent malicious
| applications to take over the whole machine.
|
| That's a big part of what we've done to ourselves. And this
| makes computers better for a whole lot of people.
| abraxas wrote:
| Yeah, no.
|
| First, all those things sans high DPI functionality
| existed in 1998.
|
| Second, most of Electron apps don't benefit from these
| theoretical advancements.
|
| Preemptive multitasking existed in 1998 and worked every
| bit as well as it does today. Even in MS Windows.
|
| Security, nah. We have more attack vectors than at any
| point in the past. And just more crapola caked on to
| "protect" against those.
| throwanem wrote:
| Emacs does those things too, these days. It's still snappier
| than anything else I've tried recently.
| GuB-42 wrote:
| Interesting how what was seen as slow and bloated back then
| become the opposite today. Eight Megabytes And Constantly
| Swapping, yep, back then, 8MB was unthinkably large for a
| text editor...
|
| Another example is the Enlightenment window manager. It was
| considered a little heavy, but good looking. But because
| there was a large hiatus in development, it got "stuck in
| the past" and now, it is one of the lightest there is.
| unknown2374 wrote:
| _cough_ vim _cough_
|
| I'm just kidding. Don't want to start a fight here.
| throwanem wrote:
| Well, with vim, it probably depends more on your terminal
| and tmux, while Emacs renders its own graphical frames.
|
| But those wars are long over anyway, these days. One
| might just as well fight over whether the monolith on
| Earth's moon is better than the one on Europa, or vice
| versa.
| [deleted]
| unknown2374 wrote:
| As mentioned in the other comment, emacs does those things,
| and so does Vim (with plugins of course).
|
| I moved from sublime to atom to VS code, but eventually
| settled on Vim because I was able to get the same features
| (that I used) while getting almost instant response. A
| feeling that has completely changed how much I enjoy writing
| any sort of text.
| zant wrote:
| I tried to move from VS Code to NeoVim with NerdTree and
| some other plugins to make it more IDE-like.
|
| But eventually wasn't able to get the same code completion,
| and searching was also a bit more painful.
|
| How do you go about that? Would you mind sharing your
| setup? :)
| smichel17 wrote:
| Write code in vim with no/few plugins. Don't worry about
| getting the variable names right. Then move to your IDE
| to get it to compile.
|
| It's conceptually similar to sketching out the design of
| your code with a pen and paper or whiteboard. First write
| it quickly, then make it correct.
| jrochkind1 wrote:
| That's what you do? Why?
| bobmaxup wrote:
| How is writing something in vim faster? You can have the
| same bindings in many IDEs.
| eska wrote:
| Stop trying to use vim like your IDE. Vim doesn't have
| shortcuts, it has a whole language of commands that can
| freely be combined.
| smichel17 wrote:
| This thread has been specifically about responsiveness.
| Latency, not throughput. Also, the bit about no plugins
| was a little white lie. I really meant "no plugins for
| IDE-like functionality (language server, etc)". While
| many IDEs offer basic vim keybindings, I don't know any
| that would let me import my .vimrc wholesale and work
| exactly the same. I'd love an IDE that embeds neovim as
| the text editor.
|
| Anyway, if you don't care about all that, you can get a
| similar effect by turning off intellisense (or
| equivalent) in your IDE while you write, then turn it
| back on at the end to get what you just wrote to compile.
| I do this sometimes in Android Studio.
| linknoid wrote:
| The VsVim plugin for Visual Studio makes an attempt at
| supporting everything in the .vimrc (or _vimrc) file.
| Compatibility is not 100%, so certain things just fail,
| but it's a lot more than just basic key bindings.
| IggleSniggle wrote:
| There is an IDE that embeds neovim as a text editor, kind
| of.
|
| The VSCode Neovim extension makes neovim run as its
| backend, while giving you all the IntelliSense etc of
| VSCode. I can't tell exactly you how it affects
| responsiveness as I only toy around with it, but it does
| feel noticeably better in some aspects...yet maybe
| occasionally glitchy?
|
| Anyway it's pretty interesting, especially if you're
| already using neovim anyway.
| agrippanux wrote:
| The vim plugin CoC uses the same engine for code
| completion as Code. It's pretty trivial to set up.
|
| For searching, use SilverSearcher / fzf
| davidkunz wrote:
| Hi, I use Neovim with basically the same features as
| VSCode. I made a video series on how to configure it:
| https://youtu.be/CcgO_CV3iDo?list=PLu-ydI-
| PCl0OEG0ZEqLRRuCrM...
| zant wrote:
| Wow looks super promising. Definitely worths a try.
|
| Thanks for sharing!
| higerordermap wrote:
| Yeah. LSP has changed a lot for me.
|
| For C/C++, could use QT Creater or KDevelop too, which I
| think are pretty good in latency.
| anthk wrote:
| >all sorts of things we never had a couple of decades ago
|
| We had them.
| setr wrote:
| However, most of that should be done in the background -- it
| shouldn't affect your actual text input speed. Auto-format is
| more along the lines of something that could be blocking, but
| we're not dealing with latex problems as to be significant
| tshaddox wrote:
| I'm pretty sure that none of these latency benchmarks are
| showing that text input speed is affected. You can
| definitely input more than 1 character every 40ms in modern
| "slow" text editors.
| tleb_ wrote:
| The question isn't about throughtput but latency.
| andylynch wrote:
| Even putting that aside, just showing text on a screen is
| much slower on modern PCs then older ones, since you have a
| far more complicated graphics stack and latency at several
| added steps.
|
| I remember an article a couple of years ago where someone
| rigged up a camera to measure key press to screen update on
| different machines and the results were eye opening.
|
| edit: found it http://danluu.com/input-lag/. The Apple ][
| ties for first place with an iPad Pro.
| esperent wrote:
| > The Apple ][ ties for first place with an iPad Pro.
|
| * When used with an Apple Pencil (30ms). When used with
| touch it drops to 70ms.
|
| Also, it's worth noting that there's a very limited list
| of devices tested there and it heavily skews Apple.
| jart wrote:
| Are you referring to this submission?
| https://news.ycombinator.com/item?id=23369999 Outstanding
| article. Total shame it only got 100 upvotes.
| moosingin3space wrote:
| Another fascinating look into text on computer screens is
| this article: https://gankra.github.io/blah/text-hates-
| you/. Just goes to show that text rendering is actually
| absurdly complex, unless you drastically restrict the
| problem space.
| makapuf wrote:
| This sometimes makes me think we're still on the
| skeuomorphism phase of text. Its more and more complex to
| render realistic looking with proper illumination and
| textured faux leather for your UI until until you just
| admit you're rendering a ui on a screen and then you're
| back to colored rectangles. We're still trying to render
| ideas and words resembling handwriting and print press
| characters, until we embrace screens and render arial and
| images or even monospaced fonts which are perfectly
| readable (I do that all day long on my code editor)
| skipnup wrote:
| And then comes unicode and all the simplicity is gone
| again as the rest of the world uses more than 26 letters.
| vmladenov wrote:
| https://twitter.com/id_aa_carmack/status/1934806225331200
| 01?...
| fao_ wrote:
| Related, my favourite thread to come out of the queer
| tech circles:
|
| "Almost everything on computers is perceptually slower
| than it was in 1983" https://threadreaderapp.com/thread/9
| 27593460642615296.html
| underwater wrote:
| Google Maps is a truly horrendous interface. It's pretty,
| it's well built, but it's fundamentally a horrible UX.
|
| I find myself frequently bamboozled until I stop and try
| and determine which mode I'm in. Navigation behaves
| differently to browsing, which behaves differently to
| searching, which behaves differently to viewing an
| individual result. I'll be thrown from one mode to
| another and never feel in control of the app.
| 1ark wrote:
| I hate it with passion. Clicking a photo on a cafe in the
| main view, horrendous because it does not actually open
| the photo, nor the overview on the cafe screen. Have to
| be on the photos screen for the photo to open up full
| screen.
|
| Pressing on some place while being in other than top
| mode.
|
| The back button experience.
|
| And the bottom drawer, no idea when I should pull it up
| or down, or if I am currently in it.
| jart wrote:
| One thing that's illuminating is go to
| chrome://settings/content/all and sort by "data stored"
| to see how much local storage websites use. Stuff like
| vice.com needing 100mb of space on your hard drive for
| who knows what purpose.
| jrochkind1 wrote:
| Wow, thanks for the tip, never occured to me to do that.
|
| There were websites I had never heard of using hundreds
| of megs. Also acehardware.com for some reason using
| hundreds of megs.
|
| Also Github "community" forums and Travis "community"
| forums (I don't use travis anyore) using hundreds of
| megs. Are some websites just caching the entirety of
| every page you look at in local storage? How rude.
| xvilka wrote:
| > IMO there's a tradeoff: we could be writing all our
| programs in C, still.
|
| No need for that - you could use Zig or Rust. Though both
| need a better GUI frameworks, but it's certainly more
| efficient with them.
| [deleted]
| Aeolun wrote:
| > It's doing autocomplete suggestions, linting code as I type
|
| Even so, shouldn't it be able to do that in 16ms?
| dsr_ wrote:
| Fermi guess: 60 wpm, that's one 5 character word per
| second, it probably doesn't make sense to give a new
| prediction more often than once per character -- that's
| 200ms to chew on autocomplete and linting and fancy
| animations. Meanwhile, please render the specific character
| out of your lookup table in 16ms, thank you.
|
| Do modern graphics drivers for X or Wayland hand off font
| rendering to the GPU? They probably should -- it's maybe
| 100 or so small textures per font-selection, 150KB or less
| prerendered with 3-bit alpha, and maybe 100 loaded up into
| graphics RAM at a time -- 10MB is nothing, really.
| chii wrote:
| they certainly could. Games can do 16ms frames, while
| calculating full physics simulations.
|
| It's just that text editors of the modern day are
| programmed by people who prefer to not write it that way -
| mainly because it's quite hard, and the modern OS doesn't
| usually fit well into this framework of rendering for
| multi-tasking. And it takes more effort too.
|
| Much easier to rely on a UI framework which adds overhead.
| The expectation is that the user probably won't care, and
| prefer that the software be more feature rich.
| klingon79 wrote:
| I'm less concerned about the footprint and more about security.
|
| It can be assumed that anything running on the desktop has or
| will have vulnerabilities. The rise of web applications has
| been partially due to the assumption of great sandboxing.
|
| I look forward to this project doing well, but it's not the
| first time I've seen an electron competitor on HN promoting it
| being Node-based. Node isn't sandboxed by default.
| LinguaBrowse wrote:
| Another commenter brought up the idea of porting it to Deno -
| I'm not sure how inter-compatible the two are, but it
| provides a hopeful future direction to facilitate sandboxing.
| jart wrote:
| Help me build Cosmopolitan Libc. We're using modern compilers
| to build programs that are tinier and more portable than
| anything developers even as far back as the 70's or 80's were
| able to produce. https://justine.lol/cosmopolitan/howfat.html I
| built a LISP interpreter too, which makes Altair BASIC look
| bloated by comparison. https://github.com/jart/sectorlisp I
| will say that 20mb isn't too shabby if we judge the OP's
| project by Electron standards. If NodeGUI was pruned a bit
| more, it wouldn't be too far off from where Go is at right now
| for Hello World on the console. Although one does have to take
| into consideration that it assumes external dependencies are
| available such as V8 I assume? Does it statically build? One
| thing I'm curious about is I looked at the yarn lock file and I
| couldn't find Qt so I have no idea where it comes from.
| caslon wrote:
| If we're only interested in one/"not-Mac/Win/FreeBSD" of
| those platforms, how small could we get programs down to? Is
| forgoing certain platforms supported?
|
| Also, there was a really fantastic question asked in the last
| Cosmopolitan thread, but it wasn't answered; what's the
| answer to it?
|
| https://news.ycombinator.com/item?id=26294721
| jart wrote:
| If you uncheck the boxes on the "how fat" page I linked
| above, then static binaries for a single platform usually
| end up being 4kb. Most of that 4kb is padding nops to page
| size. The question you linked is now answered.
| kazinator wrote:
| 8 bit BASICs were extremely tightly coded and packed a lot of
| functionality. They had working garbage collection for
| strings, with useful string processing built on it. Programs
| could be interrupted to safely return to the prompt, and
| errors which terminated the program informed the user of the
| line number, e.g. "illegal quantity error in 210". The
| internal, tokenized representation of programs could be
| interactively edited to update the program, which could be
| saved to disk. BASICS also had floating-point support, with
| functions like LOG, EXP, SIN, COS, TAN, ATAN, ... Also
| arrays, including multi-dimensional ones.
| pjmlp wrote:
| And the compiled ones also included some form of records.
| jart wrote:
| Very impressive. But it didn't have a metacircular
| evaluator! sectorlisp does.
| kazinator wrote:
| I see there is a metacircular evaluator in the repository
| (lisp.lisp), but I don't see where that is pulled into
| the image.
|
| In the BASIC heyday, there existed compilers for BASIC
| (some of them written in BASIC). These didn't ship in the
| ROM images either, they were third-party apps.
| kitd wrote:
| I can't remember the precise mechanism, but IIRC the base
| NodeGUI pkg downloads and builds a minimal QT, and then links
| into it using NodeGUI/qode which hooks up the Node and Qt
| event loops.
| gravypod wrote:
| Off topic but what did you use for emulating and visualizing
| your bootsector (blinkenlights.com) in here [0]. Looks much
| more convenient then QEMU which is what I used last time when
| doing ring 0 stuff in x86.
|
| [0] - https://www.youtube.com/watch?v=hvTHZ6E0Abo
| jart wrote:
| I used Blinkenlights to simulate x86 boot. I wrote it!
| https://justine.lol/blinkenlights/index.html
| anthk wrote:
| > built a LISP interpreter too,
|
| Some friend of mine like it :D.
|
| But I'd like that more if it was Scheme.
| davej wrote:
| It would be nice to have the ability to weave in WebViews with
| the native UI. I see this lib but it's still marked as WIP:
| https://github.com/nodegui/nodegui-plugin-webview
| tpmx wrote:
| So is it Chromium-based or not? "which makes it CPU- and memory-
| efficient when compared to other Chromium-based solutions like
| Electron"
| LinguaBrowse wrote:
| Its UI runtime is Qt and its JS runtime is Node.js. No Chromium
| here :) it makes super-small, low-memory apps.
| crazygringo wrote:
| Yes, I suppose people could be understandably be confusing V8
| with Chromium.
|
| It's using the same JavaScript engine as Chromium, which is
| of course developed by Chromium and is part of it, but
| without the rest of Chromium, as Node.js always has.
|
| It's a great example of synecdoche [1]. :)
|
| [1] https://en.wikipedia.org/wiki/Synecdoche
| tpmx wrote:
| V8 is tiny compared to the operating system known as
| chromium.
|
| Anyway, it was just a misunderstanding based on poor
| writing on the web page.
| danenania wrote:
| Looks like it's node + QT, not chromium.
| tpmx wrote:
| Yeah.
| nawgz wrote:
| Seems weird to slander a community instead of stating what
| happened, which is that the extraneous "other" made the
| meaning ambiguous.
| zachrip wrote:
| They're making use of yoga (a layout engine) so I assume that
| it is not web based (because why would you use yoga otherwise).
| mkl wrote:
| The word "other" probably shouldn't be there. It seems to wrap
| Qt. From the NodeGUI page: "it is a wrapper for a native C++
| widget toolkit QT".
| sonthonax wrote:
| I'm always a bit surprised there was the space for Electron to
| exist in the first place. Since most operating systems have
| widget toolkits that have browsers effectively embedded into
| them.
|
| What I would have liked to have seen instead of Electron would
| have been a shim API that abstracted OSX/iOS/WinForms/QT
| webviews, and for those webviews to have a working API that would
| allow DOM manipulation, and allowed native sub-views to be
| inserted as block elements.
| Stratoscope wrote:
| One reason is that for a very long time, if you created a
| native WebView on Windows, you would get an IE7-compatible
| browser, even if the user had installed a much newer version of
| IE. There were a couple of tricks you could use to get the
| user's actual browser version, which I described some time ago
| here:
|
| http://forums.apricitysoftware.com/t/why-is-markdownpad-spaw...
|
| In any case you were still dependent on IE10/11 at the best,
| and certainly nothing as modern as the old Edge, much less the
| Chromium-based Edge. And on older Windows versions it
| completely depended on whether the user had upgraded IE.
|
| You _could_ write HTML /CSS/JS that was portable between
| IE10/11 and other native browsers, just as we all did in actual
| websites. I did this for Mac/Windows in the past and it worked,
| but it was fairly compelling for web developers to have a
| single browser version to target instead of the various
| incompatible native web views.
|
| The situation is a bit different now, where you can get an
| Chromium Edge view on Windows 10 and a Safari view on Mac, but
| what do you get on Linux? I don't know.
| k__ wrote:
| I know a bunch of devs who simply shipped a Qt webview app when
| a native client was requested.
| techdragon wrote:
| That was sort of half doable with the horribly insecure
| Microsoft Hypertext Applications
| https://en.wikipedia.org/wiki/HTML_Application
|
| You had to use JavaScript or VBScript but all the safety rails
| are off, this is pre-sand boxing, what do you mean websites
| might be malicious why would someone make one like that... you
| could do crazy things, and fully leverage windows APIs directly
| without much effort via VBScript, I once used the winforms(?)
| APIs to introspect field labels and names to automate the
| driving of multiple desktop apps from a crazy jquery and
| VBScript monstrosity. Made me twice as efficient at that job
| though so it was awesome.
|
| You could control child iframes and pop up windows (remember
| these?) and VBScript let you shoehorn quite a bit of native UI
| type stuff whenever it was going to be easier than building
| something with simple forms, JavaScript, tables and frames. If
| you got really fancy you would Base64 some absurd binary into
| your app and unpack it on the fly with VBScript then call it
| from a temp directory in order to drive things like interacting
| with network services that didn't have any sort of thing you
| could work with via HTML JavaScript and XMlHTTRequest (this was
| the very dawn of Ajax)
| baybal2 wrote:
| How is it "light" weight?
|
| > Low CPU and memory footprint. Current CPU stays at 0% on idle
| and memory usage is under 20mb for a hello world program.
|
| 20MB!
| j-krieger wrote:
| So what? If you stored each Pixel on a modern WQHD monitor,
| that would be 15mb. Its almost like people on HN dont know what
| theyre talking about
| baybal2 wrote:
| At least, that will be a shared system framebuffer, not
| applications own memory.
| butz wrote:
| Would it be possible to use Deno for JS runtime? That should add
| some sandboxing limitations for apps.
| LinguaBrowse wrote:
| I'd need to pass that question on to Atul (who made the parent
| project, NodeGUI). As long as Deno supports the same native API
| bindings as Node does (does it?), I imagine that it wouldn't be
| out of the question.
| majkinetor wrote:
| Will wait for MAUI.
| crazypython wrote:
| Styling with CSS is interesting.
| Gys wrote:
| > core set of platform agnostic native widgets
|
| This is confusing for me. I think such a framework is either
| 'platform agnostic' OR 'native'. Maybe the API is platform
| agnostic and the rendering is done natively?
| LinguaBrowse wrote:
| That's the case, yes - the UI runtime is Qt5 (which is rendered
| using low-level graphics APIs, so we class it as "native" -
| mostly in contrast to WebView-based UIs), and it's the same API
| regardless of which platform you're running on.
| ComputerGuru wrote:
| I saw Qt and immediately understood what you were trying to
| say, but for the record: That's not what native means. Native
| means "uses the platform widgets and drawing/theming api" and
| Qt is not native: it actually draws its own widgets (for the
| most part with certain exceptions on certain platforms) that
| are drawn to mimic the system UI with subtle differences. If
| the system UI implementation suddenly changes (say with an OS
| release) the Qt UI wouldn't magically change with it.
|
| An example of native UI is libui or WxWidgets.
| jart wrote:
| Yeah but Qt does it well enough that I consider it de facto
| native. It's not like Swing Java where they totally went
| their own way with the widgets.
| wruza wrote:
| Nativeness lies more in behavior than in looks. E.g. an
| input (an edit for old folks) has a very specific popup
| menu on every system, text selection works in a specific
| way (think what happens when you double/triple click,
| move with ctrl or lose or gain focus). Tab order and
| focusability is important as well. If they get that
| correctly, by e.g. using borderless system text areas or
| grabbing a menu from common control internals, it's not a
| big deal if they draw some borders or animations by
| themselves. It's just pixels in the end, sometimes better
| than native (which is just crap too often, like windows
| tables, lists, popdown controls).
|
| But really, native look and feel only left on macOS.
| Windows lost its traditions around vista, linux never
| ever had one true way to do UI, and browsers almost
| exterminated everything else.
| kuschku wrote:
| Swings Platform LaF was still much closer than current
| browsers ever get.
| avel wrote:
| Is Qt considered native when you use KDE and not native
| when you use GNOME? Is Qt 3 considered not native when you
| use a KDE release that uses Qt 4 under the hood?
| flipcoder wrote:
| Native usually means standard or specific to the
| particular system. I would say yes to those questions.
| quarantine wrote:
| I would say so. Just like GTK is native on GNOME but
| definitely not on Windows. "native" (to me) really just
| means whatever the system is designed for.
| nine_k wrote:
| Then Windows 10 apparently lacks a native GUI toolkit,
| because it's certainly not "designed for" just one.
|
| A similar thing happened to Android.
| gigel82 wrote:
| One could argue Win32 is still the de-facto GUI toolkit
| in Win10. Things like .NET Windows Forms and (non-WinUI3)
| UWP are actually rendered with Win32 common controls.
| jart wrote:
| WIN32 isn't de facto it is the canonical API for Windows.
| It always has been, since like the 1980's.
| ComputerGuru wrote:
| Indeed, but with some exceptions. .NET SWF shipped with
| extremely kludgy drawn clones of toolbars and menu bars
| instead of using the native ones (although the native
| ones were later exposed) and the result is that those
| particular controls on SWF apps did not age gracefully
| (DPI problems, system theme mismatch, scroll acceleration
| issues, etc). That's the kind of thing Qt would also face
| with drawn components skinned to look like the real deal.
| MaxBarraclough wrote:
| > Then Windows 10 apparently lacks a native GUI toolkit,
| because it's certainly not "designed for" just one.
|
| Windows 10 has several native GUI toolkits. The same
| thing happened in MacOS, which transitioned from Carbon
| to Cocoa.
|
| If the widgets are drawn by a toolkit that isn't bundled
| with the OS, it's a non-native GUI. Of course, this isn't
| always a bad move.
| mrwoggle wrote:
| Real question, what do some people mean with native C++? Or
| stuff like react native? Seems like it just equals more
| performance / peels away an abstract layer.
| LinguaBrowse wrote:
| React Native does extend from platform UI components such
| as UIView, so that one at least is uncontroversially
| "native".
| heleninboodler wrote:
| Part of the point of "native" is that each platform gets
| its own consistent look and feel and behavior for its own
| UI widgets. Back when I worked at Adobe, we had our own
| internal cross-platform UI framework for
| Illustrator/Photoshop and they were consistent across the
| supported platforms, but they didn't look like "native"
| controls, and that can end up being a pretty big headache
| (e.g. when accessibility and keyboard navigation don't
| just automatically work the way the native controls do,
| that's your problem to fix or punt). They also just
| generally look "different" and a lot of people consider
| that a bad thing.
| dschuessler wrote:
| Not necessarily. This expression probably refers to Qt's
| capability to use the subset of native widgets that are
| functionally equivalent across platforms. This blog post has
| some images of this feature in action:
| https://www.qt.io/blog/desktop-styling-with-qt-quick-control...
| LinguaBrowse wrote:
| Maintainer here - Happy to answer any questions!
| norswap wrote:
| Is there a story for interop with other languages? I understand
| the UI probably has to be defined in JS, but what about
| transparently making request to a local server written in
| another language (bonus point if it can somehow be made less
| observable than that, i.e. not consuming a localhost port).
| akiselev wrote:
| The NodeJS NAPI support binary modules written in any
| language that can build dynamic libraries against the C FFI.
| There's still a little overhead marshaling between Javascript
| and the guest language but it's small compared to the
| overhead of HTTP or WASM.
| mrwoggle wrote:
| I know QT is dual licensed for application development. How's
| the licensing here?
| LinguaBrowse wrote:
| Some clarification on that from the maker of the parent
| project, NodeGUI, here:
| https://twitter.com/a7ulr/status/1225498258233053184?s=21
|
| Atul is licensing NodeGUI as MIT, so I'm licensing Svelte
| NodeGUI as MIT accordingly.
| flipcoder wrote:
| From Qt's page https://www.qt.io/licensing/open-source-lgpl-
| obligations:
|
| "In case of dynamic linking, it is possible, but not
| mandatory, to keep application source code proprietary as
| long as it is "work that uses the library" - typically
| achieved via dynamic linking of the library."
| empyrical wrote:
| Also, Chromium's Blink renderer has a lot of LGPLv2 source
| files that date back to the KDE KHTML days[1] and as you
| can see by the numerous proprietary applications that use
| Electron and Chromium Embedded Framework, that this doesn't
| hinder companies from using LGPL libraries as long as they
| abide by the license.
|
| However, one thing to note: the OSS version of Qt uses the
| LGPLv3 license, which has additional restrictions (like the
| "Anti-Tivoization" clause) which make it incompatible with
| the iOS AppStore thus forcing you to use the commercial
| version of Qt in those situations. Not sure about the Mac
| and Windows 10 app stores, I am curious if anyone knows/has
| experience with LGPLv3 and those stores?
|
| [1]
| https://github.com/chromium/chromium/search?q=%22kde.org%22
| heavyset_go wrote:
| > _which make it incompatible with the iOS AppStore thus
| forcing you to use the commercial version of Qt in those
| situations._
|
| Not necessarily. If you're able to distribute versions of
| your app to iOS users so that they can link it against
| their own Qt libraries, you'd be in compliance with the
| LGPL.
|
| I've seen companies that distribute via the App Store,
| but also provide object files with instructions to link
| them against user supplied Qt libraries and to get them
| on iPhones/iPads.
| varajelle wrote:
| The "Anti-Tivoization" clause is only applicable for
| hardware that are distributed with GPL/LGPL software
| included. It does not concern the app store.
|
| The use of LGPLv2 on the iOS AppStore seems to be
| controversial. But nothing changes with LGPLv3 in that
| respect as far as I know.
| bmn__ wrote:
| 1. Is there any way to load a UI file made with designer-qt5,
| perhaps with example code?
|
| 2. Thank you for backing up your claims about a native
| implementation by actually providing one, unlike your
| competitors Tauri and Wx who constantly lie about the topic.
| pfraze wrote:
| It's looking good! One really common usecase Id suggest
| emphasizing (it looks supported) is the systray UI. I've had a
| lot of cases where my program is mostly just a background
| nodejs service and the simple task of adding a dock UI required
| electron. A great thing to have solved!
| hawthornio wrote:
| Qt supports this! so you should be covered.
| boromi wrote:
| Any Win 10 fluent examples? Perhaps WinUI integation?
| LinguaBrowse wrote:
| The parent project, NodeGUI, has some Windows screenshots and
| examples - I'm not familiar enough with Fluent or WinUI, but
| basically the UI runtime is Qt5, so integrating it into
| genuine Windows apps is out of scope (but may well be
| possible with the right expertise). I assume it would involve
| some kind of Qt-hosting view. I'm unsure whether Qt5 can host
| Windows UI components.
|
| Edit: NodeGUI here: https://github.com/nodegui/nodegui
| jcelerier wrote:
| > I'm unsure whether Qt5 can host Windows UI components.
|
| yep, basically you have to do : auto
| window = QWindow::fromWinId(reinterpret_cast<WId>(/* HWND,
| NSView, X11 buffer, Wayland surface... /*)); auto
| widget = QWidget::createWindowContainer(window);
|
| and then you can use the widget like any other Qt widget,
| put it in a layout, etc... (of course caveats may apply
| when you start doing transparency or other fun things).
| ComputerGuru wrote:
| WinUI 3 improves the ability to embed fluent UI "xaml
| islands" in Win32 apps (like Qt processes) but it's
| extremely convoluted and requires a lot of boilerplate
| (that I believe Qt could theoretically abstract over being
| at a high-enough level).
| jjcm wrote:
| Does this use the native OS's current default browser renderer?
| If so is windows using edge or chromium under the hood?
| dgreensp wrote:
| There's no browser component. Qt (https://www.qt.io/) is the
| granddaddy of native cross-platform GUI.
| nguyenkien wrote:
| Off topic, any plan to make ot work with react native?
| LinguaBrowse wrote:
| No plans, but what kind of integration would you have in
| mind?
|
| I actually happen to be struggling to get React Native in the
| NativeScript runtime right now - running it in the Node.js
| runtime would be if anything even more challenging. But there
| are other ways to make the two work together.
| bsaul wrote:
| I've always been wondering what nativescript really was
| about, and how it compared to react native and other
| platforms (and also, why do i barely read about it on HN or
| elsewhere, as it seems to offer a cross-platform dev
| environment).
|
| The project's webpage has way too many tech listed to be of
| any help, and the video mentions a framework, an IDE, a
| debugging environment...
|
| Do you have a good link where i could get a better
| understanding of the tech, and how it's used in real world
| project ?
| himujjal wrote:
| I might go a little offtopic here. Any plans to integrate
| https://github.com/c-smile/quickjspp. That way you can target
| mobile platforms too. QT supports mobiles well
|
| As for desktop only this is great. Great work. Many people are
| commenting on NodeGUI only. They have forgotten to mention how
| Svelte also contribytes to saving memory footprint and cpu
| cycles over other frameworks with a much easier way to write
| apps. Add a small learning curve to that.
| glutamate wrote:
| There are other projects like this - But what would really set
| it apart would be mobile (iOS and Android) support. Can we do
| anything to support that happening?
| LinguaBrowse wrote:
| Qt does have an implementation that targets mobile. I don't
| know how the licensing works, but in theory there should be a
| way to rely on Qt for mobile to extend support to iOS and
| Android. Way out of my own expertise, though!
| heavyset_go wrote:
| Qt for Android and Qt for iOS can be used under the
| LGPL[1]. The issue for iOS, though, is that Apple's App
| Store violates the terms of the LGPL. To comply with the
| LGPL, you must make available to iOS users versions of your
| app that can be linked against user-provided Qt libraries.
|
| If you use the Qt commercial license for either, then you
| don't need to worry about your app conforming to the LGPL.
|
| [1] https://wiki.qt.io/Licensing-talk-about-mobile-
| platforms
| ognarb wrote:
| Something similar: https://www.kdab.com/declarative-widgets/
| c-smile wrote:
| Same demo in VanilaJS and Sciter.JS :
| https://github.com/c-smile/sciter-js-sdk (see screenshots there).
|
| Binary is ~5MB, and that is HTML/CSS + QuickJS + NodeJS runtime.
|
| Versus 50MB+ of NodeGUI that is Node.JS + QT.
|
| And SvelteJS works in Sciter.JS out of the box too.
| anilgulecha wrote:
| Hi c-smile - i always get confused about the FOSS status of
| sciter related projects. It's a very promising platform -
| specially being CSS/HTML/JS at a low resource footprint.
|
| I recall a crowd-sourcing campaign to make this toolset fully
| open - did that succeed? What's the current state? For me a
| signal to use sciter would be it's inclusion into the
| debian/ubuntu repository.
___________________________________________________________________
(page generated 2021-03-06 23:02 UTC)