Yeah Vite+Reat+Tanstack SPA apps is definitely the way to go for a majority of web apps. I would still stick with nextjs for ecommerce or pages that need to load instantly when clicked from google however.
I'm anti-establishment because the establishment doesn't care about anyone but themselves. What are we doing all this work for? Progress would be getting universal healthcare for all in this country. Getting better work life balance. Being able to afford a home. Now it's just all the "haves" fighting bitterly to keep getting more and more until they have everything and nothing for anyone else.
> Think of it like WWII, only only instead of planting victory gardens to beat the Nazis, we're building AI apps and finding ways to create the economic value needed to cover the reckless bets being made by the elites.
LOL fuck this, the stock market deserves to burn to the ground.
I think HN is it's own anti-react bubble that really doesn't match reality. Everyone here decided they hated react in 2016 or whatever and doesn't want to update their worldview to the reality that react is frankly an amazing tool today.
Kind of sad to see a 2022 paper about svelete with extremely questionable benchmarks get upvoted so much vs all the great things that came out of react conf yesterday.
Have had our apps on expo for a while. Highly recommend, much easier upgrades and you can turn off any platform vendor stuff like their OTA updates and do local builds also. Expo + RN has saved us a ton of time on our apps and no way a small team like us could support both platforms otherwise.
Performance of WASM issues. Rendering performance of large data grids is not good. Also the first load time is also terrible 50mb+ payloads.
Blazor server uses websockets and is just a whole other bag of hurt. You'll have to deal with disconnects even if you can stomache the increased cloud costs.
Yeah there is basically no real difference between MVC or RazorPages or BlazorStaticServer pick your poison depending on your preference. Personally I wish the .NET team would just add components to MVC and RazorPages then we can forget about Blazor.
Blazor static server side + HTMX is probably the only way to make a cost efficient and performant version of Blazor suitable for public websites. WASM is way too big and slow, Websockets take up server resources and cause problems with timeouts where the user has to refresh their screen losing all state.
I think nextjs does lead to a very simple codebase at every step of the interactivity gradient. You can have pure server side rendered HTML all the way up to full blown SPA and everything inbetween with just one tool rather than having...
1. HTMX itself
2. Your backend language Go/Java/whatever
3. Whatever JS framework for your interactivity islands
But yes we are all on the same team here of reducing complexity in the codebase and if HTMX works for you go for it.
HTMX has a ceiling on how interactive/complex you can make your site [1]. If you know you will never need to exceed those sure. However I like to use nextjs as it gives me the peace of mind I will always be able to pivot or implement whatever the customer wants.
Which is why I think react (and other SPA frameworks) are now pointing beginners to full stack frameworks like nextjs, remix etc where those best practices are baked in. It took the JS frameworks a bit to find their path there but I think they are there now.
Yes but in 6 months react will release a compiler to catch it up by a lot. Performance has diminishing returns and at some point, things just need to be fast enough (see vscode) and the industry will continue on as the switching cost is way too high.
If building a SSR site with nextjs use react server components and react context
If building a SPA site with vite use tanstack/react-query and react context. There are other great libraries like zustand and jotai that can make sense in certain kinds of more complex applications.
jQuery fell apart HARD when you started to build larger/more complex apps with it. I don't think there is anyone actually nostalgic for that time that actually went through it. For a while SPAs had their own disadvantages vs MPAs but newer web standards and SPA frameworks adopting SSR have basically solved those problems nowadays.
Being able to <Context value={1}> instead of <Context.Provider value={1}> is also a nice, albeit small, QOL change. Feels like they are really honing down the API. Esp once they kill off useMemo and related hooks with the compiler.