You might not need JavaScript | Hacker News Reader

You might not need JavaScript

youmightnotneedjs.com

649 pointsMarkusWinand246 comments

When I was hired on the Watson team, the first thing they asked me to do was help improve performance of their AngularJS-based website. It was all-around slow, especially for the initial page view. I stripped out AngularJS and most of the other JavaScript, and published a website that was almost pure static HTML. It loaded very quickly. My manager thought it was hilarious - his "JavaScript expert" came in and deleted all of the JavaScript.

As a developer, I find more pleasure in deleting code than writing it. It might have been hilarious, but I wasn't surprised to read that :)

More than hilarious, I find it a serious skill manifestation.

A large percentage of the "very skilled" developers I know will much sooner brag about how much code they deleted or didn't write than how much code they wrote.

That is already well known quality[1]. I find Parent work even deeper, he pivoted the whole thing to make his main skill a second class citizen because that's what it was to be in this context.

[1] I regularly nerdgasm at LibreOffice releases reading how many thousands LoC they removed from the code base.

ps: beside code golf, I think there should be a patch golf thing. Try the smallest changeset that fixes or add a feature.

I like the idea of "patch golf". If only people would at least do a diff before they commit to spot gratuitous reformatting or accidental changes :-(

That's the exact reason I thought of it [1]. With "large" code base, every character impacts the project, patch size becomes a skill. That said, it's so tempting to fix multiple almost related things in one go.

[1] also, git surgically precise patch mindset helped too.

A very proud moment for me recently was when someone ran git stats and it showed I'd deleted more code than I'd written. It was glorious.

Lazyness is a virtue for software engineers in my opinion.

Generally when I hear people talk about having imposter syndrome in software development, I feel like they're missing this key insight. The fastest code, and the easiest to maintain is the code that's never written. I've been trying to formulate how to express this idea to people who don't have it ie paraphrasing YAGNI:

"Strive to optimize for less code, and the minimum level of abstraction."

That should be the appropriate level of abstraction. The appropriate level of abstraction being that which requires the least code to implement and least effort to reason about.

I think "appropriate" is highly subjective. The problem is developers seeking to impress their peers with over abstraction of trivial things. I personally think "minimal" is more "enforcable" ie easier to convey in a code review comment for example. Again, imo.

I did just that same thing for a client. They were using React to make 1 AJAX request to Foursquare. The thousands of lines of code turned into 22 lines of vanilla Javascript. I was shocked.

Or when a project includes jQuery for a single AJAX call - someone somewhere got paid for that ridiculous insight.

Given "fetch" is not yet a standard, jQuery $.ajax is actually a decent cross-browser polyfill.

I've been out of the JS world for a few years, but for a single Ajax call, why wouldn't you use XMLHttpRequest?

jQuery ajax essentially is just a wrapper to XMLHttpRequest.

With some effort, the relevant jQuery methods that act as polyfills could be extracted.

However, a minified version of core jQuery is < 20Kb. A very low technical debt trade-off to support 99% of browsers.

Why would you care about IE8 - 9 or whatever other browser you might be thinking about that has probably an infinitesimal market share?

Market share might be a ridiculously small percentage overall, but it's never appropriate to dismiss compatibility outright.

Reasons to include inefficient code for compatibility reasons might include applications where maximum reach is valuable, or where the scale is so large that the "infinitesimal market share" percentage plays out into thousands of end users.

Because market share is only meaningful if you target consumers. If you write (internal or niche) web applications for e.g. schools, large companies, non-profits etc. legacy browsers can easily be > 30% of your targets.

"They were using React to make 1 AJAX request to Foursquare."

Did anyone get fired for that bit of programmer malpractice?

The parent comment is a freelancer. The code he corrected was almost certainly from another freelancer. And so the cycle of outsourced code continues.

Exactly this, but hey at least I know what I'm doing and the client is happy!

It reminds me of this:

https://hackernoon.com/how-it-feels-to-learn-javascript-in-2...

I've had interview candidates for frontend developer positions who only know how to build web pages using frameworks like Angular and React. They don't seem to understand how those frameworks work but essentially patch together a bunch of example online to get something going. It's truly unfortunate that many beginner web development tutorial introduce these technologies first in my view. Without giving new developers understanding basics of the web platform they get siloed into only knowing one way to do things and it results in using the wrong tools for the job as this example shows.

Here's another perspective. I started learning JS in reverse and ended up just creating my own framework because it was less verbose. But you would hire me over your patch-and-patch fellows?

Perhaps the right answer is to code know the basics but also have a handle on the popular frameworks too.

"Here's another perspective. I started learning JS in reverse and ended up just creating my own framework because it was less verbose. But you would hire me over your patch-and-patch fellows?"

Yes more likely. In fact I would find informative to see the framework that you have built as an example of understanding web development.

To expand a bit I think learning the framework is easier once you have an understanding of the web platform's basic. For non web stuff I value more problem solving ability, general CS knowledge over specific technology knowledge. I usually don't set a language requirements in interviews and look more to someone being able to explain how the code they wrote works and why it's a better solution than say some inefficient brute force method. Which in my example when applied to web stuff would translate to why is implementing something this way in angular better than an alternative, what advantages did you gain from angular. Etc...

My framework looks like this: https://github.com/serprex/openEtG/blob/master/dom.js

The code that uses it looks like this: https://github.com/serprex/openEtG/blob/master/views/MainMen...

The site looks like this: http://etg.dek.im

I recently worked on a site at my job where I was able to implement it with JS + C#/OWIN, all static html, only uses toastr/jquery. Was nice they let me break away from the illusion that the choice is only between WebForms or MVC

If you ask me to compare this to Angular, I'd have to say I've never used Angular so I don't know

Seeing that code I would not hire you.

Any specific reason? Not trying to be accusatory, but your comment appears not genuine and I don't see anything instantly unhirable about his code after a short peruse.

Depends what you're being hired for, but I tend to believe hiring managers are overly biased towards CV bullet points on the highest common library/framework in the stack. This is after all the most precise information you can put in a job description that is actionable by a recruiter/HR-person.

But in my view, building your own framework first and then learning a standard equivalent gives you a much better understanding of the tech of the new framework which will pay dividends. For instance, I built my own PHP framework in 2001, and subsequently played around with Drupal/Django/other homegrown frameworks. When Rails dropped in 2004 I was immediately ready to jump on board because I had been through the same mental process as DHH had when he started building Basecamp in Ruby after having been frustrated by PHP. Whereas a lot of people complained about Rails' magic and lack of transparency, to me it was very easy to dive into the source code and understand the reasoning that led to its architecture.

Of course these things calcify over time, and you don't need to necessarily go very deep into every layer of the stack, but you have to at least be competent in a few layers or you'll be helpless the minute you hit a problem with a leaky abstraction. But in the case of JS, yes I think any time spent learning core JS is well-spent, and knowing only React/Angular is a real liability as a front-end engineer, especially because those frameworks are designed to solve heavy SPA problems which are only a tiny subset of the type of interactive web pages one might want to create.

I'd hire you but I'd still make you use a framework.

Convention makes code readable and maintainable. A framework is essentially shared convention that you don't have to maintain. Making your own framework shows that you understand the value of convention.

A framework means that spaghetti code can only get so bad. A bad ad-hoc implementation of a web platform is an order of magnitude worse than bad code written on top of a popular web platform.

When I look at ugly React code, I know how to extract logic, where to push it, how to identify poorly-named concepts. When I look at ugly vanilla JS, I don't know what to make of anything.

How would you suggest breaking out of that silo?

Asking for a friend? ;)

