-
It seems to me that a lot of people are forgetting that when updating to next major version of a package, breaking changes are expected - that's the whole point of major version number in SemVer [1]. What they actually want is seamless updates (or never changing APIs, but that not possible in most situations, and also not what you want as a package developer - you want to be able to correct your API design mistakes). That requires a lot of work from the package developers.
Look for example how people at Remix do it: breaking changes are hidden behind future flags [2], so you a user can turn them on one by one and adapt their code on gradually without surprises. Another solution is creating codemods for upgrades. But how many open-source package developers are willing do to this extra work?
Same story with peer dependencies - they're completely fine, if package developers know how to use them.
As always, don't be mad at React, don't curse Npm, it's not their fault. There is no great package without great effort.
[1] https://semver.org/
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
gowebly
🔥 A next-generation CLI tool that makes it easy to create amazing web applications with Go on the backend, using htmx, hyperscript or Alpine.js, and the most popular CSS frameworks on the frontend.
That's Go's out-of-the-box experience. Maybe you're looking for something to scaffold projects? There are plenty around, I've been using https://gowebly.org
-
I'd highly recommend reading some articles by Luca Palmieri[1], or even buying his book[2]. Although I didn't learn this stack by working through his book, whenever I had questions through the years, my searches usually led me to his articles which are often excerpts from the larger book.
The high level of API stability and lack of churn in the Actix ecosystem makes the book a particularly good investment for someone looking to settle on this stack in my opinion. In keeping with the topic of this submission, I doubt I'd be comfortable spending money on a similar book about building web apps with React.
[1]: https://www.lpalmieri.com/posts/2020-08-09-zero-to-productio...
[2]: https://www.zero2prod.com
-
> I just restarted a personal project on rails because of its batteries included mentality - it means I can limit the number of dependencies
https://github.com/rails/rails/blob/main/Gemfile.lock
Just a playful comment - not challenging your experience
-
clace
Hypermedia based internal tools for teams. Application server for containerized apps. Runbook automation like Rundeck, custom apps like Retool.
I have been building a platform https://github.com/claceio/clace for teams to develop Hypermedia based internal tools. One of the main criteria for the technology stack and the feature set has been making sure apps can be maintained easily, after six months and after six years.
Settled on using Go HTML templates, Starlark and HTMX. Go has a great track record of not breaking backward compatibility. Go templates are widely used by ops teams, any breaking changes there will cause ops teams to revolt. Starlark is somewhat widely used by build systems (like Bazel), any breaking changes there will cause build engineers to rise up in arms. The HTMX 1.9 to 2.0 upgrade was also painless, no changes required in my test apps. Only change required was to update the way the websocket extension is resolved.
-
> JSX is a really elegant way to avoid templating, but we're back to templating with HTMX
Not necessarily. There are libraries in all mainstream languages that let you embed HTML generation directly in your backend server itself, without using a templating engine. Some examples:
Python: https://htpy.dev/
Scala: https://com-lihaoyi.github.io/scalatags/
OCaml: https://yawaramin.github.io/dream-html/ (that's mine)
> Routing, state management, auth, components, theming, API access, and more are all still problems that people add libraries for and those problems don't go away
Actually they kinda do go away. Have you ever tried Ruby on Rails? It does all this out of the box.
-
> React is a small rendering library
Sorry, can't agree. React is a state management library that also attaches efficient rendering on top of the DOM diff it computes as it propagates the state changes.
This allows React apps to remain so simple (one function per component) and so composable without turning into an unmanageable dish of callback / future spaghetti.
There is a number of other VDOM libraries, but what sets React apart is the data / state flow strictly in one direction. This allows to reap many of the benefits of functional programming along the way, like everything the developer sees being immutable; not a coincidence.
Regarding the size, preact [1] is mostly API-compatible, but also absurdly small (3-4 kB minified), actually smaller than HTMX (10 kB). But with preact you likely also want preact-iso, so the size grows a little bit.
[1]: https://preactjs.com/
