Our great sponsors
-
webui
Use any web browser as GUI, with your preferred language in the backend and HTML5 in the frontend, all in a lightweight portable lib.
-
-
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.
-
core
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web. (by vuejs)
-
graderjs
💦 Turn your full-stack NodeJS application into a downloadable cross-platform binary. Also works for SPAs, or regular web-sites.
-
jspaint.exe
🌂JS Paint ~~ as a cross-platform native desktop app. In other words, the "🎨 Classic MS Paint, ＲＥＶＩＶＥＤ + ✨Extras".exe hehe
-
flexbugs
Discontinued A community-curated list of flexbox issues and cross-browser workarounds for them.
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
simdjson
Parsing gigabytes of JSON per second : used by Facebook/Meta Velox, the Node.js runtime, ClickHouse, WatermelonDB, Apache Doris, Milvus, StarRocks
-
-
ollama-html-ui
HTML UI for Ollama. Minimal & responsive UI: mobile & desktop. Cross-browser support. Simple installation: host on your own server, run in your browser.
-
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.
Looks like it is—they started out with the same color scheme just without the splashes [0], then changed the colors when someone recognized it. From the thread it sounds like an honest mistake. They seem to have assumed that everything on icons8 [1] was up for grabs, when in fact a lot of trademarks are on there.
[0] https://github.com/webui-dev/webui/issues/100#issuecomment-1...
[1] https://icons8.com/
Ok, let's change the URL to that from https://github.com/webui-dev/zig-webui above. Thanks!
Strange then that frameworks advertise how fast they are at rendering, mutating, and creating objects in the DOM, and one of the main JS benchmarks everyone likes to measure their performance by is literally a benchmark about DOM manipulation: https://github.com/krausest/js-framework-benchmark
Oh wait. It's not strange. Because state manipulation is a largely solved problem, and even the least performant state manipulation is blazingly fast. However, presenting components in the browser's DOM is tens of magnitudes of orders less performant than anything you can throw at state manipulation.
And every single framework is busy solving one single problem: how do we touch the DOM as little as possible?
From your own example, here is the text from https://vuejs.org/ as of today:
> The Progressive JavaScript Framework
> An approachable, performant and versatile framework for building web user interfaces.
> Approachable - Builds on top of standard HTML, CSS and JavaScript with intuitive API and world-class documentation.
> Performant - Truly reactive, compiler-optimized rendering system that rarely requires manual optimization.
> Versatile - A rich, incrementally adoptable ecosystem that scales between a library and a full-featured framework.
Yes, performance is mentioned. But it's hardly the main selling point, and they don't even mention DOM manipulation, they're talking about the rendering in general.
Lit isn't even a framework, it's a "web components library".
> all modern frameworks
Yeah, "all modern frameworks" being one framework + one library?
This is very polished and cool looking. Inspiring. I find this project's level of polish very inspiring.
It's lovely to see someone has captured this idea and expressed it in the right way to make it interesting to many people. I really hope this mode of desktop apps can take off, at least to the level where the community has something to explore for a while to see if it works. I made something like this for Chrome browsers a while ago, nodejs backends, vanilla front-ends, built-in packaging using pkg. It's just a nice approach: https://github.com/dosyago/graderjs
And I made a demo using the venerable MS Paint clone JS Paint^0. The dev experience was great, I literally just dropped in the front-end code to the right folder, compiled it and wham, "desktop JS paint" on 3 platforms, haha.
Using the ubiquitous local browser as the rendering / API engine for desktop just seems smart. And it's technically interesting, because you get to think in terms of how can you step back from the browser, the platform, the front-end and the back-end and come up with a general API that addresses all of it, which is kinda cool.
0: https://github.com/00000o1/jspaint.exe
This is very polished and cool looking. Inspiring. I find this project's level of polish very inspiring.
It's lovely to see someone has captured this idea and expressed it in the right way to make it interesting to many people. I really hope this mode of desktop apps can take off, at least to the level where the community has something to explore for a while to see if it works. I made something like this for Chrome browsers a while ago, nodejs backends, vanilla front-ends, built-in packaging using pkg. It's just a nice approach: https://github.com/dosyago/graderjs
And I made a demo using the venerable MS Paint clone JS Paint^0. The dev experience was great, I literally just dropped in the front-end code to the right folder, compiled it and wham, "desktop JS paint" on 3 platforms, haha.
Using the ubiquitous local browser as the rendering / API engine for desktop just seems smart. And it's technically interesting, because you get to think in terms of how can you step back from the browser, the platform, the front-end and the back-end and come up with a general API that addresses all of it, which is kinda cool.
0: https://github.com/00000o1/jspaint.exe
For old features yes, for new ones it depends.
https://github.com/philipwalton/flexbugs
String parsing is negligible compared to the speed of the DOM which is glacially slow: https://news.ycombinator.com/item?id=38835920
Come on, people, make an effort to learn how insanely fast computers are, and how insanely inefficient our software is.
String parsing can be done at gigabytes per second: https://github.com/simdjson/simdjson If you think that is the slowest operation in the browser, please find some resources that talk about what is actually happening in the browser?
Reminds me of the approach of CLOG (Common Lisp Omnificent Gui[1]) and its ancestor GNOGA (The GNU Omnificent GUI for Ada[2]).
They also integrate basic components and even graphical UI editor (at least for CLOG), so you can essentially develop the whole thing from inside CL or Ada
[1] https://github.com/rabbibotton/clog
[2] https://github.com/alire-project/gnoga
Reminds me of the approach of CLOG (Common Lisp Omnificent Gui[1]) and its ancestor GNOGA (The GNU Omnificent GUI for Ada[2]).
They also integrate basic components and even graphical UI editor (at least for CLOG), so you can essentially develop the whole thing from inside CL or Ada
[1] https://github.com/rabbibotton/clog
[2] https://github.com/alire-project/gnoga
https://github.com/christianhellsten/ollama-html-ui/
The biggest problem with HTML/CSS apps is that their look and feel are different from native GUIs. This is less of a problem for chat and document-based applications (Slack, Word, etc.), IMO. With Tauri, I can also customize the window and integrate native features to mitigate this. I'm not sure WebUI can do this.
The active development of GNOGA occurs in https://github.com/Blady-Com/gnoga
Don't know the relation to the official repository, which might still be: https://sourceforge.net/projects/gnoga/ but Blady-Com is the current most active developer in both.