Earlier quoted context omitted.
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.
Things I wish I knew before moving 50K lines of code to React Server Components
351–360 of 540 posts
Re: Things I wish I knew before moving 50K lines of code to React Server Components
#352Earlier quoted context omitted.
Well, I've yet to see any web project of that scale survive more than 2 years. What do you think would be a better stack with similar frontend interactivity? (Genuine question, not being snarky)
I have seen Angular projects last pretty long avoiding code entropy. Angular is opinionated, rigid, and verbose, but goddamn if that structure and predictability don't pay off in the long term.
I haven't tried modern Angular in a while. But Next.js reminds me of a lot of the things I loved about early Angular and disliked about raw React (which always was more of a UI lib than a proper framework). Have you tried comparing them in particular?
Re: Things I wish I knew before moving 50K lines of code to React Server Components
#353Earlier quoted context omitted.
Just because it’s a one liner to install something doesn’t mean you aren’t installing a big, complex, over-engineered thing.
Look at your computer. Are all its parts and pieces strictly necessary to display the text "Hello world" on your screen? No. Why don't you throw it away and buy something simpler, then?
Re: Things I wish I knew before moving 50K lines of code to React Server Components
#354I'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.
Re: Things I wish I knew before moving 50K lines of code to React Server Components
#355I 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.
Re: Things I wish I knew before moving 50K lines of code to React Server Components
#356Earlier quoted context omitted.
- npx create-next-app@latest - npx: command not found - install node / npx - npx create-next-app@latest - realise your node is too old - install nvm / node - npx create-next-app@latest - answer a bunch of questions - npm start - get an error: Error: ENOENT: no such file or directory, open '/tmp/my-app/.next/BUILD_ID' - npm run dev - hello world in browser
npm is biggest hurdle for me to learn nodejs. For me it has never worked in first attempt. On other hand Ruby on Rails bundler very rarely game me errors, and for every error provided hints what to do.
Re: Things I wish I knew before moving 50K lines of code to React Server Components
#357In server-side rendering, clients are sent HTML that they can see immediately I noticed this too. You can put a plaintext file on the server and it gets transferred to the browser pretty fast. You can also put another plaintext file ending with .css on the server and it can make things on the first page move and look really nice just because the browser knows what to do with it. It’s a neat trick but still second to…
I thought we had lost that technology.
Re: Things I wish I knew before moving 50K lines of code to React Server Components
#358What 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).…
In fairness, PHP prior to v7 was either a dumpster fire or a dirty bomb depending on how far back you go. When folks called it a fractal of bad design, it 100% deserved it, and folks rightly went looking elsewhere to solve their problems. PHP is a phenomenally better language today, and folks really should take another look, but let's not pretend it was always anywhere near as good as it is today. Not by a long shot.…
Re: Things I wish I knew before moving 50K lines of code to React Server Components
#359Rails/Django/Laravel/… + Turbolinks/Htmx/… or even sprinkle some light clientside JS for fancyness.
Or go best-of-all-worlds if you happen to know Elixir/Phoenix.
But don’t continue the descent into RSCs, now matter how many people tweet about it. These folks with less than 10y industry experience will run into all the basic problems we had in vanilla PHP sites years ago, I even spotted react components with inline-sql-hooks already. This time with much accidental complexity overhead!
Stay sane instead, ship actual products quickly, and earn that lambo!
Re: Things I wish I knew before moving 50K lines of code to React Server Components
#360That seems like a tremendous commitment for such a recent technology.