The wonderful thing about glimpsing into the future is that the path is never completely clear. We can look at trends, and look at innovations and ...
For further actions, you may consider blocking this person and/or reporting abuse
Insightful as always, Ryan. I find it inspiring that we are using tried-and-tested patterns and put them inside a new abstraction that allows for isomorphic front-ends without making too many compromises in terms of bundle size and performance.
I too think that we'll see a convergence of frameworks towards reactive signals. I also think that tools like Mitosis will help people to become more mobile between frameworks.
Looking forward to 2023 and I'll see you on the other side of this year!
Great insightful article. I always stick by 'its what you create not how you create it that counts' . Frameworks will come and go, but they all produce the same thing, html, CSS and Js. Frameworks should be used where appropriate and not always the defacto go to. Quite often, inexperienced Devs think they need to use one, even for the smallest amount of JS where the footprint (or point) of the framework does not fit. As Devs we have to be mindful that business often don't care about the latest framework, just productivity, hence the rise of low code platforms.
That said it's nice that articles like this share latest thinking to allow people to make the decisions as to whether it's just more of the same (so stay as is) or it's a significant enough shift to take more notice of.
Well said.
Great write up Ryan! Excited to see where 2023 takes us. 😎
Oh why did I bother... lol Every year we change this. I'm always skeptical, then I come around mid-march, start to learn and believe in april/may, develop it into a new system or platform by July and compete it by November/Dec, or implement composed based development in some form or another which is good. Just modules and now going back to server side. I came from Serverside I should have stayed serverside. I'm grateful for learning all that i have though I've been raking it in with #Next #Nuxt and #Gatsbyjs fast optimization-based libraries and frameworks coupled with typed-script driven language libraries like react. Not regretting Gatsby or Next one bit.
Great article! I'm loving
solid-start!My DX wish is if
createServerAction$form.get()could be fully typed from a generic.Informative...!!
Good Job.
What did you mean by “moving away from client-side caches [doesn’t] meaningfully changes the math”? I really have no idea…
The micro-trend to refetch everything on any mutation or use browser in built cache. In contrast to JSON cache like you'd find in React Query, URQL, or Apollo.
I realize these are both client side. But I meant cache in managed in JavaScript. This can reduce the size of data fetching libraries. But more commenting on the savings might be in the range of 5kb or something and doesn't really impact size much overall.
Got it! So all you are saying is that moving from artifical JS caches to built in browser one's doesn't save much in terms of bundle size?
Yeah, I mean the savings on library size is something. Apollo is 30kb, but URQL is 9kb, and SWR is 5kb I think and it isn't like the libraries using the browser cache aren't a few kb themselves.
It's been suggested that this somehow saves more but that is the result of just moving more logic to a backend API, you could do that regardless of the mechanism. Like saving on using
momentor something in the browser.So I think the win is that people are conscious enough to do better things but not so much that the technology itself changes very much in terms of bundle size. This portion of the win can be done at any step, but I suppose it gets more obvious.
By default everything ends up in the client. These cacheless solutions suggest doing stuff on the server. Things like Partial Hydration end up dropping enough peripheral code that those things and more don't end up in the browser.
I just hope that 2023 will be the year when java and .net devs will finally stop looking down on javascript/typescript devs. I know its idle hope :P
What a great great article !
Good thoughts, thanks for this article!
This article is food for thought, thanks for sharing it Ryan!
Great post.
Loved this post @ryansolid !
Well written and insightful as always.
This article is where I'm getting my "how good is Rust" updates from LOL. Thank you.
I appreciate the overview of trends and reasoning behind rise/falls.
Great article! Curious about what 2023 is going to bring us!
I generally have always tried to build for the lowest common denominator. And that means people who have turned off Javascript in their web browser should not break the app. Some organizations disable Javascript for organizational security reasons (e.g. defense contractors working in Classified environments). Javascript is nice when it is enabled but I don't just assume it is. Server-side rendering has gotten a lot faster in the last two major PHP revisions (7.x and 8.x) due to major rewrites of fundamental data structures to take advantage of the design of hardware features (e.g. CPU pipelining).
Yet, I think people should write code in whatever way works for them. Unless someone is actually a massive entity like Google or Facebook with 10,000+ servers across hundreds of data centers, rendering everything on a single server is fine for 99% of all websites. Server-side is also a lot easier to work with and correctly handles application security scenarios.
Javascript frameworks are largely a hack until the browser vendors pick the best bits and integrate them into the mainline browser. jQuery had that effect (i.e. how native event handling was improved). Bootstrap had that effect too (i.e. how we got CSS Flexbox and Grid). So future predictions should probably be more along the lines of what is likely to make it into a future web browser release from existing frameworks. That's the sort of game-changing future that matters. Everything else is stuff that can change on a whim.
I used to feel as you, but given the nature of the industry, I've adjusted my attitude.
I prefer to target the 80% in my application development and don't believe that necessarily includes the "lowest common denominator", (nope, I don't believe it's worth spending any time supporting diehard IE users either) nor do I find considering that audience particularly interesting, so I'll leave leave the coverage of those folks up to those who feel as you..
From a business perspective any audience that can be cost effectively reached is interesting.
So far "the industry's" preoccupation has been on developer convenience as it relates to time to market.
Meta frameworks like Remix, SvelteKit and SolidStart aim to deliver developer convenience while also creating the opportunity to create solutions that reach the broadest possible audience over the web.
Thought I’d also share my JS framework predictions for 2023:
(growth in terms of npm downloads and github stars)
React, React Native, SolidJS, Svelte, Vue, Astro and Qwik will all experience enormous growth during the year.
Redwood and Remix will struggle to grow as much, but still grow some.
Remix will grow more than Redwood. (Not a very spicy take, but still).
React and Next.js will still dominate all competitors in absolute terms, and continue to grow,
but React Native, Svelte and Qwik will grow much much more (percentage wise).
«The year of React Native» on native/crossplatform, and
«The year of Qwik» on web, certainly mind share wise, but also growth wise.
Styling:
Tamagui will be pretty hyped, mostly in React Native and mobile crossplatform circles, and grow greatly (more than 3x amount of npm downloads and github stars).
But will be dwarfed by the meteoric rise of Nativewind. «The year of Nativewind» on native/crossplatform. Which will be fuelled by the fact that
TailwindCSS is still dominating amongst modern web styling tools, and will >2x its amount of downloads, and grow around 18% in github stars by year end.
What do you think about AI and automated code generation? btw it was nice read.
What does this mean? "now we need the code not only to client render but to hydrate the page." Perhaps, refreshing the state? Thanks, good read so far.
"Hydration is the name given to the process in JavaScript frameworks to initializing the page in the browser after it has previously been server rendered…"
Why Efficient Hydration in JavaScript Frameworks is so Challenging
Ryan Carniato for This is Learning ・ Feb 3 '22 ・ 9 min read
i.e. "replaying" the client side "page application" state to the point that it is synchronized with the (HTML and resulting client DOM) representation as rendered by the server.
Conquering JavaScript Hydration
Ryan Carniato for This is Learning ・ Mar 21 '22 ・ 5 min read
Beautiful, thanks for the clarification my friend :-)
Htmx and AlpineJS made quite an impact on existing workflows. Language diversity will be a thing to get the job done in novel/groundbreaking works.
Less js for client.
More duty on server.
Server sending html and fine-grained event handlers and incremental data to client.
Sounds like all is going to qwik.
;))
Or furlther, then no need to use nodejs
on server side... Finally we will get a qwik written in go or rust. 😂😂😂
i think so