... I remember inventing signals circa 2005 for a knowledge graph editor I worked on in GWT back when I didn't care about knowledge graphs. Not long after that I was using similar concepts to develop a complex Silverlight decision support application for sales territories.
I'm still a little appalled that people have forgotten how to make HTML form applications like we made in 1999 and frequently use React for things that don't really need it. React has, I think, one of the most elegant methods of implementing a widget set ever invented (sure beats XAML, FXML, Visual Basic, etc.) but it doesn't support a real answer to maintaining application state that would be adequate for applications as complex as RIAs made by early adopters in 2005.
which works like a cross between VRML and Unity Framework. Here you can easily build a virtual world that people can experience with desktop, mobile and VR headsets. Something you can't do with HTML forms!
I have a few side projects based on HTMX but I am pretty sure we will see something like it but better soon. In particular back end frameworks need to be updated for the new reality. Often you have a "component" like a dropdown box which can either be drawn as part of a bigger page or updated on its own and you really need some way you can reuse the HTML template for those purposes and hopefully also reuse associated code that does database lookups and such.
I swerved out of the way of the Flux architecture that took over the mainstream and kept using “uncontrolled” forms and a much simpler and more sane approach to state management. You know, treating a view as a view.
My current approach is using F# and Fable to compile to a React app that uses parallel client/server express middleware to support the same code handling a client without JS enabled as the SPA that handles when the client does have JS.
This is a good article, but I think the "future of web development" is using native web APIs for like 99% of everything.
I'm really sick and tired of framework churn at this point. I don't like any of the options. I don't want React, Solid, or Htmx. I don't want Turbo or Alpine, I don't want Svelte or Solid.
I don't even use Lit anymore most of the time.
Give me vanilla* or give me death!
* (and a smattering of _very small_ libraries which do only one thing and one thing well. Signals from the Preact team is pretty awesome in this regard because you can just use the signal/computed/effect however you like. Create your own component architecture. Stick 'em in custom elements. Anything. We need a lot more of that!)
It's in the top tier of options available... but there are a lot of contenders for "top tier" so I guess that's just, like, my opinion, though State of JS has ranked it in the top 2-3 frontend libraries for satisfaction for the last 2 or 3 years I believe
Cool; thanks! Just due to not really paying attention to FE, I'd never really heard of Solid, but had heard from more conversant friends that Svelte is way more enjoyable than any other library they'd worked with in awhile. By this I mean people who cut their teeth on like...ext and webforms and spent a good part of the last decade working in various SPA frameworks.
I'm still a little appalled that people have forgotten how to make HTML form applications like we made in 1999 and frequently use React for things that don't really need it. React has, I think, one of the most elegant methods of implementing a widget set ever invented (sure beats XAML, FXML, Visual Basic, etc.) but it doesn't support a real answer to maintaining application state that would be adequate for applications as complex as RIAs made by early adopters in 2005.
My favorite use for React is
https://aframe.io/
which works like a cross between VRML and Unity Framework. Here you can easily build a virtual world that people can experience with desktop, mobile and VR headsets. Something you can't do with HTML forms!
I have a few side projects based on HTMX but I am pretty sure we will see something like it but better soon. In particular back end frameworks need to be updated for the new reality. Often you have a "component" like a dropdown box which can either be drawn as part of a bigger page or updated on its own and you really need some way you can reuse the HTML template for those purposes and hopefully also reuse associated code that does database lookups and such.