Haha you know it :)

Start from scratch/plain ol html. Add dependencies as you need them and for very specific purposes rather than have them "just because"

Right, start with something simple, say a form and add client side validation to it. Move to making a small widget that updates with data obtained async using plain XHR. Add some styling with out preprocessors (so you know why they make life easier). Understand events and how they propagate etc. Learn a bit about the DOM and how to query it with built in apis. Etc...

Consult MDN (Mozilla developer network) and read their articles

Stay curious. If you know only one framework, read its source and understand every bit of it (or which parts you can ignore and why).

> only know how to build web pages using frameworks like Angular and React

I've never been able to fathom how anybody can do that without understanding the foundation that it's built on. At the bare minimum, how the heck do these people troubleshoot errors? If you have so much as a typo in your code, Angular is going to give you a completely cryptic jQuery error message.

This is why I came to really dislike angular pretty quickly. Maybe it's just evidence that I suck at javascript, but I found it devilishly difficult to debug even seemingly simple issues. But the errors were not in jquery, they were in the maze of the digest cycle. But I agree, I have no idea how beginners manage when things fall off the happy path.

I think it's partially an artifact of JavaScript's historical arc. Piecing together examples was maybe not best practice, but it was pretty damn good practice in the days when Jquery was best practice and in those days Jquery was best practice because browsers varied. I mean the alternative to using black boxes was to recreate Jquery.

It's also partially an artifact of JavaScript's lack of namespaces and scoping rules and prototypical inheritance because these make it easy to make a class of errors that are conceptually difficult to understand without holding a complex mental model in my head...and that's after standardization of browsers reduced the number of arbitrary rules that could cause bugs.

I would say that is what makes you truly a "JavaScript expert". Knowing when to use it and when not to but most importantly knowing how to implement alternative solutions when needed.

It would be cool to see the before (with AngularJS) & after (pure HTML) of this.

I've been a Frontend Dev for almost 5 years now. I feel a large part of performance is knowing when and where to remove unnecessary JS.

Every time I read about the original "hackers" of the modern computer era, it seems many were much more focused on refining their code, or "bumming" lines of code, into the smallest form possible due to the technological limitations of the time. It's not super surprising many developers aren't as conscientious about bloating software because computers have gotten fast enough to mask a lot of performance issues. Still, I think those who strive for less code show maturity as a developer. For one, you can't remove lots of code if you don't truly know how the code works, and furthermore, that process is a good way to learn how it does.

There's a name for that: https://en.wikipedia.org/wiki/Wirth%27s_law

I just sent an email to my "favourite customer", recommending that they hire you!

Of course: The important thing about a tool is not just to know how to use it, but also when and when not to.

