Hacker News Reader

Comment by orheep | Hacker News Reader

I see the point but noone in their right mind would write the javascript like that. When written better it's a good amount shorter than the React solution.

http://pastebin.com/wbGZZs7U

View on HN

I totally agree, in fact I'm going to link this :) The point I wanted to make is that every feature requires a bit of refactoring like this, whereas React puts some structure.

Makes more sense to me to have the "Tweet" button enabled by default and disabled on load by JS. If there's an issue with the JS or it's disabled in the browser or whatever, the button should still work (with server side logic to catch empty Tweets). Right now, if the JS doesn't load you can't Tweet at all.

Just a small nitpick I had after thinking about the reasoning behind why the OP had disabled the button in JS rather than the HTML in the first place.

true, but to be fair, you'd probably also want to introduce variables like $addPhotoBtn, $tweetBtn, $textLengthLbl, etc, to avoid css queries on every keyboard change. That would add to solution length and also introduce a bind-step to avoid stale variables after a dom change.

Also, there's the authors very well-placed point that adding a new feature may lead to css query refactoring, eg. when $("textarea") doesn't cut it. I find html refactorings to be nb 1 cause for breaking progressively enhanced solutions like this one, probably bc I suck at naming elements.

Lastly, it should be noted that this refactored solution does not contain all the features of the final react solution.

Reply on news.ycombinator.com