141–150 of 195 posts
The HTTP request for voting should be a POST request, not a GET request, since it changes state. So both the JS hack involving an image and the non-JS fallback are broken. The JS function should use XHR, and I guess the non-JS fallback should be a form with an image button, not a link.
This code is simple, works reliably and has done so for a long time with no changes. That seems like the opposite of broken to me
I see a lot of comments here about how not having js on the page is a great thing and lets get back to the old days. Lets be frank here, HN's UI is not good. At the very least it needs collapsible comments and responsiveness to mobile. The fact that HN is a success is despite its bad UI, or maybe because of the many HN readers out there that fix all the broken stuff on the page. While js on sites have surely overgrow…
HN's design is fantastic - it is totally perfect for its function. Collapsible comments are a pig to use. HN looks and works great on mobile now (it didn't used to but they did a redesign in the last few months). Downvoters do you care to explain why you disagree?
Collapsible comments are still, I think, the minimum needed to make HN usable, in long threads it just becomes impossible to find or follow comments.
I see a lot of comments here about how not having js on the page is a great thing and lets get back to the old days. Lets be frank here, HN's UI is not good. At the very least it needs collapsible comments and responsiveness to mobile. The fact that HN is a success is despite its bad UI, or maybe because of the many HN readers out there that fix all the broken stuff on the page. While js on sites have surely overgrow…
HN's design is fantastic - it is totally perfect for its function. Collapsible comments are a pig to use. HN looks and works great on mobile now (it didn't used to but they did a redesign in the last few months). Downvoters do you care to explain why you disagree?
For the record, after the redesign the comments looks worse on Windows Phone. I know, no one gives a damn about WP, but a "proper" mobile redesign would work on every browser.
In my honest opinion, the only possibility browser vendors should disable these days is the possibility to turn JS off.
Earlier quoted context omitted.
HN's design is fantastic - it is totally perfect for its function. Collapsible comments are a pig to use. HN looks and works great on mobile now (it didn't used to but they did a redesign in the last few months). Downvoters do you care to explain why you disagree?
I didn't down-vote you, but "collapsible comments are a pig to use" isn't really a statement I can get behind, nor a statement with any real value (what does "a pig to use" mean, practically?) I use a (slightly modified) Chrome plugin to clean up HN's styling to make it more readable. Most importantly it adds collapsable comments, without which I would enjoy HN much less. Collapsable comments makes it easy to tell wh…
Disclosure I use no script and am very happy that HN works without any javascript.
Practically I find collapsible comments highly annoying in every case I've seen them used. This is probably because they seem to either (1) require javascript, or (2) require page reloads, or (3) both.
In the case of HN, dang et al do a good job of detaching irrelevant comments.
I guess that collapsible comments should be one of those optional features that could be available with javascript but gracefully degrade to showing the full tree without.
Earlier quoted context omitted.
HN's design is fantastic - it is totally perfect for its function. Collapsible comments are a pig to use. HN looks and works great on mobile now (it didn't used to but they did a redesign in the last few months). Downvoters do you care to explain why you disagree?
> HN looks and works great on mobile now (it didn't used to but they did a redesign in the last few months). For the record, after the redesign the comments looks worse on Windows Phone. I know, no one gives a damn about WP, but a "proper" mobile redesign would work on every browser.
Earlier quoted context omitted.
For the majority of cases that I've seen, these arguments are simply excuses to avoid doing real work. It's way more fun to decide whether your amazingly awesome Unicorn startup is going to use React or Angular, or Express vs. Rails, or whatever than it is to actually go through the hard work of building a customer base and making money.
Would love to see "Enterprise HN" with Node and React and Redux (with server-side rendering), and how it compares (whether horribly or awesomely).
Not exactly any of these technologies, but it is using more javascript at least. I think the example is pretty awesome actually.
Earlier quoted context omitted.
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 carri…
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.
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.