Nice example.

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 JSON (which yeah I know "you're making a web app why can't your endpoints accept a form?" but as we all know it's never that simple and you might want to provide different behaviors for, say, showing a progress bar or disabling certain features during the submissions or a THOUSAND other things).

I get axing dependencies. I really do. I wrote msngr.js entirely in ECMAScript 5 using zero dependencies so I'd have the most flexibility possible. But at the same time overcomplicating your code to the point where it's breaking standard practices or making it un-maintainable simply to axe a dependency is the wrong way to go.

But by all means keep making cool stuff that shows off how versatile CSS is! Just don't expect to use all the CSS tricks you learn in a production environment.

You should surely realize that requiring SCSS and requiring JS are two very different concerns.

Of course they're different but the article mentions JavaScript as a dependency. SCSS would also be a dependency it just comes into the stack at a different place but it's there nonetheless.

Regardless my other points still stand.

One is a server-side depencency and one is a client-side dependency. Don't conflate them.

SCSS isn't even server side, it's developer side. Your build pipeline can be ugly as sin, the client should never care.

Until you need to maintain it (small changes) or worse, (breaking) change it. I'm not going to trade a flexible js dep for a limited css trick.

I never did conflate them. I've worked in this industry for 12 years now. I really don't get the disconnect here. I called it a dependency because it is and everyone is trying to tell me it's a different type of dependency. Well no shit but that was never my point to begin with.

My point was hijacked and contorted here.

What everyone's trying to tell you is that your point is beside the point.

The dependency thing was a minor quip at the start, it was never the point...the other 70% of the text was the point and unrelated to my dependency comment. I don't see anyone trying to say that, these comments seem as if my quip was the entire point of my post.

Talk about a tangent over a tiny, unremarkable comment that was meant to be light hearted.

SCSS is not a dependency for the user, this gets rid of the requirement of having JS and having it enabled and any page that works without JS is a better page than one that requires it.

Compile time requirements and runtime requirements are different things.

You could go the other way just as easily, and eliminate the css requirement. Doesn't mean it's the best way to do a given thing.

Also, the examples don't support a lot of use cases... the accordian and tab examples, while interesting will submit goofy information if they're containing multi-part forms.

The image changer will break other bits of navigation, or similar changers by abusing the target. Similarly, the lightbox example doesn't have a slideshow support, and even if so, would probably be as/more complex than just using JS.

Also, how many of these examples work in IE11? This browser will be around a while for public facing sites, and has some really broken implementations of newer css features like calc (which doesn't work in several scenarios).

Amen. If you are really good at CSS, you might play to that strength. Or, you might play to different strengths. There's probably more than one way to do it in many cases that doesn't hurt the project.

My 100$ smartphone came from a 5B$ factory.

I agree, but I think you're putting the emphasis in the wrong place. A SCSS dependency isn't that bad because the client will never see it.

What is bad is code that's hard to maintain. When I did a stint of front end development recently, I went in with the mindset that "JavaScript is evil for the user and therefore should not be used when avoidable". I discovered after a while that although you can replace JavaScript with CSS sometimes, the resulting code is often much more difficult to understand and modify than the original JavaScript would have been. It's no longer in my interest to avoid JavaScript at all costs, as was the case before.

You touch on this with your "overcomplicating" sentence, but I feel like it didn't get the spotlight it deserved in your comment!

Javascript is not evil, evil is when it's used unnecessarily, and when your page displaying 4-5 pages of text starts out 2mb without images and becomes 15mb as I scroll to bottom because you're pinging various third parties for analytics and whatnot, and when I can't view you pages where the essence is a couple paragraphs of text but you wanted to render it via Javascript and I have it blocked and you not whitelisted, and when I hesitate to use my schools web services for important things that may affect my academic career but god knows what's gonna break when on that halfe-arsed website, and especially when you mess with my history (my pet peeve).

These "you"s are rhetorical BTW, I'm not addressing kqr directly.

> Javascript is not evil

We-e-ell, it's not a good language. But it's what we have.

I agree, though, that it can be used well and does have a place in writing good web pages and sites, but that when it is used to create horrible 'web apps' it is being used for evil.

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

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

Getting there! https://bestmotherfucking.website/

If I was the owner of motherfucking.website I would also take requests at better.motherfucking.website and best.motherfucking.website.

The first two were actually making a good point. This website (yours, presumably) is just jumping on the bandwagon and sticking an affiliate link in it. I'm not against affiliate links, but this site lacks substance.

The affiliate link does kind of bother me, but the rest of the page is pretty good. Especially about keeping real black as your font color.

HTTPS and full contrast text are important. The 2nd attempt is a downgrade from the first. This 3rd attempt is an actual improvement.

The second one is the only one that puts any effort into actual legibility. There's a nice comfortable amount of space between the lines! The text doesn't render right at the edge of the page! There are MARGINS and WHITESPACE.

If you just take your browser's defaults for all the typographical stuff like that, everything looks like trash.

Honestly, I can't stand websites that decide to waste 70% of screen estate. I can see the first site almost without scrolling. It is 2 to 3 pages on the other iterations.

The only things I may agree with is https and zipping.

"Fits on all your shitty screens" Does mean that it FITS ON ALL YOUR SHITTY SCREENS. Mine is a 1920x1080 (which is the minimal nowadays) and the 2nd and third iterations DO NOT FIT IT.

That thing around the web page, it is called a fucking window. It resizes. I'll do that if I want your fucking column-format.

And a very tiny bit of additional polish (which would make a good basis for, say, browser defaults), IMO, even better: https://codepen.io/dredmorbius/full/KpMqqB/

14 style rulesets.

I think it would be better without the horizontal lines.

I remember one of my dev friends showed me this when jQuery was taking off. The site has changed over the years because back in the day when I first saw it, he was railing against using too much javascript - specifically jQuery.

None of these requires SCSS at all. You may verify by grabbing the SCSS they provide in the codepen and pasting it into http://www.sassmeister.com/

Most examples are equally compact in plain old CSS. In fact, many of them are just plain CSS displayed in a window labeled "SCSS".

The places using SCSS seem like they're simply being more sane in allowing a user to change numbers trivially. Instead of saying "just change all the 400px throughout to 500px", one can change the `$slide-width` definition in one place (usually at the top).

There's also the style preference of nesting to group. But neither of those make it a strict dependency.

---------

EDIT: I'm not saying that I disagree with your assertion that CSS is a bad place to layer logic from a maintainability standpoint; I'm more pointing out that blaming it on SCSS makes no sense in this context.

> I'm not saying that I disagree with your assertion that CSS is a bad place to layer logic from a maintainability standpoint; I'm more pointing out that blaming it on SCSS makes no sense in this context

I don't see where I blamed anything on SCSS just found it amusing the page purports to axe dependencies (JavaScript) but uses SCSS. The rest of my post is far more on topic and interesting. Everyone is focusing on my SCSS poke though, heh.

I certainly agree that the rest of the post makes sense and is more on topic! It's why I felt the need to add the statement at the end of my own stating that I agree with it, immediately after I posted it ;)

Re: requirement - there I was referring to your opening:

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

And explaining that although they used SCSS, it certainly isn't a requirement, nor even much simpler than the plain CSS.

I'd guess that most of the responses probably focussed on it because leading statements are often read louder than what follows them. They set the mood/tone in a way.

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 idea of saying content isn't there by making it present in the document but invisible.

Edit - Some of the default behaviours are also a bit pants. In chrome, the form validation on a pattern starts working after I hit submit, then angrily shakes at me for every keypress until it's valid. Then, it ignores invalid input as I type more! Please never use this for phone numbers or credit card numbers. Stop requiring an exact format when what people type varies, and stop telling me I'm putting in something wrong when you ask for a phone number and I give you something that'll connect to me if you type into a phone.

Maxlength is not a validation it's just ignores any more letters you type. Quietly ignoring your users input is probably not what you want.

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.

The tabs example is something I need to tab onto then use left and right, I assume because it's a radio box underneath, not a series of links. Are tabs really radio buttons?

The same for the accordion. Which I've found if I add any tabbable content inside them then I'm focused on a hidden item. Great. Tab onto "tab 1", hit tab, focus has disappeared and I'm now potentially going to click on random items I can't see. This is because although you want to pretend the content isn't there just because it's not visible, it's still there! It's in your document.

Sure, you might not need javascript. But maybe you should still use it.

> 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 for me.

In the meantime, this works and gets around a bug in FF: http://stackoverflow.com/a/20189012

  <input type="text" id="username" required placeholder="Enter Name"
      oninvalid="this.setCustomValidity('Enter User Name Here')"
      oninput="setCustomValidity('')"  />

where setCustomValidity could provide any text, even localized text from some other source like a DB, potentially, since it's JS. Requires a modern browser, though.

> Sure, you might not need javascript. But maybe you should still use it.

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

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.

Yes, there are sites that provide a matrix of supported browsers, but I don't think that would be as simple to use; developers like copy-and-paste examples, for better or worse, e.g. StackOverflow.

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

Yeah honestly banana or cherry is just screaming for a much simpler plain old radio input.

It made me learn about http://caniuse.com/#feat=input-pattern ; thanks for that!

Same. Didn't even knew that exists. Awesome.

Same here and it seems fucking amazing. I'm beginning to wonder how many more html-things like this I don't know about?

If this is your first time hearing about caniuse, then you likely also want to know about html5please.com as well; if you haven't already.

I use caniuse excessivly, I just hadn't heard about the pattern attribute. But thanks for the tip, html5please seems very nice!

May be worth perusing https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in... for additional attributes that are native to the input field.

Seems like the pattern attribute is the only input attribute I've missed somehow.

Does anyone else feel that a site called "You Might Not Need Javascript", probably shouldn't use Javascript?

No?

Perhaps they needed Javascript ;)

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

Why would syntax highlighting need JavaScript?

The browser doesn't natively support syntax highlighting (they aren't features of HTML or CSS).

