5 ms·

Web developers need to take a step back and realize that plain HTML/CSS can fulfill the needs of 90% of the basic text-on-a-page format of most websites out the

by acabal 5y ago

Web developers need to take a step back and realize that plain HTML/CSS can fulfill the needs of 90% of the basic text-on-a-page format of most websites out there, especially with the advances in CSS and form/input controls we've had in the past few years. When I was putting together the Standard Ebooks website[1], I wanted to take cues from the epub books we were producing: having a classic document-centric format without JS, based on traditional, accessible HTML elements, without frameworks, and with an emphasis on semantic structure without <div> soup. The result is a site that loads almost instantly, whose HTML transfer is small--12kb for the homepage and 24kb for the ebook grid--whose CSS transfer is 10kb, and whose JS transfer is 0. The bulk of the network transfer goes to the initial download of our self-hosted fonts, and cover images. Yet the site looks perfectly modern and even has effects like grids, form effects, transparency, responsive layout, and dark mode. It's hosted on an inexpensive DO droplet and has survived multiple HN hugs without breaking a sweat. If you're making a website, chances are high that you're just making a document that maybe is a CRUD app. Plain HTML was designed with documents in mind, HTTP/REST was designed with document display and CRUD in mind, and CSS is advanced enough where we can make it all look really nice. Go back to the basics! [1] https://standardebooks.org https://standardebooks.org

Enginerrrd 5y ago
Just checked it out, this really is a lovely site you've built. Side benefits include way better accessibility, zoom isn't broken!, and I can browse with javascript turned off with no problems. My only complaint on usability is an inability to select intermediate pages down at the bottom on the "ebooks" page. My options are basically just 1st, current and last page. I can see some downsides to that, but the filter functionality works well.
he_is_legend 5y ago
The problem isn't necessarily web developers, or certainly not all web developers. Thanks to constant penny pinching, very little gets developed from scratch in-house anymore - instead everything is put together using a myriad of third party code (often cheap third party code) that does things in very opinionated ways, meaning all of their dependencies become your dependencies, and every time you add another third party lib you get more dependencies. So you end up with a gigantic base of dependencies - none of which can easily be eliminated because its just a giant house of cards. The alternative is every shop building their own functionality from scratch, with the result being 100s of competing libraries all doing very similar things but slightly different. What needs to happen is the same as in most industries - end users / customers needs to realise the real cost of things and pay that full price. No more cheapest possible solutions. No more making do with lowest common denominators. Pay more money for better solutions.
- acabal 5y ago
  The point is that front-end libraries are not as critical as most of today's web developers think they are. Sure, you can use a well-known templating library on the back end to assist in constructing HTML before you output it. But once the HTML is in the browser, 90% of it is page-based documents with some CRUD sprinkled on top. Front-end libraries are rarely required given modern HTML/CSS and modern back-end languages like PHP/RoR/Python or even JS, and it's front-end libraries that are the causing the bloat. There's no need to develop from scratch: Use third party libraries on the back end to output plain HTML/CSS on the front end.

by acabal 5y ago

Enginerrrd 5y ago

Just checked it out, this really is a lovely site you've built. Side benefits include way better accessibility, zoom isn't broken!, and I can browse with javascript turned off with no problems. My only complaint on usability is an inability to select intermediate pages down at the bottom on the "ebooks" page. My options are basically just 1st, current and last page. I can see some downsides to that, but the filter functionality works well.

he_is_legend 5y ago

The problem isn't necessarily web developers, or certainly not all web developers. Thanks to constant penny pinching, very little gets developed from scratch in-house anymore - instead everything is put together using a myriad of third party code (often cheap third party code) that does things in very opinionated ways, meaning all of their dependencies become your dependencies, and every time you add another third party lib you get more dependencies. So you end up with a gigantic base of dependencies - none of which can easily be eliminated because its just a giant house of cards. The alternative is every shop building their own functionality from scratch, with the result being 100s of competing libraries all doing very similar things but slightly different. What needs to happen is the same as in most industries - end users / customers needs to realise the real cost of things and pay that full price. No more cheapest possible solutions. No more making do with lowest common denominators. Pay more money for better solutions.

acabal 5y ago
The point is that front-end libraries are not as critical as most of today's web developers think they are. Sure, you can use a well-known templating library on the back end to assist in constructing HTML before you output it. But once the HTML is in the browser, 90% of it is page-based documents with some CRUD sprinkled on top. Front-end libraries are rarely required given modern HTML/CSS and modern back-end languages like PHP/RoR/Python or even JS, and it's front-end libraries that are the causing the bloat. There's no need to develop from scratch: Use third party libraries on the back end to output plain HTML/CSS on the front end.