Earlier quoted context omitted.
Now add 5 people doing that at the same time and report back on how scaleable that solution is.
You need Kubernetes for a product which has a 5 people team?
Resume/CV won't pad by itself
Things I wish I knew before moving 50K lines of code to React Server Components
391–400 of 540 posts
Re: Things I wish I knew before moving 50K lines of code to React Server Components
#392Damn I really don't want to make the frontend even more complicated than it already is.
Re: Things I wish I knew before moving 50K lines of code to React Server Components
#393I am pretty sure 99% of the development time is no longer spent on solving problems and implementing features, but on creating unnecessary complex systems, deploying and maintaining them in an auto-scalable cloud, when a single $5 VPS would be performant enough, if all that complexity wasn't there. We should spend more time in writing efficient, simple code with fewer dependencies. We get so much natively nowadays th…
I blame the devops industrial complex. When cloud providers came online and especially when "devops" became a thing then developers became the marketing target. Social media, the whole influencer concept, and all those manipulation tactics were turned loose on software developers. Look at the breadth and depth of services and tools on the market to produce a web application.
Another thing, this isn't the first instance of the pendulum swinging back. Providing what would normally be desktop apps through a browser reminds me of dumb terminals attached to an AS400.
Re: Things I wish I knew before moving 50K lines of code to React Server Components
#394Earlier quoted context omitted.
You can generate a swagger-ui doc page from an open api yaml spec by just mounting the file in their swaggerapi/swagger-ui docker container. Same with Redocly. Granted the pages probably wont look as good as what they have here or be integrated in their larger docs, but yea its possible.
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 example where they could write their own docs generator with MUCH less complexity. You read a damn json/yaml file and make HTML out of it. Style it with CSS and you're finished. It's as maintainable as it gets.
Now let's look at running `yarn install` in this project a year from now and see how easy it's going to be to maintain it.
Odds are NextJS will be 5 versions behind and with 500 vulnerabilities found in the dependency graph.
Re: Things I wish I knew before moving 50K lines of code to React Server Components
#395I can comment on personal experience with this. I've been building a new application using next.js and its new `app` directory setup. First, it is hard to reason about what is happening where (server or client). If you want to know then you have to investigate and most of the time when I'm cranking out code I don't pay too much attention. As he mentions, it is really easy to make a small change and then all of a sudd…
> many existing React libraries are assumed to run on client because they use hooks
Do you mean context instead of hooks here? Plenty of hooks work on the server side, in that they do nothing other than initialize some values.
Re: Things I wish I knew before moving 50K lines of code to React Server Components
#396Earlier quoted context omitted.
>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! So much this. It's like our industry has a rolling 10 year cycle of amnesia. We moved away from server rendered UI for very, very good reasons. Of course the SEO argument is alw…
Pure "content" sites don't need to be SPAs, but web "applications" suck ass rendered server side.
Citation needed.
99% of apps are basic CRUD apps. Aside from a few interactive pages - which you could even write with React - there's zero need for this bloat.
No, your "application" is not Google Docs, Spotify, etc. It's not a SPA.
Re: Things I wish I knew before moving 50K lines of code to React Server Components
#397Earlier quoted context omitted.
the only downside for me is that there aren't many mature UI libs for it yet. I was evaluating it for a Tauri-based project but I went with React instead because of this.
You guys can try https://bulma.io/ as a middle-ground. It provides some fundamentals styles that aren't married to JavaScript, so there are never any conflicts with any SPA version. It's not widely used, but it worked well for us before going to Material UI as the team grew and the designers wanted something everyone is familiar with.
Yeah, serves the same niche as PicoCSS for me. Always good to learn about alternatives, especially relatively non-disruptive changes like a CSS skin.
FWIW: Material UI for Svelte has been around for a while as well.
Re: Things I wish I knew before moving 50K lines of code to React Server Components
#398Word count: complex: 9 complicated: 2 I've tried Nextjs's app router, and server/client components, and there are more footguns and gotchas than you can shake a stick at. Maybe it'll get smoothed out over time, but right now it is downright HARD to keep the mental model of your app when server and client code is constantly being intermingled, imported, and exported back and forth to each other.
I'm advising a NextJS team now and acting as a liaison to a system they're integrating with. Even the devs in the NextJS code every day get confused about what's running on the server and what's running on the client and the consequences of both.
I can see the attractiveness to a setup like this. Back when I was much more involved in actually typing out code it was always a pain to switch mentally from backend side coding to front-end side coding. On the other hand, it made it easier to reason about security. Front-end was the wild west and on the backend you didn't trust anything coming in.
Another thing, i understand the supposed advantage of having one language for both backend and frontend but i don't recall that ever being a real issue with me or the teams i worked with. Everyone seemed able to shift from Javascript (and associated Javascript frameworks) to the backend language ( Java and C# in my case) without any issues.
Re: Things I wish I knew before moving 50K lines of code to React Server Components
#399I can comment on personal experience with this. I've been building a new application using next.js and its new `app` directory setup. First, it is hard to reason about what is happening where (server or client). If you want to know then you have to investigate and most of the time when I'm cranking out code I don't pay too much attention. As he mentions, it is really easy to make a small change and then all of a sudd…
> many existing React libraries are assumed to run on client because they use hooks Do you mean context instead of hooks here? Plenty of hooks work on the server side, in that they do nothing other than initialize some values.
I might be loose with my terminology, but hooks as standard as `useState` or `useRef` will trigger errors like:
You're importing a component that needs useState. It only works in a Client Component but none of its parents are marked with "use client", so they're Server Components by default.
Another thing that hits me is when I have a server component that is marked as `async` and then for some reason it ends up on the client and I get the error that says something like "We don't support async components on the client yet ..." and I have to spend some time looking at my display hierarchy trying to figure out what is causing a client to import it.
It reminds me of the "colored functions" blog post about async/await. You end up with colored components in your app which otherwise look and act the same. But now you have to be careful how you compose them together.
Re: Things I wish I knew before moving 50K lines of code to React Server Components
#400Earlier quoted context omitted.
You guys can try https://bulma.io/ as a middle-ground. It provides some fundamentals styles that aren't married to JavaScript, so there are never any conflicts with any SPA version. It's not widely used, but it worked well for us before going to Material UI as the team grew and the designers wanted something everyone is familiar with.
Yeah, serves the same niche as PicoCSS for me. Always good to learn about alternatives, especially relatively non-disruptive changes like a CSS skin. FWIW: Material UI for Svelte has been around for a while as well. https://sveltematerialui.com/
Seems like a bunch of minor things, but learned a lot from you today, appreciate it.