Live data from Hacker News

Things I wish I knew before moving 50K lines of code to React Server Components

mux.com

471–480 of 540 posts

Re: Things I wish I knew before moving 50K lines of code to React Server Components

#471
post #468

Earlier quoted context omitted.

That could've been said about Java too but it doesn't mean it doesn't stick around. Complexity is orthogonal to sticking power.

On the frontend, Java was dropped fairly early on. Long before the iPhone effectively killed plugins. The backend has always been less prone to singular dominant monocultures, had far more stickiness, and greater diversity of implementation than frontend. There are 1980s mainframes still running COBOL, especially in older, more conservative industries like banking. Those same banks have cycled their public web front…

Java is still widely used for Android, not to mention its usage in enterprise backends. I agree with you though, React will stick around for quite a while, just like jQuery.

Re: Things I wish I knew before moving 50K lines of code to React Server Components

#472
post #469

Earlier quoted context omitted.

Nah, I still think React made the right choice. I used to use functional languages so coming to the JS world and seeing that no lessons from that world were learned was disheartening. React, where UI = f(state), is an amazing model compared to the imperative jQuery model of before.

You may prefer it to jQuery's model, but that doesn't make React's model good. Try SolidJS. Similar ethos to React but far less boilerplate and performance-killing repaints. Less code is better, functional or not.

Sure it does, it is good because it's functional. I could similarly write a convoluted yet highly short Perl expression, less code is not always better.

I tried Solid. Signals are not new, I've used Knockout before and it turns into a spaghetti mess after a few years. I guess people today simply aren't old enough or experienced enough to know what eventually happens with fine grained reactivity.

Re: Things I wish I knew before moving 50K lines of code to React Server Components

#473
post #470

Earlier quoted context omitted.

> I have yet to see a React project with more than five contributors fail to turn into a big ball of mud within 18-24 months, requiring either a periodic rewrite or resigned acceptance of trudging through large volumes of mud to get anything done. Not my experience at all, and I've been working with React for years. I've seen companies successfully transition to functional components from class components, all while…

I never said it wasn't successful; I said it had successfully increased complexity. I am glad you are an experienced React developer. React needs more of you, because the vast majority aren't. That said, I have little doubt your and your team's experience could implement with most other frameworks as well—frameworks with a shallower learning curve, just as much power, greater performance before reaching for useMemo(……

True, it does take more experience, but there are footguns in any language. Personally, having used Knockout, I see that signals are not the future, because I guarantee in 5 years, just as with Knockout and RxJS, there will be articles out on how signals create a spaghetti mess of code. So I'd rather take React verbosity if only because I know where the alternatives lead.

Now if there were a performant version of the core React philosophy like Preact is (or React with their upcoming Forget compiler) I'll gladly take it, but it seems that frontend libraries these days are trending in the wrong direction.

Re: Things I wish I knew before moving 50K lines of code to React Server Components

#474

Earlier quoted context omitted.

To me, that is a separate level of decision. Sure, you could avoid the whole problem of building a docs generator by using an off-the-shelf docs generator, and letting the Redoc and Swagger dev teams deal with all the development complexity. But if you are going to build your own docs generator, React and Next with RSC aren't a bad choice. Web development just isn't as simplistic as people on HN seem to think it is.

I agreed with most of your comment but this almost triggered me: > React and Next with RSC aren't a bad choice. Web development just isn't as simplistic as people on HN seem to think it is. Yes it fucking is. I've been doing it for 15+ years and most of the complexity added since about 10 years ago is not required. Many times they're actually regressions. The web is complex because we made it so. This is a perfect ex…

You are of course right. But probably they got VC cash and some guy said, do it in React bla bla whatever the cost…

Re: Things I wish I knew before moving 50K lines of code to React Server Components

#475

Earlier quoted context omitted.

Good lord it’s awful haha. Some more unhinged stuff I noticed: - swiping backwards exists the drop down menu for some inexplicable reason - clicks on menu bar items take so long I genuinely thought I hadn’t tapped on it correctly. - taps on the menu bar sometimes just don’t work. Like, at all. Oh scratch that, the menu was there after I swapped tabs to write this sentence. - massive chunks load in at different times:…