It depends what you mean by "support". There are two things a JavaScript syntax highlighter is doing:

1. Classify each token (whether this is building up an AST or doing something more fuzzy/clever is immaterial for this discussion); 2. Construct a DOM tree (HTML) that is styled (CSS).

Step 1 does not have to happen client-side at all. Step 2 doesn't require JavaScript at all.

That hardly makes sense. Changing the color of text is definitely a feature of HTML and CSS.

What's the lazy reason for not rendering that before serving the html page.

Yes?

Depends on what it uses it for. It says you "might not" need it, not that you won't need it.

I blocked all js on the page and the examples just disappeared. I could just see the undecorated code snippets.

This website does not need JavaScript. It's progressively enhanced with it.

Maybe?

I was reading it with javascript disabled and very confused - are there only code snippets and no visualization of the examples? After reading your comment, I went back and enabled javascript and now can see the examples.

You might not, but you probably do.

The validation examples and input types are a case in point. Even on browsers where they work, the alerts can't be styled and the behaviors can't be controlled.

> the alerts can't be styled and the behaviors can't be controlled

It's not clear to me whether that's a problem. Isn't consistent UI a good thing? Isn't it faster to fill the forms correctly if alerts always appear in the same way?

How is it consistent UI when it doesn't match your design and looks and works very different in every browser?

It's consistent with the platform, i.e. the alerts are native

You should experiment with these. They are different on different browsers on the same platforms.

Sure, but (unless their GUI is implemented with web technologies for some reason) they generally use native widgets, at least.

I've actually spent many hours trying to make them work. You should at least invest a little research time before making proclamations about how you imagine they work.

I now see that we're not really talking about alerts in the 'alert()' sense, but rather about the popups - which are not native widgets (which are better off non-modifiable, in my opinion).

My bad.

Do you know of any good reading material concerning these form validation popups?

From reading on MDN [0], they seem to be browser specific - like the Chrome connection tab [1] - but somewhat customisable via JS.

[0]: https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Form...

[1]: https://blog.digicert.com/understanding-the-google-chrome-co...

Not really. The errors on Firefox at least, just say "Please match the requested format", which doesn't tell the user where they went wrong for potentially complex requirements.

You can use the title attribute to customise the error message.

Consistency is a good thing, provided that the thing you are being consistent with is good in the first place.

The form element type is perfectly enough for frontend validation.

You should do the rest on the backend anyway.

I don't get where the popup ( when you don't match the pattern) in the form example is coming.

Is it from the browser? Can someone explain?

It's from the browser, using the form input attributes they describe.

When submitting a form with an incorrect pattern in Firefox, the validation behavior highlights the relevant textbox in red for a second, and removes its contents. This default behavior gives a very poor user experience.

And if we spent half the time we collectively spend making JavaScript validation programs on making the Firefox validation behaviour better, it'd not be this way.

Who goes first? Not me!

Perfect enough? Hardly. Errors aren't shown until you submit, giving you no opportunity to fix the mistake while you are there. It also only shows one error at a time. So if you have multiple errors, you fix one, everything is fine, and you don't see an error until you submit again.

> You should do the rest on the backend anyway

Well yes, you should validate on the backend, but you shouldn't wait to only validate on the backend.

This works well enough for getting things done quickly, but it's hardly a good UX, and a far cry from "perfect enough," whatever that means.

Yeah, from the responses, I'm definitely seeing a gulf between "people who've read some random stuff on HN about web design" and "people who actually do web design".

