terandle

Wow a human employee in walmart in 2040, very optimistic take.

https://artificialanalysis.ai/evaluations/omniscience

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.

It's a good idea in theory, the perf just needs to be better. Maybe with bun.

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.

Blazor is not good at anything. Please stick with JS for the frontend .NET devs. You'll thank me later.

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.

Seems like Linus should be able to tap someone else to do 6.17 while he is on vacation

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.

[1] https://htmx.org/essays/why-gumroad-didnt-choose-htmx/

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.

They did solve it (from the guy that originally reported the suspense issue): https://bsky.app/profile/tkdodo.eu/post/3layw6wk5bs2b

Hacker News is a bunch of older grumpy folks that want to keep using jQuery. Also some had a bad time with classic redux patterns that were a terrible atrocity - but also not reacts fault, however they have a strong association with each other. Modern react w/ modern state management patterns is a joy to use.

Pretty easy to add runtime validation at the edges with Zod https://github.com/colinhacks/zod

Great thing is that the zod schema also doubles as your typescript type so you don't have to write a duplicate/shadow TS type definition.

Seems to be a lot of negativity around RN, and I can understand that if you haven't used it in a while. But these days I have nothing but great things to say about React Native when used with Expo. It's great to want custom bespoke individual native apps for each platform but as a solo dev that just isn't really practical and RN has enabled me to ship things I wouldn't have been able to otherwise. Also that hot reloading react DX is just great in general. And I really want the RN model of using the platforms native controls to win out vs rendering everything to a canvas like Flutter.

Can't wait to try out the new arch when 0.76 lands in expo.

Great release! People should be much happier with the new caching defaults.

This is why I think react is still the best: In react you only deal with plain values. You never have to worry about wrapping a value in an observable or calling it in a function with a tracking context. Or .valueing it or whatever.

It looks like Svelte 5 is trying to make signals "disappear" but they still leak through. Reading the docs about shallow $state.raw vs deep proxying the default $state rune in svelte 5 makes me really appreciate the plain value and simpleness of react.

The react compiler will make the biggest headache of react go away, that being useMemo, memo, and useCallback.

React has the biggest and highest quality ecosystem. It has the smartest and brightest people in this space working either on react directly or in the immediate surrounding ecosystem. React has by far the most $ backing it.

Looking ahead I think react makes the best immediate AI target. Long term AI will go past react but while we still want to vet the code with humans react will probably be the best target.

Thought of another important reason why I love react:

- It has the best TypeScript support of any framework. Partly because MS is so invested in react the typescript team is very incentivized to have good support for them.

Oh yeah and this one is imporant:

- React Native with expo is the best way to make cross platform mobile apps. Yes its better than Flutter.

Beware the footguns!

https://mareks-082.medium.com/dark-side-of-the-primary-const...

Let's just say they could have done a much better job on it. It feels rushed and haphazard for such a mature language.

Been using .net since 2.0 and nah C# has jumped the shark. Primary constructors are a very poorly designed feature that for some reason was added in the last version.

The new-ish yearly release cycle I think is mostly to blame, they feel like they need to add some headline features every year but the team also, maybe due to org-chart politics, seems to not really able to make deep runtime level changes that are needed to actually add anything useful so they just add syntax sugar every year bloating the language.

I would say react server components are fundamentally different.

PHP starts off powered by the state on server (database etc) and ends there when it hits the client unless you hand it off to a completely different language/system: JavaScript.

It would be really nice if you could instead keep writing PHP-for-the-client which would let you reuse your templates/PHP code/etc but keep all the state on the client so you can instantly do things without round trips to the server.

That's what RSCs are and they are pretty great IMO.

Is Singals coming to Angular not shiny object syndrome?