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 calculator sans JS, but it's nice to know that it's possible and it could be something I look at if I want to implement a piece of it for something similar.
Exactly, but it's an example as to similarly, it bugs me to no end when I see styled radio/checkboxes that rely on JS at all. I'm still wrapping my head around flexbox though... The naming conventions and rules are just weird and alien to me, and been at it for over a year now off and on.
These kinds of tricks are nice for progressive enhancement - you can have a navigation section in your server-side-rendered SPA that outputs a fully usable nav like this, and if a user has JS disabled, they'll still be able to navigate around your site, albeit with hard page reloads instead of more instant transitions. It's funny that people are using js frameworks to render js-free snippets that are then progressively enhanced with more js, but that's web development today.
The form stops working, deleting a todo also leaves it in use so you'll run out constantly, but it's like a pure css app bro - it's pretty sweet I think.
You could also make more than 50 in his js renderer file on github if you needed more
"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.
> 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.
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 lot of sense to me, consistency-wise, at least in these days of CSS3.
1. Because having the web server render html doesn't use appreciably more CPU cycles than encoding the raw data in json anyway.
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.
I am doing that by downloading, parsing, rendering and evaluating the HTML and CSS. I'm not giving you arbitrary code execution. Do you want to fold proteins too?
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.
These exercises will be a lot more fruitful to read through if the author can acknowledge the contrived nature of these attempts and provide a real-world advantageous use case of the techniques outlined
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 hacky, but in either case you learn a lot along the way.
Yes. Folks with an "enabling attitude" (as Martin Fowler puts it so well - https://martinfowler.com/bliki/SoftwareDevelopmentAttitude.h...) would probably tend to appreciate exploratory exercises that expand horizons or demonstrate new ways of using old tools, while folks with a "directing attitude" might tend to dislike them.
Using inputs and pure css imo is a superior method to deliver content tabs and other similar UI. Minimal markup for a fully functional non js bound interface
Yeah, that would be a pretty basic feature.
I get that he is just showing of some ´out-of-the-box' thinking. But really, it is not something practical.
In the end, he made a TODO-Layout, not a TODO-App. Interesting experiment I suppose, if you are into frontend stuff
A common misconception is that adding JS to HTML (e.g. in forms) _hurts_ accessibility. In fact, foregoing JS in favour of "pure" CSS+HTML can actually be much worse.
Yes, you can create certain interactions with CSS alone but doing so purely for the sake of not using JS is pointless and at worst harmful.
That's super cool! The `:checked` and `:valid` and `:invalid` selectors are really powerful tools when it comes to CSS. This is a real fun use of clever CSS selectors.
I was doing something similar the other day with toying around trying to come up with an HTML/CSS only game. I ended up with this: https://codepen.io/billnreed/full/boXrVr
48 comments
[ 3.3 ms ] story [ 112 ms ] threadIt'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 calculator sans JS, but it's nice to know that it's possible and it could be something I look at if I want to implement a piece of it for something similar.
You could also make more than 50 in his js renderer file on github if you needed more
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 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.
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
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 lot of sense to me, consistency-wise, at least in these days of CSS3.
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.
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.
How complex of a web app can you make without using javascript.
CSS-only for this sort if thing is totally contrived, but making it still proved to be a fun little exercise.
[0]: https://codepen.io/scryptonite/pen/oLGzdj
[1]: https://github.com/you-dont-need/You-Dont-Need-JavaScript
That's not an app.
TL;DR: Use styled checkboxes in a form.
In the end, he made a TODO-Layout, not a TODO-App. Interesting experiment I suppose, if you are into frontend stuff
Yes, you can create certain interactions with CSS alone but doing so purely for the sake of not using JS is pointless and at worst harmful.
https://news.ycombinator.com/item?id=15589943
I was doing something similar the other day with toying around trying to come up with an HTML/CSS only game. I ended up with this: https://codepen.io/billnreed/full/boXrVr