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.
-
-
-
Recoil
Recoil is an experimental state management library for React apps. It provides several capabilities that are difficult to achieve with React alone, while being compatible with the newest features of React.
-
-
-
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.
-
proposal-record-tuple
ECMAScript proposal for the Record and Tuple value types. | Stage 2: it will change!
-
-
-
-
htm
Hyperscript Tagged Markup: JSX alternative using standard tagged templates, with compiler support.
-
-
-
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.
This is interesting because it's a bit like Svelte, but it doesn't use the Svelte "language" (which looks like JS and HTML but, in some crucial ways, sometimes isn't).
It's a little disheartening to see that it's 3+ years old and has only had a single significant contributor though[1].
It's impossible to avoid single-contributor projects in the JS world, especially with Node, but the alternatives (React, Vue, Angular, and even Svelte) are orders of magnitude more popular, so it's one area that we can play it safe if we need to.
1. https://github.com/solidjs/solid/graphs/contributors
https://github.com/solidjs/solid-docs/graphs/contributors
We would have never gotten the docs translated into 15 languages otherwise. I do agree that one should be cautious regardless. But I don't want to underplay the contributions of many contributors putting in improvements every day.
Like the author of this post, I appreciate Solid's API because component's only render (i.e. run) once by default and then you define which sections of the component should re-render on changes by using "signals" provided by the library (e.g. `createSignal()` and `createEffect()`). In react, the entire component re-renders on every change and you need to specify which code should _not_ re-run. This was necessary because of the way react was created, but strikes me as fundamentally flawed.
Having used Solidjs for some pet projects, I've come to strongly prefer Solidjs over React. It's an evolution of react, so I've found my existing skills/knowledge transfers. This being said, Solidjs is brand new and the ecosystem is minuscule compared to React. For this reason, I plan to continue using React for the foreseeable future. One of the biggest weaknesses of Solidjs is the lack of a "nextjs" like framework. It appears work is being done in the solid-start[1] repo, but it looks like it's still years away from being fleshed out. I want Solidjs to succeed, but I'm not interested in being an early adopter.
[1]: https://github.com/solidjs/solid-start
The current implementation looks a lot like my current favorite state framework, Recoil - https://recoiljs.org/
[2]: https://github.com/solidjs/react-solid-state
"UI state knows what its dependencies are automatically and only updates when they change" - you should check out [valtio](https://github.com/pmndrs/valtio).
Sorry for the "+1" chain but I want to express my agreement as well.
Especially when I compare it to Svelte and Vue (not solid, solid.js is just... good), If I look at component, with react it's way easier to say what's going to happen.
Aren't there gotchas? Yes, but sometimes it's just stuff JS lacks, and so does React.
I'm very excited about Records and Tuples in JS to help with the immutability, for example: https://github.com/tc39/proposal-record-tuple
This reminds me a lot of Clojurescript's Reagent https://reagent-project.github.io/ (link also has a counter example)
I've tried using bare React in the past (after using Clojurescript), because I wanted my project to be more approachable for outsiders. But I couldn't really handle the (to me, and the author) unnecessary complexity that's added.
I would even say the Reagent version is even simpler than the Solid.js version, because you're Clojure's Atom API rather than creating read / write functions. For the adventurous hearted I'd definitely recommend giving it a try!
I ran a profiling tool. I searched "zz" then deleted these.
Deleting it caused a 120ms UI freeze (and I notice it :p):
Profiling report: https://share.firefox.dev/3C3OhIq
Given I had slightly more entries (a hundred more) and that I had way more node per entry, it led me with way worse performance.
Instead of a plain list I have a little summary card per pokemon (which is why I have more node per entry).
The naive implementation in Vue run flawlessly(sadly no preview):
https://github.com/Kuinox/kuinox_pokedex/
Note that the react implementation do weird thing because I tried to get around the issue without success.
I've been maintaining a web component library with Lit for a while. Web components overall don't feel ready for primetime. Just making a custom input field and have it work with a is chore.
Just look here at how much overall code is needed to do it right: https://github.com/ing-bank/lion/blob/master/packages/input/...
After you get through all the inheritance and mixins it's thousands of lines
You might find this interesting: https://github.com/developit/htm#readme
https://github.com/dg92/Performance-Analysis-JS
The problem with JS is that the execution model is so nebulous, that performance advice basically boils down to - trust in Google.
Yeah? I wrote something to deal with it too (https://github.com/toastal/return-optics) 5.5 years ago. You arguably chose the wrong data as `(model, Cmd msg, Maybe extMsg)` instead of `(model, Cmd msg, List extMsg)` which would give you more flexibility and still functions as a monoid on [] instead of Nothing, but allows multiple messages shrug. I tried this approach more recently and it involved me having to encode all of actions in a massive tree and then I still had issues with certain messages including now having to UUID all elements that that previously I didn't need to think about. It was a mess, but the best I could do with the tools at hand.
If you compare this to Halogen (https://github.com/purescript-halogen/purescript-halogen/blo...) where you still have purity but can set up subscribers and listeners from any component. It's much easier to use and for some components like dialogs, it's much simpler. And this actually isn't the best example because with the latest Halogen, Portals (https://github.com/purescript-halogen/purescript-halogen/pul...) was introduced so you can launch a dialog on the spot instead of even needing to communicate between them at all.
Yeah? I wrote something to deal with it too (https://github.com/toastal/return-optics) 5.5 years ago. You arguably chose the wrong data as `(model, Cmd msg, Maybe extMsg)` instead of `(model, Cmd msg, List extMsg)` which would give you more flexibility and still functions as a monoid on [] instead of Nothing, but allows multiple messages shrug. I tried this approach more recently and it involved me having to encode all of actions in a massive tree and then I still had issues with certain messages including now having to UUID all elements that that previously I didn't need to think about. It was a mess, but the best I could do with the tools at hand.
If you compare this to Halogen (https://github.com/purescript-halogen/purescript-halogen/blo...) where you still have purity but can set up subscribers and listeners from any component. It's much easier to use and for some components like dialogs, it's much simpler. And this actually isn't the best example because with the latest Halogen, Portals (https://github.com/purescript-halogen/purescript-halogen/pul...) was introduced so you can launch a dialog on the spot instead of even needing to communicate between them at all.
https://tigervnc.org
Does some impressive compression tricks that results in it being remarkably snappy.
You may prefer to run Xvnc directly rather than use the wrapper script, depends how you want to set everything up.
I will be honest here that my setup is not properly automated yet because it's inside a jail on a FreeBSD install and the underlying box gets good enough uptime that my current half-assed approach hasn't yet annoyed me into finishing it.
There weren't any interesting gotchas though.