I think a more important point is that you should design your website to still be functional even if Javascript is disabled.

Why? Because some users, such as those who use Tor, may have legitimate reasons to disable Javascript execution while browsing. Another reason is that Javascript-generated content can screw up your website's SEO when crawlers visit your site.

Using Javascript for your form validation is okay if your form will still work with Javascript disabled. Yes, the user will lose some functionality of not seeing pretty validations, but it's okay if they can still use your site. [1]

Where JS becomes a problem is when it's used in ways where disabling it completely breaks the page... Single page web apps: I'm looking at you.

-----

[1] One way to improve the experience of form input validations for Tor users could be to have both a JS runtime validation and server side validation of your form inputs, and then put the validation messages that both would generate in the same place so that they stay in sync.

I'd argue that single-page apps are a completely new emerging paradigm- the "web-page-as-application" rather than "web-page-as-interface-to-application" (or "webpage-as-hypertext-document", before that.) This isn't to say the previous two paradigms are bad, just that they're solving different problems. In light of that, here are a few responses to your points:

> Where JS becomes a problem is when it's used in ways where disabling it completely breaks the page... Single page web apps: I'm looking at you.

Here's my point: if you disable Javascript and navigate to a URL where a single-page app is hosted, the page isn't broken, your execution environment is. If I make a React app, then ipso facto I'm making an explicit choice to exclude folks that don't want to enable Javascript.

HOWEVER

> I think a more important point is that you should design your website to still be functional even if Javascript is disabled.

There's absolutely room on the Web for all three models: document, interface, and application. And despite my disagreement with this point when it comes to client-side applications, I definitely agree when it comes to Web documents and Web interfaces to server-side applications. (Rails muddied the water something fierce on that last one, which has been the source of uncountable headaches for me.)

I agree with what you're saying, but many, and I mean many, single page web applications get used for things that are essentially Web documents.

If you're building a game or something interactive, I get it. But many SPA's are used to give database-backed forms a pretty skin. It's the overuse of Javascript in this way, and the lack of graceful degradation for forms like this when Javascript is disabled, that I think is beginning to create concern.

you should design your website to still be functional even if Javascript is disabled

True, but irrelevant to the issue of "can you do X on the client side without Javascript?". I can imagine a Javascript form validator that somehow makes the form unusable with Javascript turned off, but I've sure never seen one.

And server-side validation is website 101 stuff that you should always be doing regardless of the front-end technology, not a counter to the many good uses of front-end validation.

I agree. Though sadly keeping your JS validation messages in sync with the ones your server produces can still be a surprisingly high amount of work and headache. Many people can think of the time it takes to build functionality like this as gold plating.

Or you can just respond with a "Bad Input" static HTML page.

Your Back End should be validating the Front End. As it is possible for people to make their own HTTP Post messages to your Back End. This is actually fairly trivial to do if you can use wireshark+curl/hippie/wget.

You're talking website 101 stuff. That doesn't pertain to the client-side validation issue, as you should be doing it in every case, anyway.

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!

The Tor web browser disables most (if not all?) Javascript by default as a security measure.

Avoiding Javascript is an advantage if you want your website to be accessible to Tor users.

If your website only handles basic things like form inputs and it breaks when Javascript is disabled, then you have not made it accessible.

I think by now it's pretty safe to say most websites don't care about the tiny % of people using Tor or disabling JavaScript.

That doesn't make it laudable, or even defensible.

From a commercial point of view it kind of does. If the development costs exceeds the increased revenue it's not really worth it.

http://youmightnotneedjquery.com/

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.

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?

You might not need Sass.

I absolutely agree! While we can discuss about why SCSS is better, it is more like comparing Volvo with Mercedes. In the end, CSS is the standard, not SCSS. And CSS is evolving and getting better and better.

There's a "view compiled" button that turns up if you hover the SCSS in codepen. I got through half the doc before discovering it though. I was very surprised to see the ampersand, since I was pretty sure CSS didn't have anything like that.

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 think you've hit the nail on the head here.

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

SCSS variables also make things FAR more maintainable. To change a color, you shouldn't have to change every single line where that color is used.

You update the value where your color variable is defined, and then each style declaration that uses the color variable receives the new value automatically.

Some of these are ok, but others are just misusing features for their intended purpose. An input gaining focus is not the same as a click event. Using the :checked peudoselector to keep client-side state is not an alternative to using JS.

Using HTML/CSS hackery where you should be using JS instead creates an anti-SEO, non-semantic mess that causes headaches for others to work on and nightmares for anybody needing to extend or modify functionality.

Don't get me wrong, I love pure CSS solutions and try to use them as much as possible where it makes sense. But sometimes, it definitely doesn't make sense. JS isn't something users or developers should be scared of anymore, it's much better supported and much less intrusive than it used to be.

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 the error messages and generally fiddle around with it a lot more; I'm not really sure the modal is fit for purpose beyond the most basic use case... etc.

It's fun to see what you can partially achieve without JavaScript, but there is no shame in using JavaScript sensibly to enhance the usefulness of a web site.

Image sliders are considered bad UX to begin with, and the lack of user control makes them even worse IMHO.

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.

So, we're all familiar with the fact that imgur requires JavaScript in order to display more than the first few images in a gallery (the 'view more' link executes JavaScript; there's no way to page forward). That's highly annoying, since HTML supports exactly this use case.

It's understandable, though, because we are not imgur's customers: its customers are advertisers, and if we have JavaScript disabled then imgur's customers have less ability to violate our privacy. Thus, it's in imgur's best interest to encourage us to reduce our privacy & security, so that its customers may have their way with our browsers. I can't see that the imgur programmers would care about the fact that they can do amazing things with CSS.

But recently I've discovered that Target's website simply refuses to display products without JavaScript. This is insane: Target are, presumably, in the business of selling things. They ought to want to display a picture of their item and provide me a link to buy it; that's in their best interest. Building that sort of website is easier than building the sort of ecommerce site which cannot even display an image and a link without JavaScript. It should be in Target's best interest to do the right thing.

