[HN Gopher] The new wave of JavaScript web frameworks
___________________________________________________________________
The new wave of JavaScript web frameworks
Author : remrem
Score : 53 points
Date : 2022-09-24 08:10 UTC (14 hours ago)
(HTM) web link (frontendmastery.com)
(TXT) w3m dump (frontendmastery.com)
| meitros wrote:
| 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.
| stevenfabre wrote:
| True! I would also include https://liveblocks.io to that list
| of services that help developers make multiplayer experiences.
|
| Interesting to see more players in this space to help more and
| more developers do this.
| meitros wrote:
| Liveblocks looks great, thanks for mentioning! Will try it
| out sometime
| dtagames wrote:
| 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.
| metadat wrote:
| 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.
| dtagames wrote:
| Indeed. I wrote a whole series on it. I don't post this every
| time I comment, though. :-)
|
| https://link.medium.com/RpKPYCuwAtb
| derkoe wrote:
| Great article but the resumable framework is called Qwik not
| Quik: https://qwik.builder.io/
| eurasiantiger wrote:
| 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.
| mcluck wrote:
| 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.
| tln wrote:
| GraphQL isn't a web framework though.
|
| ----
|
| 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
| [deleted]
| eurasiantiger wrote:
| You're right, but for example Apollo is a widely used GraphQL
| framework for both server and client--yet it was not
| mentioned.
| matt7340 wrote:
| 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.
| dtagames wrote:
| 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.
| Bellend wrote:
| 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.
| dtagames wrote:
| What is left to do? It's syntactic sugar for browser
| standard stuff. It doesn't need to change, ever. That's an
| advantage.
| rk06 wrote:
| 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
| ehnto wrote:
| > 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.
| andy800 wrote:
| 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.
| seydor wrote:
| Has anyone thought of creating an engine that creates web
| frameworks?
| vinibrito wrote:
| We could randomize the overlaid syntax taken from other
| languages.
| klysm wrote:
| 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.
___________________________________________________________________
(page generated 2022-09-24 23:02 UTC)