There's something to be said for optimistic routing, server or client side. It seems like they're using suspense to wait for the page to be rendered before swapping the route. It's a noticeable breach of the standard pattern of instant navigation, and then wait for content to appear.

I really wish it was possible for users browsers to opt-out of stuff like this. I don’t want some unhinged developer deciding they’d like to arbitrarily delay things like this, just render the page and stop making things worse.

Re: Things I wish I knew before moving 50K lines of code to React Server Components

#476
post #437

Earlier quoted context omitted.

> As long as a framework invents their own HTML-like DSL, I'm not using it. Okay, that's a choice. > I wanted to move to React where I can use actual JS You… uhh… know that JSX was literally invented as React's own HTML-like DSL, right? And that TypeScript is not "actual JS", right? Just food for thought: HTML can exist and provide tremendous value on the frontend without JS. JS on the frontend without HTML is… not q…

I knew this comment was coming. JSX is not the same as the DSLs of Vue and Svelte. They often have poor support for TypeScript and cannot be mapped, folded over etc, because they are not "just Javascript with syntactic sugar," they are a much more rigid DSL. Trust me, I've made a lot of Vue sites, I know what it's like to use JSX vs that kind of DSL. Never mind that TS is a superset of "actual JS," your point doesn't…

My point was you were very TS/JS-centric with a preference for frameworks that embed HTML and CSS in JS instead of the other way around. Try Htmx?

Re: Things I wish I knew before moving 50K lines of code to React Server Components

#477
post #294

Earlier quoted context omitted.

Have you tried SvelteKit yet? I can't say it lacks magic, but that magic is focused on eliminating boilerplate, not hiding where everything is coming from and going to. It is jarring at first when you look at your code and say, "Wait, what else do I need to do?" And there's nothing left. const { count, setCount } = useState(0); becomes let count = 0; There is no more useMemo(…) or useEffect(…). They just don't exist.…

I think you just sold me on Svelte, and I am not joking - I haven't tried it yet, but I want to now.

Oh! I forgot one of the best parts! CSS is automatically scoped to your component. No manual shenanigans. No weird naming rules your dev team have to agree on. No giving up and just using inline styles. No hacks.

Just make a descriptive class name and write your CSS styles. That's it. You're done.

https://learn.svelte.dev/tutorial/styling

Re: Things I wish I knew before moving 50K lines of code to React Server Components

#478
post #476

Earlier quoted context omitted.

I knew this comment was coming. JSX is not the same as the DSLs of Vue and Svelte. They often have poor support for TypeScript and cannot be mapped, folded over etc, because they are not "just Javascript with syntactic sugar," they are a much more rigid DSL. Trust me, I've made a lot of Vue sites, I know what it's like to use JSX vs that kind of DSL. Never mind that TS is a superset of "actual JS," your point doesn't…

My point was you were very TS/JS-centric with a preference for frameworks that embed HTML and CSS in JS instead of the other way around. Try Htmx?

Why would I like HTMX if I already said I dislike HTML-like DSLs? I tried it, it has the same issues as Vue and Svelte DSLs. I don't want to turn HTML into its own programming language when I have a perfectly good one through JS/TS right there that I can use.

Re: Things I wish I knew before moving 50K lines of code to React Server Components

#479

Earlier quoted context omitted.

Thanks for sharing the Elixir love! More people should do this openly I think, since it’s still vastly underrated and fellow alchemists seem to be too humble to evangelize!

It's nice but if only it had types. After using languages like TypeScript and Rust, it's very hard to go back.

There are a small handful of statically typed languages on BEAM, gleam is the only one I've played around with but it's pretty neat

Re: Things I wish I knew before moving 50K lines of code to React Server Components

#480

Earlier quoted context omitted.

It's nice but if only it had types. After using languages like TypeScript and Rust, it's very hard to go back.

There are a small handful of statically typed languages on BEAM, gleam is the only one I've played around with but it's pretty neat

Yeah I've used Gleam but unfortunately using a language for production apps that is not well supported as Rust and even Elixir is is a dealbreaker for me. Gleam is fun to play around with though.
Post reply on HN