But it doesn't. Its programmers ought to be interested in a site like youmightnotneedjs.com, but are they? If they didn't bother to build their website properly before, is this likely to encourage them now?

The issue with CSS sliders is that they mess with the browser history.

I expect my back button to open the previous page, not to move an image slider.

aren't you talking about the view switcher ( http://youmightnotneedjs.com/#view_switcher ) ?

In this demo yes, however I have seen CSS image sliders with buttons which happily sit on the back button.

Am surprised no one has pointed out how bad these examples are for accessibility, no pause/play on the slider, hidden content that won't be read by screen readers etc.

I like the idea of using CSS over Javascript where it makes sense but in a lot of these examples it feels hacky.

The rationale of the site site is simple purism, not mere technical considerations like code complexity, accessibility, history pollution, etc.

Since half the examples do not work on Safari, I believe the title is a bit misleading.

Safari is the new IE6, stop supporting it and let it die. It will not get any better anyway. If most of your users are on iOS, then make an app for them, it's what Apple also want you to do...

I switched from Chrome to Safari 5 months ago. The memory usage in Safari is far more superior than Chrome / Firefox on OS X. Also the CPU usage is relatively low, which means more time on battery for me.

I still use Chrome for development, though.

Safari, is not as bad as IE6 was and anyway no professional front-end developer would make a website that is not working properly on iOS Safari, so it's kinda obvious it will stay supported for a long, long time.

So I would consider what the OP is doing with the CSS, something that might also work on Safari, but with some polyfills.

Oh please. Safari 10 (both desktop & iOS versions) is the only browser with 100% ES6 compatibility. All browsers have some issues (e.g. Chrome still does not support 'sticky' position, Safari hasn't implemented Service Workers, etc), that's part of the multi-vendor / open-standard game.

http://kangax.github.io/compat-table/es6/

Safari does have longer release cycle than e.g. Chrome, because Apple provides very uniform / polished support for wide range of devices (Macs, iOS devices, including very old ones such as iPhone 4S).

I have no idea why people use Chrome.

Chrome/Google has terrible/no support of many browser layout & interaction features, such as CSS Regions & scroll snap points.

Also, Safari is just a much better browser than Chrome. We need to make sure people stop using Chrome and move to the default browser in their environment - Safari & Edge.

If you support the default browser, then you're going to be fine.

> default browser

Hi, I'm Linux.

Yay for Midori, Konqueror, Epiphany, Dillo, lynx, and all the things a regular dev never have to encounter with :)

( By the way lynx is perfect to pierce through a lot of paywalls. )

Chrome is still the best choice for development on Linux.

The alternatives are Opera and Firefox. Everything else is like coding while wearing mittens.

Well I use Chrome because I find the development tools to be much better than those in Safari.

It gets tedious switching the default browser setting over so I tend to just use Chrome for everything.

>Safari is the new IE6, stop supporting it and let it die.

Not sure what old wives tales you have heard, but actually Safari was the first browser to 100% support ES6.

And compared to Chrome, it uses 1/3 less battery...

He is parroting a year old clickbait headline (https://nolanlawson.com/2015/06/30/safari-is-the-new-ie/) where the main gripes were that

- Apple didn't attend EdgeConf 2015

- https://webkit.org/blog/ was not updated often enough

- Safari 9 had a seriously buggy IndexedDB (fixed in Safari 10)

I would rather refer to this https://news.ycombinator.com/item?id=12051267

I'm not the only one who think Safari is a joke compared to the competition. While IE6 was much much worse than what Safari is today, I feel like history is repeating itself again. And ES6 support is irrelevant when the main goal is to make sure websites renders and behave correctly, which is more painful for Safari than the other browsers.

I still have flexbox issues on Safari https://bugs.webkit.org/show_bug.cgi?id=136041

>I'm not the only one who think Safari is a joke compared to the competition.

How does that opinion survive reality, e.g. Safari being the first browser to reach 100% ES6 compliance?

>I still have flexbox issues on Safari https://bugs.webkit.org/show_bug.cgi?id=136041*

So? All browsers still have Flexbox issues. Here are Chrome's:

https://bugs.chromium.org/p/chromium/issues/list?can=2&q=com...

ES6 has very little to do with keeping up with Web APIs. See https://platform-status.mozilla.org/
Notably Fetch API and WebRTC for my use-cases.

IndexedDB is actually not fixed in Safari 10: https://www.reddit.com/r/javascript/comments/545ylm/psa_inde...
Hopefully they'll figure it out eventually!

Websites and browsing it self look and feel smoother in Safari compared to Google Chrome. Font rendering in Safari feel like font rendering in the rest of macOS. Not always but sometimes the same website has proper fonts in Safari but looks awkward in Chrome for some reason, I dunno why. Safari has proper GUI (especially settings) that feels at home in macOS instead of some weird web-based settings. Safari uses so much less power for the same usage compared to Chrome.
It's just my anecdotal view, but I believe that Chrome might be better for developers, but websites are made for the users, not the developers, and Safari is far superior on that front.

"Safari is the new IE6, stop supporting it and let it die."
I can only assume you never went through the pain that IE6 delivered... It has been some years now but I still get nightmares about it. It literally made me question at one time if I didn't made the wrong choice to focus on web development.
Apple may be dragging its feet when adapting new api stuff, but the situation is by no means comparable as what the situation was with IE6. Not by a million miles.

IE6 wasn't so bad. It could do everything in 2001 that practically every site needs today, and pretty intuitively if you didn't also support other browsers. But dealing with emerging "standards compliant" browser bugs alongside "the de facto standard" IE6 bugs in the same code, and eschewing table layout before CSS was up to the task, that was a nightmare.

"You might not need Safari"
FTFY :)

If you use React and inline styles, you might not need HTML and CSS: https://vimeo.com/116209150
Also, if you want the benefits of inline styles, but need media queries and the like, check out Radium: npm.im/radium

