The responsiveness of bootstrap's grid is something that css doesn't have. With a few classes I can make the same site for mobile and ultra wide screen.
You'd do it with media queries and make different grids for different screen sizes. If anything it's more flexible than bootstrap because you can change element order as well.
Bootstrap grid system is super complete, and probably better coded that anything I can make. Its also available as a standalone module, so the size is pretty small. I just wanted it integrated to PicoCSS because I'm lazy.
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.
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.
Agreed. I think the two of us can talk all day about the necessity of it becoming a “large and complex field”. I accept I am an old miser about it, but it is indeed the reality.
I only got part-way through the survey before moving on, but based on what I did see of it, it doesn't look like an alternative HTML-only/non-JavaScript version should be that hard to put together at all for future surveys.
Just do it on a single page, in one big form that's submitted at the end. Don't even bother with styling it.
If a version like that were available, I probably would've completed the survey because I could have more easily judged how long it would take to finish it.
I would recommend 2D semantic HTML documents (using a table), and no, HTML tables are not harmful (https://webaim.org/techniques/tables/ with a real life example https://iroiro.neocities.org/ ). People with visual impairment can still navigate easily (see webaim page above) with screen readers.
How do you detect which version to serve in this case? Using User-agent server-side, or something else client-side? Or maybe letting the user decide using a separate website?
It's a bit ironic to host the state of html survey in an environment that absolutely requires JavaScript. It is also a pretty bad thing since progressive enhancement is a key principle of the web.
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?
No, that's not how it works in the real world. that's how it works in your low-fidelity perception of the real world. You've never much bothered to check if your model matches the observations you might make.
Look at the statement "private entities can't be compelled by the government". Which government are we even talking about here? It's quite clear that many governments do actually compel such things when it suits them. Have you never noticed?
You might switch to making the argument that "private governments shouldn't x", and I suppose if you were clever they might even be good arguments. You might also make the argument that this government or that government doesn't currently do it... but that boils down to "I want it to continue not compelling x". Hardly an argument, except maybe for the status quo.
You don't know what I'm asking for. It's an idea far enough outside your narrow cone of comprehension and even narrower cone of imagination that we might as well not even be speaking the same language.
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.
I get what you are trying to explain but this analogy is completely wrong. It would mean that the two subjects are complementary and are often used together which is clearly not the case.
While a JavaScript framework like React can be used to build a company website or CMS, it is often not a good idea to use React to do this.
Off course this is highly context specific and depends on the particular requirements of the "company website". Without a strict definition of what it is, it will be always a discussion about an ambiguous and moving target.
The choice also depends on the technical knowledge and experience. For someone with years of experience with Javascript and really an expert on it, it might be still a smart choice. Or maybe we are not talking about 1 developer but a team of 10 developers etc.
I was just trying to suggest that this is not often the case.
> The author is seriously suggesting Next.js to build a company website.
Hi, I'm the author :). I wanted to highlight this recommendation has the modifier "If you'd like to learn something new". This very subjective recommendation is solely based on the exciting mix of rendering options, the vast popularity, and my preference for JS and React.
You're spot-on when you emphasize that there are web applications that are a different beast anyway and websites that run perfectly fine with a CMS in the background.
That's exactly the point I see...? To build a website (as opposed to a web application) with mostly static content and maybe some interactive embedded content, do not use N*xt.js. Use a CMS or static site generator or whatever instead. Without any fancy client-side URL routing and whatnot. Just let the browser do its thing.
That being said, some frameworks support a SSR-only approach or even static site generation. That's also fine IMHO. Just use what you like! If you like Ruby on Rails, why not? Angular SSR? Gotcha.
I tried multiple tools like Jekyll and Hugo but found them terribly clunky. Then I found Astro and now I'm happy. Reasonably similar to SPA frameworks, but generates a static site.
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.
It's really no more costly than Django/PHP/Ruby mustache-style template rendering. I consistently see 100-150ms last byte timings from a Next.js app I host on Vercel.
