Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

mux.com

Post reply on HN
Print view View original

501–510 of 540 posts

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

#501

Post by satvikpendem »

solardev wrote: post #498
satvikpendem wrote: post #496

Earlier quoted context omitted.

Try this link: https://docs.google.com/document/d/1peUSMsvFGvqD5yKh3GprskLC... Yes he says to use a language that compiles to WASM for the UI parts to draw pixels on the screen.

Isn't this a redo of Flash and ActiveX, then?

Yep, and it's pretty nice. However, he talks about important things that weren't in Flash, like accessibility, and how to handle them cleanly.

It really seems like WASM will be the write once run everywhere runtime that was touted in the past. Java almost got us there but was too dependent on Java, whereas WASM is for any language. I've been using Flutter with their experimental web WASM support and it's very fast.

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

#502

Post by solardev »

satvikpendem wrote: post #501
solardev wrote: post #498

Earlier quoted context omitted.

Isn't this a redo of Flash and ActiveX, then?

Yep, and it's pretty nice. However, he talks about important things that weren't in Flash, like accessibility, and how to handle them cleanly. It really seems like WASM will be the write once run everywhere runtime that was touted in the past. Java almost got us there but was too dependent on Java, whereas WASM is for any language. I've been using Flutter with their experimental web WASM support and it's very fast.

I think this makes sense for complex apps like games, CAD and design software, etc.

I hope it doesn't replace the lowest common denominator of HTML for generic apps, though, if only because it would dramatically raise the barrier to entry (not that your typical React app is particularly readable in the inspector...).

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

#503

Post by satvikpendem »

solardev wrote: post #502
satvikpendem wrote: post #501

Earlier quoted context omitted.

Yep, and it's pretty nice. However, he talks about important things that weren't in Flash, like accessibility, and how to handle them cleanly. It really seems like WASM will be the write once run everywhere runtime that was touted in the past. Java almost got us there but was too dependent on Java, whereas WASM is for any language. I've been using Flutter with their experimental web WASM support and it's very fast.

I think this makes sense for complex apps like games, CAD and design software, etc. I hope it doesn't replace the lowest common denominator of HTML for generic apps, though, if only because it would dramatically raise the barrier to entry (not that your typical React app is particularly readable in the inspector...).

Yeah Figma is in WASM and it's great that it is. I don't see it coming for React apps, really. Or if it is, that the JS tooling itself will automatically convert it to WASM.

I personally use Flutter for a lot of my apps, as well as React/NextJS for SEO based apps, the combo works pretty well.

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

#504

Post by solardev »

satvikpendem wrote: post #503
solardev wrote: post #502

Earlier quoted context omitted.

I think this makes sense for complex apps like games, CAD and design software, etc. I hope it doesn't replace the lowest common denominator of HTML for generic apps, though, if only because it would dramatically raise the barrier to entry (not that your typical React app is particularly readable in the inspector...).

Yeah Figma is in WASM and it's great that it is. I don't see it coming for React apps, really. Or if it is, that the JS tooling itself will automatically convert it to WASM. I personally use Flutter for a lot of my apps, as well as React/NextJS for SEO based apps, the combo works pretty well.

Yeah, Figma's tech is incredible! Especially when I use side by side with Microsoft Teams, lol. One's a complex layered drawing app with plug-ins and imports and the other is a glorified chat app... guess which one is 10x slower and crashes every half an hour?

Whelps. Time to learn C++ again!

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

#505

Post by satvikpendem »

solardev wrote: post #504
satvikpendem wrote: post #503

Earlier quoted context omitted.

Yeah Figma is in WASM and it's great that it is. I don't see it coming for React apps, really. Or if it is, that the JS tooling itself will automatically convert it to WASM. I personally use Flutter for a lot of my apps, as well as React/NextJS for SEO based apps, the combo works pretty well.

Yeah, Figma's tech is incredible! Especially when I use side by side with Microsoft Teams, lol. One's a complex layered drawing app with plug-ins and imports and the other is a glorified chat app... guess which one is 10x slower and crashes every half an hour? Whelps. Time to learn C++ again!