Pretty much what I do. I am also enjoying using Aphrodite [1] these days.
[1] https://github.com/Khan/aphrodite

The biggest pain point with using :target is that location.hash, which powers it, is a single global state variable - which means you can't nest tabs inside tabs, for example.
The slider has the problem that it cannot dynamically size with the container width, and the amount of slider elements has to be known at compiletime (width: n * 100%).
File upload has the nastiness that you can not really independently style the inputbox with the filename and the button. Chrome has input[type="file"]::-webkit-file-upload-button, but I am not aware of a Firefox/IE solution. Also, you cannot combine the input[type="file"]::-webkit-file-upload-button with a general button selector in the same CSS rule, because Firefox doesn't know the ::-webkit-file-upload-button and discards the whole rule as invalid - you have to double declarate your button styles if you want uniform button look in Chrome. And, even on Chrome, you cannot visually separate the inputbox from the button (e.g. I have a 2-col layout, 320px/col and 16px margin, and I only can mess around with width, padding and margin instead of a clean separation).
To the people who whine about SASS: you can ALWAYS write the resulting CSS by hand, it just takes a boatload of manual typing.

Wow at the color picker. Funny that chrome seems to use my windows system color picker.

<input type="color"/>, standard HTML5. It’s not got brilliant support though: http://caniuse.com/#feat=input-color

Wow even the Android browser implements it. IE and Safari are lagging again...
I was surprised to see some Linux-style color picker pop up. It looks a lot like the one GIMP uses. Wonder if Firefox implemented that or they depend on something that does, and in the latter case, what's that dependency?

Yep, pretty hilarious. Also: doesn't really work (returns black always - Win 10).

Does not work for me in Safari :(

Notably doesn't seem to work on iOS.

You might also not need CSS.
Doesn't mean you should bruteforce everything with just one tech. CSS is hard to maintain.

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.

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.

A few days ago a saw a talk about CSS animations with RxJS [0] and the gist about CSS only stuff was something like: "Yes, you can do much with CSS only, but it gets ugly fast."
Often you're better of to do a mix of both, because some things that are very complicated in CSS are two-liners in JavaScript.
[0] https://www.youtube.com/watch?v=lTCukb6Zn3g

> ...because some things that are very complicated in CSS are two-liners in JavaScript
And vice-versa, in modern browsers! Best to have both in your toolbox, definitely.

The site would benefit from displaying browser versions where each of those features is supported à la caniuse.com

CSS is great, and by all means use it, while also being aware that you can build so many functional UI components without the additional dependancy.
Maybe you can include a few lines of utility code, or a mixin, and forgo the requirement. If you're only targeting more modern browsers, you might not need anything more than what the browser ships with.
This site is fully copied from youmightnotneedcss.com, an excellent resource for vanilla CSS created by @somebody and @somebodyelse. But this time, we take a look at the power of modern native HTML and g as well as some of the syntactic sugar of DuJour. Because, you might not need scripts for that task at all! (Note: these methods can all be accessible, but the demos may not be. Please take a moment to test these before using in production)

You might not need (to write any) Javascript, but you might still want modern UX with some AJAX.
I have some good news: http://intercoolerjs.org
You can add AJAX to your application without writing any javascript code, and you'll get to use REST (with real, honest to God HATEOAS) without even thinking about it:
http://intercoolerjs.org/2016/01/18/rescuing-rest.html
http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.ht...

What are the performance implications of using CSS animations versus Javascript? Say, if you were trying to make an application where page animations need to be extremely fast, like under 2ms for an experiment or test.

I believe animations are always faster when you use css instead of doing it with js.

I had always assumed that CSS is faster, till I read your question. A quick search gave me this interesting link - https://css-tricks.com/myth-busting-css-animations-vs-javasc... - check it out!

Thanks for the link, a very informative read... and I've been looking for an answer on this topic for quite a while.

CSS for behaviour = un-scalable non-x-platform big ball of crap
I understand why people try so hard to do without JS, but if you want to implement certain UI features, you're SOL. Either give up on them, or embrace the pain.

Or, you could use JavaScript and do something in 30 seconds rather than fiddling with CSS.
Why do people try so hard not to use tools that make their life easier?
You might not need a car - you can walk. But it makes life easier and it just works!

> Or, you could use JavaScript and do something in 30 seconds rather than fiddling with CSS.
Assuming you're more proficient in JS than CSS ;) With CSS3 I find some animation is easier w/ transitions and keyframes than JS.

Another point of view: an exceptional article by Jenn Schiffer "A Call For Web Developers To Deprecate Their CSS" https://medium.com/cool-code-pal/a-call-for-web-developers-t... - HN Submit here https://news.ycombinator.com/item?id=12691081

Surely that's a parody. If it's not...

I clearly is.
Note the absurd metric (lines and spaces) to justify how the blown-up version is considered to be smaller. Also note that the article consequently talks about "Node code" even though they are talking about client-side JavaScript.
From the article:
#gulp { color : #0000ff; padding : 10px; } This CSS takes up 4 lines, and at least 13 spaces. [...] document.getElementById(‘gulp’).style.color=‘#00f’; document.getElementById(‘gulp’).style.padding=‘10px’; This Node code takes up only 2 lines and there are 0 spaces. Essentially, we are saving lines, spaces, and files (delete your .css documents!).

As a rule of thumb: if it's written by Jenn Schiffer, it's probably satire.
Also, she called CSS "California Style Sheets" and called JS DOM manipulation "Node code".
Also, the header was obviously done in MS Paint.
Also, it's Jenn Schiffer.

That writer is amazing.

One thing I have taken issue with a lot of these different CSS "component" implementations, is the lack of examples on how one would write a good testing suite for these. My first reaction looking at these is not "wow", but more "how can I test this?"
I would honestly be interested in hearing from some people here about how you would go about writing a proper test for these examples. And if the answer is "webdriver screenshotting", I might just shake my head a bit.

> JavaScript is great
I've never heard somebody say that. Can you elaborate?

It's powerful, flexible, supports classical and functional paradigms and can handle input validation and transformation better than most languages with less code.
It's the only reasonable cross platform client/server language which is well supported.

I can say this for (nearly) any dynamic language like python or ruby. Your second statement is plain wrong however. Take clojure for example which compiles to java bytecode and javascript (cljs) seamlessly. You seem to be a victim of the Blub paradox.

The problem with using CSS for animations is that if the UX designers make a minor change to the spec, you might be forced to rip out the whole thing and redo it in JavaScript.

I thew this together a while back if anyone's interested: https://github.com/johnhenry/funwithoutjavascript

If you learn JavaScript, you would be learning an imperative language that shares many features with other languages, and you would be, as a resource, more flexible than if you just use CSS for everything.

JavaScript is overused today, even for stupidest things. If needs to be done in JS, you'll see God knows how many frameworks included. This idea reminded me of: youmightnotneedjquery.com

The keyword in all of these sites is the "YOU MIGHT NOT NEED" not "YOU DON'T NEED".. One could theoretically create youmightnotneeda.website and convey that maybe for what you're doing, a website isn't actually needed at all... Doesn't mean it's gospel and everyone should follow it.

I would like to see more sites that use an uppercase title making it so via CSS so I can copy/paste that without having to copy from the source <title> or be lazy and rewrite.

Many of these make sense, but a few (for eg. 'View Switcher') end up obscuring the logic of what's happening, and are probably better off done in JS.

Also, some of them have major accessibility and usability issues.
The image slider for example can't be paused. There's the CSS property "animation-play-state" which could have been used to do this, but that literally freezes the animation, whereas you typically don't care about the animation but don't want the slider to move on to the next image (i.e. finish the transition, then pause).
And of course depending on which browsers you're targetting, many of these are horrendously broken for most of your users.

Yeah, the slider could have an overlay label that toggles a checkbox, where the slider animated is depending upon a checked property, but then the issue is which image is active... that would get fairly complicated with css only.

These examples are all good but I doubt whether you can really avoid javascript. In reality it's more like you can't avoid javascript if you wanted too.

Neat stuff. One small issue: the lightbox re-opens when I'm using the back button on my mouse (using Chrome), not sure if that's fixable or not?

IMHO unless your site is just showing static content, like a flier or something like that, not using JS will plunge your UX and overall productivity.

It's funny that all the examples previews use CodePen and,
>Codepen requires JavaScript to render the code and preview areas in this view.

These don't work in Safari 10:
- The modal dialog example
- Color picker
- Form validation

And also with IE9. So what's the problem? :))

The problem is public facing websites, and will depend on your userbase.

The problem is that Safari (especially mobile Safari) is actually a current, major browser [0], while IE9 thankfully is not :).
[0] http://gs.statcounter.com/#mobile+tablet-browser-ww-monthly-...

