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

231–240 of 540 posts

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

#231

Post by wruza »

ozim wrote: post #178
lelanthran wrote: post #143

Earlier quoted context omitted.

Well they don't look like they were created to manage complexity either, so exactly why are they used?

They were created to manage complexity of building web applications. So something more like Excel than something like dummy photos gallery. One still can simply drop html file and sprinkle it with jQuery.

Ironically, “Web Excel” doesn’t use any of them. And if you asked someone who can create Excel to implement it in a webpage, they wouldn’t probably even think about these frameworks seriously.

The real promise of these is web forms with a little interactivity. Anything more complex and you start to fight with it to drop back down to the level where it’s manageable.

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

#232

Post by Cthulhu_ »

DigitalSea wrote: post #207

I'm old enough to remember when servers rendered everything and you used CSS and Javascript to enhance the pages after they were rendered. The web is in such a dark and overengineered place. It's almost unbelievable. It's why my approach to building apps is server-rendered first and then enhanced after the fact.

You guys are using Javascript?

I jest; our first geocities page was just HTML with maybe a visitor counter, marquee and whatnot.

Our first PHP application / project in school actually didn't use JS yet, it used frames for a static menu and header and just straight form submission to get data to the back-end. Those were the days.

But when I did my first college level internship (1 year of internships is part of college education over here), it was Java back-end, JSX templates for the presentation part, and it was enriched with PrototypeJS for things like dialogs and an animated accordeon (back when animation was still "update the height of this element a couple times a second").

My first job involved using a lot of JS to still enhance a page; add to cart, image carousels, that kinda thing. jQuery era.

And my next job involved building a user interface for customer support staff to look into SAP or something like that, poorly built in BackboneJS.

The next assignment was once again using BackboneJS to rebuild the investment banking front-end for customers. That was - as with most applications I've built btw - a great use case for single-page applications (as they were called then). No SEO needed, fast enough to render purely front-end, API heavy (that was also the time when people realized you could build one API for both web and mobile), etc.

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

#233

Post by mickael-kerjean »

renegade-otter wrote: post #211
M4v3R wrote: post #132

Earlier quoted context omitted.

You literally just run: > npx create-next-app@latest Press Enter a few times for default settings and voila, you have a hello world app up and ready to run.

With 700 dependencies, 200MB, and a massive security surface.

that's still better than CRA, to make the point a few weeks ago at work, I counted > 800 dependencies and 6 high security vulnerabilities warnings. If facebook can't get their shit together, who can?

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

#234

Post by fidotron »

kxrm wrote: post #130
popcorncowboy wrote: post #104

Earlier quoted context omitted.

React is as baked in now as Java and Covid.

A little over 10 years ago we were saying this about jQuery. React definitely solves problems that jQuery just couldn't solve well. I know that there are issues in react we still need to address, so I know it will be a matter of time before some new way is developed that will supplant react and we will talk of react then as we talk of jQuery today.

And who has even heard of MooTools or the Yahoo User Interface library?

The JS ecosystem destroys the past like nothing else.

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

#235

Post by Cthulhu_ »

alib wrote: post #55

What I love about this is how PHP and JavaScript had basically the same syntax (minus a $ symbol here or a var keyword there), and then NodeJS was like, but we want to run JS on the server! And now, 15 years later JavaScript has finally caught up and it’s basically the same as PHP, but with more acronyms and a steeper learning curve (to be fair, streaming data from server to client components using suspense is cool).…

I never liked NodeJS; on the one side it was innovative in that its concurrency model allowed for faster back-ends, but a lot of the features of existing back-end languages like Java and PHP were still missing, so a lot of patterns were re-invented, the language itself needed years to get to the 'safety' levels that Java already had and PHP was working towards, and proven and standardized technology like XML and the contractual guarantees it could give were discarded because it was heavy and JSON was better because it was human-read/writeable or something like that.

I feel like we lost a lot of time and effort by ditching XML. I mean documenting a REST/JSON API is still painful. While 20, 25 years ago you could already generate your data models and a parser for your XML payload. I still don't know what was wrong with XML. Yeah it was a bit heavier on the line than JSON, but that's a fixable problem - using compression, or use EXI (https://www.w3.org/TR/exi/) to turn it into a binary protocol. I don't know if EXI ever became a thing, but at the time I was quite exited about it knowing how much XML was passed around.

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

#236

Post by Cthulhu_ »

Illotus wrote: post #31

I guess you use what you are familiar with, but using react for doc site instead of using some off the shelf static site generator/cms with caching seems like wasted effort. More fun from dev point of view with react no doubt.

> More fun from dev point of view

This is the curse of software developers and employers everywhere tbh.

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

#237

Post by Scarblac »

ljm wrote: post #119
marban wrote: post #99

Earlier quoted context omitted.

To cap it all off, I'll add some dynamism with cgi-bin magic.

Why use kubernetes and the cloud when you can FTP or rsync your code onto a box? Simpler times.

I just ssh to the server and edit the code there, I never understood why people need to have two whole environments that they keep in sync.

(though seriously, in my dorm room in the 90s, my pentium 90 desktop at the end of my bed had a fixed IP address and was the server...)

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

#238

Post by sodapopcan »

psd1 wrote: post #10
CipherThrowaway wrote: post #4

Earlier quoted context omitted.

It seems most of the content is dynamically rendered (at build time with SSG). What alternative did you have in mind?

I'd rather use Blazor, or Jinja. But I hate react, js, and front end work, so maybe I'm not the target audience. I clicked the link out of morbid horror.

I use Phoenix LiveView and I’m really big on frontend. I also do a lot of backend, though, so I’m one of those “full stack” generalists that no one likes anymore.

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

#239

Post by Cthulhu_ »

skippyboxedhero wrote: post #162
Illotus wrote: post #31

I guess you use what you are familiar with, but using react for doc site instead of using some off the shelf static site generator/cms with caching seems like wasted effort. More fun from dev point of view with react no doubt.

It is statically generated. The reason to use React is so you have one language across the front-end rather than having some people using React on one site, and then people using Gatsby/Hugo for something else. Next.JS can do the same thing as Gatsby/Hugo but has more features and is in React.

But you don't even need to know what language your tool is written in if all you want is a static documentation site.

This is a problem a lot of people have; they think in technology instead of actual problem solving. Just look at how many projects have been posted on here with a title like "$solved_problem... in Rust!" as if Rust makes everything better forever.

It's marketing bullshit. It's self-gratification. It's using a technology for technology's sake, not for solving a problem. And it's costing the industry billions in sunk cost, dead ends, overcomplicated and unmaintainable software. Because one guy felt strongly about a language or technology.

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

#240

Post by wruza »

CipherThrowaway wrote: post #145
holoduke wrote: post #125

I think i am getting old. These frameworks are so big and complex. For a simple web hello world you need a huge build and compile pipeline. And now its extended with serverside components. I really wonder what the overhead is. How many of layers of frontend and backend framework code is executed to get the hello world example running. I retreat back to my simple 10kb component framework in which i need only f5 to reb…

F5ing to refresh is a heavier workflow than the hot-reload/refresh you get with every modern web framework.

First, HMR doesn’t magically put you into a specific program state. Second, you can still HMR any website, as it is a feature of a bundler, not a web framework.
Post reply on HN