Might I suggest...Rust? It really is a great language and it has excellent WASM support due to not being GCed, just like C++.

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

#506

Post by solardev »

satvikpendem wrote: post #505
solardev wrote: post #504

Earlier quoted context omitted.

Yeah, Figma's tech is incredible! Especially when I use side by side with Microsoft Teams, lol. One's a complex layered drawing app with plug-ins and imports and the other is a glorified chat app... guess which one is 10x slower and crashes every half an hour? Whelps. Time to learn C++ again!

Might I suggest...Rust? It really is a great language and it has excellent WASM support due to not being GCed, just like C++.

Good idea. Sounds fun, actually!

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

#507

Post by BeefyMcGhee »

datavirtue wrote: post #280
sodapopcan wrote: post #249

Earlier quoted context omitted.

My brother just started learning web development this past year and his mind was blown when I told him you could send HTml over HTtp.

Please help the guy before he gets too far along. Some of us might have to work with him. Seriously though, I saw someone described as a 22 yr old software engineer in an article. There is a better term: "Software Engineering Apprentice"

While we're gatekeeping, how about "Software Developer Apprentice"? This stuff isn't technically engineering.

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

#508

Post by laputan_machine »

satvikpendem wrote: post #500
laputan_machine wrote: post #486

Earlier quoted context omitted.

As you get more experienced in programming you'll inevitably inherit projects that you didn't have any say over, when that time comes come back to this comment, I'd be interested to hear if you still feel the same way.

I have inherited such projects. But it seems like you're talking about code that is no more complex than hello world, as you've quoted, so it wouldn't be too complex to do in any language or framework. Now if you do inherit a larger project that you don't like, well, you either work on it or you switch jobs.

> Now if you do inherit a larger project that you don't like, well, you either work on it or you switch jobs.

Which you wouldn't have to contemplate if your predescessor had simply used the right tool for the right job, right? Such as not using an over-engineered framework for a problem that didn't need to use one. :)

Cheers!

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

#509

Post by satvikpendem »

laputan_machine wrote: post #508
satvikpendem wrote: post #500

Earlier quoted context omitted.

I have inherited such projects. But it seems like you're talking about code that is no more complex than hello world, as you've quoted, so it wouldn't be too complex to do in any language or framework. Now if you do inherit a larger project that you don't like, well, you either work on it or you switch jobs.

> Now if you do inherit a larger project that you don't like, well, you either work on it or you switch jobs. Which you wouldn't have to contemplate if your predescessor had simply used the right tool for the right job, right? Such as not using an over-engineered framework for a problem that didn't need to use one. :) Cheers!

I mean sure, but I wouldn't work at such places anyway. One cannot escape complexity, it's either in your code or in other people's code that you use. Don't overengineer, but not everything you'd think is overengineering is actually the case. Otherwise, just work in assembly.

It is also interesting that you haven't responded to the other comments that call out flaws in your argument, just mine, perhaps because you don't have an answer for them either, as your original comment is now dead.

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

#510

Post by XCSme »

regularfry wrote: post #483
XCSme wrote: post #379

Earlier quoted context omitted.

But... a round trip is usually faster than serving 2MB of JavaScript.

It is, but that's not the comparison. The question is how well you can react to a user action if you need a network round trip in the middle. The user's already got the 2MB of JS loaded in their browser. My stance is usually that as long as you can get a response to the user (which can be a DOM fragment, a JS snippet, whatever, doesn't matter) within 200ms, you don't need client-side rendering. And if you haven't yet…

> The question is how well you can react to a user action if you need a network round trip in the middle

I do think this is the question, but the solution is not an SPA, but instant interaction feedback and no content jumping around. If you solve that, a 1-2s response from the server will seem instant, whereas with a bad implementation, you can have everything on the client-side and make that 0ms interaction look more sluggish than the one that goes to the server.

Think of a chat application, if you send a message and press send, it doesn't matter the request takes two seconds, if:

* The message is immediately shown in the chatbox

* There is direct feedback on the status of the message (sent/received/read)

* You can continue interacting with the application while the message is being sent (non-blocking)

You don't have to send all the data/messages before (server-rendered), just some logic to what happens when an action is taken.

Post reply on HN