Live data from Hacker News

You might not need JavaScript

youmightnotneedjs.com

121–130 of 254 posts

Re: You might not need JavaScript

#121
post #35

Earlier quoted context omitted.

Do any of the examples use Javascript? Or are you saying the site shouldn't use JS for syntax highlighting or whatever, even though that's not the sort of thing it claims JS isn't needed for?

If you look at the source, there are plany of JS files being loaded. Mostly from codepen, but also from the site itself. I don't see any features of this site which should require javascript, so they should probably "practise what they preach".

Technically, they're preaching that you might not need JavaScript rather than advocating against it

Re: You might not need JavaScript

#122
post #9

The you don't need jQuery website had a concrete use case - you need not include an entire library into your website for some simple tasks which makes your website faster. Though, this site is cool in showing the power of CSS, I am not sure if there is any specific advantage of using CSS over JS to design tabs, sliders, etc. Just use the best tool for the job!

There's definitely some merit to not requiring users to download and run arbitrary and untrusted Turing-complete code. Whether abusing a stylesheet language to achieve that is worth said merit is certainly debatable, but I for one applaud the effort.

Re: You might not need JavaScript

#123
post #110

So let's show off what you can do without JavaScript...but also include SCSS as a dependency when the opening paragraph complains about a JavaScript dependency? Madness...but I digress. Some of these are cool examples. Others, like the modal, won't scale very well because now you can trigger modals by tabbing (breaks keyboard navigation) or most of the form examples as you'll likely hit many endpoints that require JS…

All you need is this motherfucking website: http://motherfuckingwebsite.com/

Actually you need a tiny bit more: http://bettermotherfuckingwebsite.com

Re: You might not need JavaScript

#124

There is some useful stuff to learn from here, undeniably, but many of these are a bit useless when you compare them with what you would actually typically need on a real site. Yes, the "image slider" is vaguely functional, but really most of the time you will want a lot more control than just the CSS animations allow; similarly, yes, the form validation is a starting point, but normally you would want to customise t…

What bothers me is that I saw many of these things implemented in CSS only in ~2004. Of course, it required much more code then, including shims for IE 6 and careful slicing of GIFs, but things like tabs, accordion or lightbox were being implemented. Makes me wonder where the last decade went. At least there was a good reason to avoid JS back then: it was slow and often looked worse than CSS hacks.

Re: You might not need JavaScript

#126
post #39

I'm cautious about using CSS to do things that feel like actual behaviours. For example, the modal that appears when you click on the button actually doesn't do things on "clicking" but focusing . This means if you tab over the button it'll load the modal, then tabbing away means the modal is gone. I can't tab into the content in the modal at all. How does that work with accessibility? Though I generally dislike the…

> The "Would you prefer a banana or a cherry?" just shouts "Please match the requested format" if I type "a cherry". I know chrome has nothing else to go on other than "the regex wasn't matched" but it's a bad end user experience. Localized custom validation messages for the provided pattern should be added as part of HTML spec. Someone should follow up on that, because it'll probably be too much of a waste of time f…

>Localized custom validation messages for the provided pattern should be added as part of HTML spec.

That sounds like a reasonable addition. Perhaps a series of validators and messages?

> Yes, but if you are writing for a general audience, make sure it's accessible: http://webaim.org/techniques/javascript/

Very true. Thanks for the link.

> Someone should put together a site that, given a set of browser restrictions the user provides, gives examples of each of these to show the most accessible and standards-compliant version of the code to use, minimizing external libraries required, with and without localization, because not everyone has the resources to provide localized content, unless localization could be provided by a built-in library in the browser or OS, which would be another great project.

This is something I'd like to see, because apart from a few things I know to look for (tabbing, for example), I don't know how well various devices and settings do with different content. Consistent approaches also help people working on things like screenreaders.

Re: You might not need JavaScript

#127
Funny that I had to activate javascript in order to see the previews, so, although you don't need JS in real life, you need it to convince people to stop using it.

Kinda like when Dante wrote in Latin about the utility of the Italian language.

Re: You might not need JavaScript

#128
post #48
post #5

It's sad that this site uses SCSS for displaying the rules, I'm using it in production and fully understand it, but it's needlessly abstracting the rules for the sake of a few extra words in each declaration. That aside, these are some pretty cool examples. Are there ways of doing this with CSS which doesn't screw with my browser back button?

I half agree with you, but one of the real benefits that SASS gives you here is making dependencies more obvious. A named variable like `$slider-height` is much clearer than a random number like `50px`. Yeah, you could put a comment next to every constant in the CSS, but I don't think that's clearer than the SASS alternative.

I'd hope CSS variables [1] will make that argument obsolete soon, but then again I've been hoping that for a while...

[1] https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_v...

Re: You might not need JavaScript

#129
Yuck. I'd take a simple well crafted and maintainable JS solution over an opinionated CSS preprocessor any day of the week.

Preprocessors do nothing but splinter the CSS scene by layering odd syntax over an already creaking/complex CSS spec. Got nothing against compiling CSS in general - postprocessing features related to current and future CSS specs with PostCSS is a great idea. But dividing the community's attention between multiple competing preprocessors while it should have been concentrating on the spec is the worst thing to have ever happened to CSS.

Great things happened to JS when people got behind tools that pushed the language forward while keeping the current and future spec in mind (ES6/Babel). Shame CSS took an alternative approach imo.

Post reply on HN