[nathancahill]

Lol. For hiding a voting arrow after it's clicked. Yes, you're right. You don't need any of that stuff. But if you were to write an entire app in the style of those two functions, things would fall apart. That's not even a hypothetical, it's been proven over and over again that it doesn't work.

How is everyone agreeing with you? Is there that much JS fatigue that we're looking at the equivalent of a horse-drawn carriage, and saying wow, I wish things were as simple as they were back then?

[BillinghamJ]

I think the point is that there's actually little wrong with using standard HTML forms and hyperlinks most of the time.

There is an increasing trend to move the whole website to the client side to be handled entirely by the JavaScript as a single actual page.

Personally I find most websites work better with a simple round trip to the server to fetch more HTML.

So actually building an entire system in this style isn't out of the realms of possibility at all - you just only write JavaScript for the cases where there is a real legitimate benefit to doing so.

[joshstrange]

> Personally I find most websites work better with a simple round trip to the server to fetch more HTML.

> you just only write JavaScript for the cases where there is a real legitimate benefit to doing so

The snippet above only works because HN is so simple, normally the rule of thumb is if you are going to use JS to change the DOM at all then you need to render it in the first place using JS or else you are double-implementing the render logic and you open yourself up to changing one implementation and not the other. For hiding arrows sure this works but 99.999% of the time it's a very bad idea to use JS to change the dom to a state that the server would otherwise render on a page reload. You may feel that a round trip works better but that's not what users expect or will tolerate most of the time. That kind of thinking feels very close to people who think CRUD is all you need to build an app. Sure you can build an app with just that but thinks break down very quickly.

[rimantas]

JS fatiques starts where web pages (not web apps) start to depend on thousands of kilobytes of javascript. Now the default thinking is along the lines "I am starting a new project, I will use angular", instead of some analysis what kind of project this is, how much JS is needed and what is appropriate.

[grrowl]

I've started chiding those at work who preemptively implement features before they're required, and not scoped. Commit the simplest code that will do the job, and if you like, create a ticket for a future sprint with cool new features.

At home, I wait until lack of a feature (like hot reloading) frustrates me, then block out a couple of hours to do it specifically. Otherwise you've got a flashy stack and no product.

[kylemathews]

>horse-drawn carriage

That code is more the equivalent of a digging stick. React is used to build horse-drawn carriages. I'm eagerly awaiting the JS framework that'll let me build cars.

[gordonzhu]

Nowhere did I tell people to write an entire app in the style of hide and vote like you're implying.

In my comparisons I mention a lot of choices people might make, like Angular vs. Ember vs. React that are ultimately meaningless to the success of your product. I think this is what's resonating with a lot of people.

[marssaxman]

How would things fall apart, exactly? On my home machine I browse with NoScript turned on by default, and it's rare that I find a site which is broken badly enough to notice which I still care about strongly enough that I bother clicking "allow". I don't think that most of what people do with JavaScript in the browser needs to be done at all if you filter the motivations of investors and advertisers out of the picture.

[snowwrestler]

> Is there that much JS fatigue that we're looking at the equivalent of a horse-drawn carriage, and saying wow, I wish things were as simple as they were back then?

Make Javascript Great Again! (TM)