41–49 of 49 posts
In doing this, you break HTML semantic relationships. Each to-do is a child of the previous to-do. That hurts. I applaud the work in making something sans JS for the kicks of it, but if your going to do it, at least don't break HTML.
The semantic Web is, unfortunately, quite dead. Hopefully a JavaScript-free Web can still happen.
Earlier quoted context omitted.
The semantic Web is, unfortunately, quite dead. Hopefully a JavaScript-free Web can still happen.
"Hopefully a JavaScript-free Web can still happen." The phone you're reading this post on has nearly as many CPU cycles available to run code as the web server that generated the html. Why on earth would you not want to distribute the overall application load.
2. The web server has much more efficient languages available meaning that it's probably far fewer total CPU cycles than rendering on the client.
3. The web server can also cache the results and only render it once for a thousand users, can't do that with client side rendering, so your using far more CPU cycles there.
4. The server knows when the content changes, it can even render the page ahead of time, the client can't.
Earlier quoted context omitted.
Right, but I find these demos interesting nonetheless - in that they reveal capabilities of HTML + CSS that, as a casual frontend developer, you wouldn't normally think of them as having.
I think this is the best way to look at projects like these. It's not an exercise in efficiency, or even attempting to prove that HTML + CSS is somehow better than a JS version. I think it's about getting as much as you can out of CSS and HTML. As a viewer, looking at these projects usually give me 2-3 tricks to add to my collection and is worth the read. I honestly don't think I'll ever NEED to implement a CSS+HTML…
Earlier quoted context omitted.
The semantic Web is, unfortunately, quite dead. Hopefully a JavaScript-free Web can still happen.
"Hopefully a JavaScript-free Web can still happen." The phone you're reading this post on has nearly as many CPU cycles available to run code as the web server that generated the html. Why on earth would you not want to distribute the overall application load.
I also think this is something Web people overlook. Our phones are _insanely_ powerful, yet almost all Web sites are slow-loading garbage: because of JavaScript.
Earlier quoted context omitted.
> Why on earth would you not want to distribute the overall application load. Maybe because I want my phone battery to last a long time, but I don't care how much electricity the web server uses. Maybe also because the JavaScript is probably proprietary software [0], which I don't want to run on my computer. [0] https://www.gnu.org/philosophy/javascript-trap.html
FWIW, the HTML + CSS approach of the author is just as copyrightable and potentially non-free as the JS in question. There's really no difference. Sure his 'code' is practically pointless, but that's no obstacle to being non-free. Uglified/minified HTML+CSS is almost as difficult to parse by humans as JS. I'm all for free software and very supportive of the arguments, but the pro-HTML, anti-JS rhetoric never made a l…
Earlier quoted context omitted.
I don't think he needs to acknowledge how contrived his solution might be or provide a real-world use case. The article very well could be taken as inspiration to approach problems from different angles.
Indeed. It's clearly not meant to be a realistic or recommended approach. It's a practice of lateral thinking, an experiment to see how much of a problem you can solve with limited set of tools. It's easy to throw in every library, framework, technology at a problem, and they might not be necessary. Sometimes approaching a problem from this unusual perspective can yield good solutions. Often times, it's messy and hac…