It's been mentioned a bit on HN but HTMX is brilliant and along with AlpineJS, you have immense power despite very little JS, or even none at all. With almost everything happening on the backend, you can focus almost all development energy on using the language of your choice. As a Kotlin fanboy I absolutely love this paradigm and am writing entire sites in my favorite language (huge shout-out to jte.gg, a native templating engine). Just in the past few weeks I've built numerous functions/features/pages in a day that would have taken weeks or more to do with Vue or React.
> This makes it easier to move a lot things currently done in the browser back to servers. While somewhat mitigating the network latency tradeoff that’s made by doing that.
I think the network latency of reaching out to a server instead of a CDN edge node was greatly overstated, especially when we then immediately fire off other requests for assets and hydration. This quote was in the context of comparing MPA to SPA architectures and tradeoffs.
Fantastic article, very impressive coverage and matches my experience quite well.
Another article about web dev that fails to mention bare metal web components and Lit. How does this keep happening?
While it's true that bare metal web components don't handle routing or state for you, in many apps those are problems that you can solve yourself -- and in a way that makes sense to you, rather than to the framework developer.
In my experience with Lit and bare metal (browser standards-based) web components that you hand-craft (not from a library), there are fewer bugs and the ones that exist are ones you designed -- rather than ones that come from a misunderstanding of a framework. Without a framework to learn, your cognitive load consists of only your own inventions and abstractions -- which are far easier to remember and deal with than something designed by a committee and documented with some largess.
Ignorance is the norm until the information spread reaches critical mass.
You could help spread ideas you consider worthwhile (presumably the ones you mention) by providing concrete links to the things you are talking about, especially information on how to properly take advantage of them. I've never heard of Lit and/or bare metal, and don't know where to begin.
I also consider myself proficient in React and Angular.
I skimmed this article and I’m confused and must not be understanding it.
It talks about bare metal vanilla components without any frameworks and such. This has my attention. But it ends with “here’s a library on top of web components called Lit!”
Are web components not good enough yet? Why do I need anything?
It's not a library. No components ship with Lit. It's just syntactic sugar for stuff that's built into browsers now. That's the "bare metal" parts. You need to write your own components and make your own library for your company or project, although some big firms like IBM, Alaska Airlines, and MS have released the libraries they made with it.
This fact, that it's the "anti-framework" (ie: not a framework) is both its greatest advantage and its biggest source of confusion for new folks.
This wasn't mentioned in the article but IMO belongs as the last section of the timeline -- To (one of) the points made in https://news.ycombinator.com/item?id=32959397, the latest wave of Javascript frameworks wants to answer: how can we build apps like Linear or Figma in the browser? https://replicache.dev/ is the most direct example of this, and https://cord.com/ is an example of a service to add multiplayer elements in a non-framework way without rewriting the way your app works. Also know of one that still hasn't launched yet.
IMO this newest wave is creating frameworks that have existed in the mobile app world for a while and are now showing up for productivity-oriented web apps.
Nice overview, especially for those of us working long term projects and locked into whatever framework the originals devs chose. I wish I had time to try all these things out, but it’s tough to keep up.
Interesting that angular, and especially angular 2, only gets a passing mention.
Google itself has moved on from Angular. They invented Lit, the anti-framework, which has far less scaffolding and cruft and is based on browser standards.
Google is a very big company. They have maintained polymer(now reincarnated as lit), angular and angular dart. No reason to believe that there will be a change in status quo
Not sure I follow this? Lit seems to be hanging on by it's fingertips? It's official starter's dependencies is (was very recently)? painfully outdated. Angular continues to evolve with what seems to be many more people working on it and a budget.
You joke, but a lot of libraries frequently have templates of them integrating with other JavaScript things. The Cartesian product of sensible choices is so large, you could effectively think of each one as a web framework.
The article doesn’t seem to give enough weight to GraphQL: it’s only mentioned in passing even though it solves the waterfall request problem mentioned much later in another context.
Hot take: a lot of usage of GraphQL is terrible and most apps don't need it.
For example, I worked at a place where it was a requirement that everything runs through GraphQL. Sure, fine, except then you see that they were making tailor-made resolvers for particular use cases. You wouldn't see multiple different apps or sections of the app pulling from the same endpoint but with trimmed down queries. It was essentially BFF but with a GraphQL middleware because "it's what big companies do." I've had a number of friends say they've seen the same thing. I'm sure when you're working with applications like Facebook and you're using it intelligently, it's great. My experience is that many people don't understand that.
I agree, that is a problem: people forget the ”graph” in GraphQL. It’s too easy to just create new query resolver to resolve that one ticket instead of thinking how data relates to other data and how it could be resolved using that other data.
That is ultimately a people problem, however: why doesn’t it click that a ”resolver” is intended to ”resolve” other entities based on fields of the parent entity?
I wonder if GraphQL is destined for the same type of evolution; React was a revelation compared to what came before, hugely popular, with a heavy client library and runtime costs. I see some of those in GraphQL
The new wave of svelte and quik etc are faster and lighter, by pre-compiling or rethinking how and when the work is performed
