91–100 of 225 posts
I don’t want server side react. It’s disappointing to me they’ve gone so hard on server side. It feels like Facebook use it server side so they’ve lost interest in being purely client side.
Earlier quoted context omitted.
A lot of people still mix jQuery and React in the same parent project. Mostly just via legacy support when using existing serverside frameworks but still sometimes having the fallback easy DOM/event stuff is just easier when you need to get it done (keeping the HTML/views isolated from each other of course so you don’t mix concepts). It doesn’t sound pretty but they can serve dual purposes. I don’t know enough about…
I am sure you can do something with it… But htmx is all about replacing server rendered html with server rendered html partials. I would like to see what reacts vdom does when you keep ploping some partials into DOM it thinks it controls.
I think to sway the only benefit of Next.js is DEO is underselling how useful it is. Sure SEO is important for most people anyway, but having multiple pages that load instantly rather than having to wait for a server call is also pretty handy. Plus auth working better. I don’t see why next wouldn’t be the default and react now the outlier.
So after graphql, micro services, nosql and serverless, the SPA + "libs not framework" crowd join the "woooops!" club. Ignoring the noise is really becoming a key skill to survive as a programmer.
I don't understand the pivot back to SSR. Tearing down and standing up the entire DOM and page memory between navigations is just unnecessary work. Little things like maintaining scroll position in the page's navigation bar meaningfully improve usability and are only achievable with a SPA-based approach. This doesn't discount the challenges of building SPAs: bundle sizes, performance, etc. can be concerns if not mana…
Fullstack react frameworks aren't purely SSR - they're isomorphic JS apps, which can render an initial page load serverside, then use clientside routing, suspense, serverside components, and clientside rehydration to progressively update the DOM without a full page refresh. They are basically delivered as SPAs, with an integrated, isomorphic backend-for-frontend service embedded in the origin server. They just don't…
1. There is a significant gap between dev and production environments. (See #2 why this is critical)
2. The production build times are super high
3. ES modules are great, but the JS ecosystem being a bundle of small libraries, getting them all to play nice is hard.
4. I occasionally get X is included twice errors that are painful to track and debug
5. There are frequent instances where I find out that the very problem I had has been solved by someone, but they don't know how or why. They remove a, b, c then it works. They add it back, it still continues to work.
What happened to KISS?
Does anyone else feel that the complexity of the full-stack frameworks is getting untenable? 1. There is a significant gap between dev and production environments. (See #2 why this is critical) 2. The production build times are super high 3. ES modules are great, but the JS ecosystem being a bundle of small libraries, getting them all to play nice is hard. 4. I occasionally get X is included twice errors that are pai…
I have been in software for about a decade and I think I’m experiencing my first complete cycle of “what’s new is old”.
Does anyone else feel that the complexity of the full-stack frameworks is getting untenable? 1. There is a significant gap between dev and production environments. (See #2 why this is critical) 2. The production build times are super high 3. ES modules are great, but the JS ecosystem being a bundle of small libraries, getting them all to play nice is hard. 4. I occasionally get X is included twice errors that are pai…
Late last year I listened to talk on nextjs and I was floored by its design. I still can’t get over that the JS community has embraced file system routing and server rendered stuff. I honestly think I’m taking crazy pills because I could have replaced “nextjs” with “PHP” in most places and it would still make sense. I have been in software for about a decade and I think I’m experiencing my first complete cycle of “wh…
Does anyone else feel that the complexity of the full-stack frameworks is getting untenable? 1. There is a significant gap between dev and production environments. (See #2 why this is critical) 2. The production build times are super high 3. ES modules are great, but the JS ecosystem being a bundle of small libraries, getting them all to play nice is hard. 4. I occasionally get X is included twice errors that are pai…
I'm still waiting for preact.js + htmx.org mashup. It probably exists somewhere, maybe https://docs.astro.build/en/concepts/islands/ or something. I just want a quick way to throw some react hooks or web components into a dom element using a library that is less than 1,000 lines of code.
Sorry but thats not a good combo. htmx is literally html extension. it is aimed at adding interaction to static html. Preact/react are completely opposite approach to that.
Preact is the tiny alternative to React (I still think preact could be smaller if they only focused on hooks).
I htmx is too bloated, while it's much smaller than the React codebase - I want the tiny, <1k loc alternative that literally just makes working forms and href links into dynamic fetch() responses and maybe adds additional support for auto-refresh from websockets or SSE.