Well done :)! Saved for future reference.

The form validation is really cool!
But why oh why does it not validate before I press submit? Is that a Chrome specific thing?

Either does not work for me in Safari, or I'm missing the result.

Does anyone else find it hilarious that this site doesn't work without Javascript?

I might not, but I need for this page. Otherwise it would work with NoScript.

Uninstall all JavaScript engines from you browser to prove that!

Best of luck making this work across browsers. And even more luck to anybody who uses this, and then has to come back 6 months later to change something.

But I need my site to work in IE9 too.

My very wide-cast idea is this: The last 5 years we've rid ourselves of flash (for the most part) and replaced it with javascript.

Coming up next: You might not need SCSS.

You might not need JavaScript*
* If you hate your users

You might nod near internet, heck, you many not need staying alive, but here we are.
Seriously, after some minimum complexity the ability to create functions and loops its extremely important. As in you don't need a spoon and a knife to feed yourself, but it sure fucking helps.

You can also read the title as: You Might Not Need JavaScript for that specific thing.
If this simplifies the codebase, and gives a more uniform user experience, it's harder to argue against.

I remember a time when the coolest thing you could do with JS was mouse trailing bouncy balls. Since then, a lot changed; one of these is that people see JS as salvation from a special hell that doesn't even exist.
That giant ball JS that is included in most sites is absolute nonsense and is not needed in 99% of the cases. We include complete libraries where is should only be a portion.
I'm aware that this is changing, by "compiled" JS - putting together only the required elements - but usually those still have massive overheads.
In my opinion, you should use the tools for what they are the best for. Provide a static, readable HTML first from a backend code - that will run on anything, anywhere; it's accessible, and you've served the main purpose: serving content^1. If you need, add the styling and the animation with CSS. Only after that add the JS layer, which, in my opinion, should mostly be used for data exchange and change triggering.
^1 There are exceptions, there always are; application within the browser, where the main purpose differs from the content delivery. In certain numbers, such as domains, these are the minority; in actual use, it's a different story.
( Imagine a world where the data exchange is not tied together with JS and that we could but other UIs in front of the backends of webapps.. )

A lot of "you don't need Javascript" articles show a bunch of CSS tricks that look flashy and cool but in reality are brittle, limited, and hard to maintain. There's a fair bit of that here, but props for also pointing out some of the new HTML5 features that may have slipped under people's radars. I was aware of the form validation and I think it's a godsend, but I had no idea there's a native color picker now too.

The site makes no claims as such, but it undermines its own credibility if it uses .js files.
Surely they could have figured a way to do without them.

At the start of the article they do state that you might need javascript. The point was to show off things you can do without javascript, not say that you never need it.

Indeed, a bit funny for a site titled "You Might Not Need JavaScript" to itself use JS.

did you accidentally go to site called youshouldneveruseJS.com? Because I think we were talking about you-MIGHT-not-need-JS.

Of course it doesn't undermine it's own credibility. If you turn off JS you'll see that the site still works. It's progressively enhanced using JS to give you examples of what is shown here.

Reply on news.ycombinator.com