Call me old-fashioned, but when I look at the source code of a web page designed using the "modern" frameworks, it looks like a horrible mess of JS/CSS with very little actual content. E.g. take a look at this guy's code snippet's HTML source in the middle of the page - it's just a wall of <div>s and <span>s, for every single visible character.
The search engines these days cannot even function without a JS interpreter, something that surely increases the complexity and cost of building one.
Long gone are the days when one cared about semantic elegance of HTML code, per-site optimized CSS stored in an external file for easy caching, only occassional use of JS for easier navigation...
Nowadays you don't build websites, you have to build "apps". It's one of many signs of the "appification" of Internet.
I generally agree that the web could be simpler. A lot can be accomplished with just plain ol' HTML/CSS nowadays. I think there's a kernel of truth in what you're saying about apps vs. websites.
That said, how would you propose to do syntax highlighting instead of
> just a wall of <div>s and <span>s, for every single visible character
? Rather than being a wall, it looks to me like it's actually a tree of <divs> and <span>s for every line and every _token_.
I think the author has used Prism[1], so I assume the highlighting was done client-side, but even if you were to do the task server-side I think you'd end up with similar HTML/CSS, no?
What would be a better approach to solving the same problem?
Gatsby doesn't offer a syntax highlighter out of the box. It has markdown (and MDX) components that generate pages, and those in turn can have syntax highlighting plugins. AFAICT prismjs indeed is the predominant one used by Gatsby sites (at least, in mine). But thanks to SSR prismjs will typically run at compile time.
Of course you'd use spans to do syntax highlighting, just like you'd use JavaScript to do interactivity. You know what the commenter means–using these in places where they aren't necessary at all.
The commenter specifically used that tree of spans as an example of the horrible mess that is modern HTML. So it is necessary here to deliver the feature, and I think the broader point is that we might see a mess in the DOM inspector, but it is a requirement to deliver certain modern features in a productive way.
Like normal text on a page? No. For one very specific thing that it's useful for? Of course. If it wasn't useful for something it wouldn't exist, the issue is using it for things that it has no reason to be used for.
The code snippet seems like the only part where individual words are wrapped in their own divs or spans. It's not true that the whole article is like that. It seems like the article has reasonably semantic html elements present, just with minified CSS classnames and maybe a couple extra wrapping divs at the top.
I'm not the one who called out this site, and this one "OK" with its semantic HTML for the article content (though outside of that it has a bit more soup than it probably needs). It does render a bunch of stuff with JavaScript though so that's not great :(
So what? Web pages can do more than they used to. Engineers of yore similarly decried the ugly machine code generated by compilers. The HTML and CSS our browsers download are targeted at browsers, not humans.
If someone writes a buggy, inefficient C program, we fix the bugs, we don't abandon C and rewrite everything in assembly because the resulting machine code is prettier.
> If someone writes a buggy, inefficient C program, we fix the bugs, we don't abandon C and rewrite everything in assembly because the resulting machine code is prettier.
Several languages have popped up to address buggy, inefficient C programs and the problems they cause.
It works great with Lynx (text-based browser in the terminal), which indicates it's at least usable by screen readers. Bonus points for not making me scroll past a horribly formatted list of links at the top of the page. I see your point, but at least give the credit for the tooling that generates an accessible text-based experience for those who prefer it. I'd rather have a few good tools that generate something reasonable and consistent than a wild west of everybody hand-baking their own personally flawed interpretation of the standard.
I have to agree. If you try to visit the site in the OP without JavaScript enabled, it doesn't even render correctly. There's little reason for a static blog to be written as a client-side web app.
I visited the page with NoScript turned on and it looked the same. All the HTML is sent fully rendered by the server, so there shouldn't be any reason to expect that JS would be necessary to show the page.
I recently required from the IT team a HTML page intended to be readable on everything. It is a simple instruction with 3 headers.
They came up with an app, full of JS. Don't get me wrong, I write apps for my own use (quasar / vue) so I like frameworks, but I wanted a simple plain page.
Since they wanted to use a framework, I asked them to use https://motherfuckingwebsite.com/ as the template and after some initial gasps of horror we had a working web page.
There are many people using static site generators like Hugo to output clean HTML like you describe. I find Hugo’s approach to static sites produces much cleaner/smaller HTML than Next.js or Gatsby because you’re in the mindset of thinking about the direct output of the templating language as opposed to JSX syntax which abstracts away the raw HTML.
It’s perfect for personal sites, landing pages, documentation, etc.
Nothing about Gatsby or React by itself gets you non-validating HTML. The article has some W3C validation errors, but they seem to be caused by a few CSS errors they made themselves, the choice by their chosen CSS framework to put <style> tags for components directly in the page body next to their component elements, and their chosen code highlighter's choice to use <div> tags inside of <pre> tags. I find it surprising those two tools do that, though I wouldn't describe those issues as having anything to do with the rest of the ecosystem. (I have a Gatsby site using the component CSS library Styled-JSX and the code highlighter PrismJS which don't have those issues, and the site only has a few validation warnings that are purely from my own html. Apparently <section> tags are expected to have headers.)
microsoft.com, apple.com, a number of large "IT" companies have websites that throw W3C validator errors. I wonder whether there's a few that are completely valid..?
This. The elegance valued by so many in discussions seems so redundant when you think of how 99% of the machines that consumes the code will fail to appreciate it. The machine couldn't care less whether your actual header was a header tag or a div tag, and to then optimize for the things the machine does care about can result in horribly ugly code. And the reader of the page sees none of the code.
> The search engines these days cannot even function without a JS interpreter
I wonder if at some point while building a JS interpreter in the early days of Google for search reasons, they realized that the interpreter they spent all the time on could be packaged into a new browser to compete with Internet Exploder.
Maybe instead it was all a conscious decision at the beginning.
The search engines these days cannot even function without a JS interpreter, something that surely increases the complexity and cost of building one.
Long gone are the days when one cared about semantic elegance of HTML code, per-site optimized CSS stored in an external file for easy caching, only occassional use of JS for easier navigation...
Nowadays you don't build websites, you have to build "apps". It's one of many signs of the "appification" of Internet.