Taking the survey myself definitely showed me my own HTML skills are rusty as a consequence of building JavaScript apps for the last decade.
The truth is that building web apps is a large and complex enough field that it's quite hard for a single person to master all of it, and I think we should normalize the fact that any single developer will have their areas of strength and weakness.
I'm one of the developers of the survey app. While I would love to have the app work seamlessly without JavaScript, the reality is that when you build apps with a React/Next.js stack the path of least resistance does usually take you in a direction that requires JS to work.
Personally I don't see it as a good or bad thing, it's just one way of building web apps, and it so happens it's the one I know how to do.
It's not a theory, it's literally how free speech works in the real world. Private entities can't be compelled by the government to to publish content they don't want to publish, just like they also can't be silenced by that government.
What you seem to be asking for is a world where the government can override the autonomy of publications and force them to publish specific items. How is that "free" speech?
Lead survey maintainer here; we are aware of the problem and are working on a new data visualization that will use historical data to highlight how bad the graphs are getting year over year, so we can really narrow down the issue.
I'm the lead survey maintainer; I agree that the survey is very front-end oriented, but that's because it was hard to properly cover everything, and we're instead hoping to do a separate "State of Node" (well, or a similar name that also includes Deno, Bun, etc.) survey at some point.
Unless you’re talking about SSG and not SSR, I think one potential issue would be that React’s SSR process is pretty slow and costly, at least from what I understand. I have to confess I haven’t heard of a pure-SSR React app before, as you wouldn’t get many of React’s benefits if it’s just being used as a templating language.
I’ve heard great things about Google Domains but this kind of story is exactly why I probably won’t be using that service. It’s just too risky if you lose everything at once.
I ran into the same situation multiple time and was never able to find a solution besides throwing more money at servers. That might be due to my own lack of knowledge about running servers and performance optimization as I was (and still am) a front-end person first and foremost.
That's very kind of you to say! Personally I would love to read something on this topic by members of the original Meteor team. Although I was a "fixture" in the community, I was also an outsider compared to actual MDG staff, so my understanding of the actual situation on the ground was always a bit one-sided…
> That is the "rehydration", taking a React app that you wrote and the server buildchain "dehydrated" (baked into HTML + CSS), but then rehydrating it to add interactivity back. Yes, you could do all that manually, but Next.js makes it magically trivial... you never have to think about it, it just works. And it's lightning fast.
Actually I think the big trend in JS front-end development is realizing that you do have to think about it! React rehydration is often a very slow step (whether it's Next.js or anything else, I don't think it makes a difference), definitely not "lightning fast" on non-trivial apps with lots of data. Islands architecture goes a long way towards solving that but it's still a bit limited today.
React by itself is quite simple, but precisely because it's so simple a lot of third-party libraries have cropped up to fill out the gaps. I'm not sure if other ecosystems are really simpler, or if the complexity is just spread out differently… At least with React you have the option of not buying into Redux/GraphQL/etc. if you don't want to.