Hacker News Reader

Comment by tlug | Hacker News Reader

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.

View on HN

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?

[1]: https://prismjs.com/

From the WhatCMS, author uses Gatsby, assume no trace of Prismjs is used.

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.

Hey, OP/author here, I do use prismJS under the hood, a flavor of it: prism-react-renderer, so it might indeed remove the traces of Prism.

Agree that it's a mess of div and spans, but it does the job.

> how would you propose to do syntax highlighting

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 :(

> E.g. take a look at this guy's code snippet's HTML source in the middle of the page

well, on the other hand manually crafting the syntax-highlighted block of code isn't a lot of fun either

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.

That’s not the point.

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.

Not sure what your seeing, but it renders fine for me in links2.

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.

https://motherfuckingwebsite.com/ works best with http://vanilla-js.com/

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.

+1 I'm still getting a bad night's sleep when the W3C validator doesn't give me the green light at the end of the day.

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.)

100% W3C has ZERO effect on SEO you are wasting time and effort

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.

Search engines navigating JS websites is a hoax. It never worked and never will. For SEO using JS for crucial parts is a death sentence

> Search engines navigating JS websites is a hoax

Google has parsed JS-generated content from businesses I work at and made it searchable within their index. That's a hoax?

there is still opportunity to do good web dev these days, but the choice is up to you.

> Long gone are the days when one cared about semantic elegance of HTML code

Why would I care about semantic HTML? HTML is at large generated for me, and is an implementation detail. I don't want to read nor "craft" HTML.

> per-site optimized CSS stored in an external file for easy caching

Is this not the standard nowadays, getting CSS files from a cache typically on a proxy like cloudflare?

> Is this not the standard nowadays

The AMP spec mandates the exact opposite, for whatever that's worth as a "standard."

Reply on news.ycombinator.com