7 ms·

What's most fascinating to me about this isn't the simplicity, it's that this code has lived for so long with almost no changes. It's a great counter-example t

What's most fascinating to me about this isn't the simplicity, it's that this code has lived for so long with almost no changes. It's a great counter-example to all the recent articles about JavaScript fatigue. It's good for us to see real examples of sites that aren't caught up in the framework of the week hype. At the end of the day we're trying to make stuff that works. ES5 vs ES6, React vs Angular vs. Ember vs. Aurelia, Angular 1 vs Angular 2, even server rendered templates vs. single page apps - it all matters a lot less than we think.

aaronbrethorst 11y ago
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.
- gordonzhu 11y ago
  YES! totally agree For a subset of us, framework authors, open source contributors, etc. It's very useful to keep up to date on the latest trends. For example, the Angular team has borrowed techniques from React. It helps for them to keep up with things. For people like me though, let's be honest. I don't need to do the latest thing.
  - pixel67 11y ago
    Funny you said that, I was looking into ng2 and they've borrowed a few things from the React community. It's all good, I'm glad to see that "framework A is better than framework B" mentality die away and everyone just uses the right tool for the right job.
- percept 11y ago
  The problem (from my perspective) is that the job market follows. It's good at that--always following.
  - zeemonkee3 11y ago
    And so we use React in our project (even if it makes no sense to) because then we can put it in our resume. And thereby contribute to the problem.
- xupybd 11y ago
  Totally agree. One problem I find arises from this is that there are no boring workhorses. Time and time again I need boring crud screens, for the admin side of applications, but there is no easy default to choose. ExtJS tends to do the trick, but it's not cheap.
  - vmorgulis 11y ago
    > Time and time again I need boring crud screens, for the admin side of applications, but there is no easy default to choose. crud is often a feature of frameworks. crud should be an external tool like documention tools (doxygen...).
- zappo2938 11y ago
  This week's JavaScript flavor special is vanilla.
- catshirt 11y ago
  maintaining software is a real thing. for the majority of cases i've seen, these arguments are to save developers time and the company money. my gut & feelies tell me there is truth to "it doesn't really matter what technologies you use" but my brain and experience tell me that is objectively false.
  - nostrademons 11y ago
    The reason "it doesn't matter what technologies you use" is because successful software gets rewritten multiple times anyway. It matters a lot eventually, but having an "eventually" to worry about is a nice problem to have. (There's also a big perspective difference between being an entrepreneur writing initial code for a project vs. an engineer hired to maintain & grow that code. Code quality, architecture, and technology choice matters a lot to an engineer who will be working with it directly. It matters a lot less to a business that can swap out engineers until they find ones who enjoy working on that codebase. The fact that you even have money to hire engineers usually indicates that the existing code is getting the job done. The business only gets screwed when the code quality is so bad that nobody can make sense of it, and the environment changes in a way that requires modifications.)
    - catshirt 11y ago
      but, there are many instances where software would not get rewritten with proper technical foresight in the first place. i take your point none the less- there are contexts where it doesn't matter.
- daxfohl 11y ago
  Would love to see "Enterprise HN" with Node and React and Redux (with server-side rendering), and how it compares (whether horribly or awesomely).
  - sundarurfriend 11y ago
    > and how it compares (whether horribly or awesomely). Given only the tech stack, it can go either way, depending on whether the implementor takes the easy, lazy route or actually puts some thought and hardwork into it. The problem is, as per good old Sturgeon's law, 90% of sites take the lazy route, and end up with tangled monstrosities that look like offerings to the Flying Sphaghetti Monster. (Also, it's interesting how quickly 'cool new tech' can become 'Enterprise' shudder when it's widely abused and misused.)
    - ethbro 11y ago
      > Also, it's interesting how quickly 'cool new tech' can become 'Enterprise' shudder when it's widely abused and misused Is this the hipster corollary to coding? Sure, Java was cool when only 100 people were using it...
  - Ezhik 11y ago
    Well, there's Designer News...
  - kriro 11y ago
    That's already a pretty "modern" enterprise stack. I'd expect enterprise HN to run on Java EE (with an Oracle DB of course) :D
  - em500 11y ago
    Have you seen hn.algolia.com?
  - staticelf 11y ago
    https://vuejs.github.io/vue-hackernews/#!/news/1 https://vuejs.github.io/vue-hackernews/#!/news/1 Not exactly any of these technologies, but it is using more javascript at least. I think the example is pretty awesome actually.
welder 11y ago
+1 times infinity
deleted 11y ago
[deleted]
ignoramous 11y ago
The img.src trick is used by google-analytics to log metrics cross-domain as well. Pretty neat trick. Another thing to note is the "RESTful" nature of the links embed in the page. I guess its some form of HMAC with SHA1 + Nonce that authenticates requests for the server. It differs for every href. Elegant. auth=311110b7ef0f268cafa8616afcbfcec8d977111e
- deleted 11y ago
  [deleted]
nathancahill 11y ago
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?
- snowwrestler 11y ago
  > 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)
- kylemathews 11y ago
  >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.
- BillinghamJ 11y ago
  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 11y ago
    > 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.

aaronbrethorst 11y ago

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.

gordonzhu 11y ago
YES! totally agree For a subset of us, framework authors, open source contributors, etc. It's very useful to keep up to date on the latest trends. For example, the Angular team has borrowed techniques from React. It helps for them to keep up with things. For people like me though, let's be honest. I don't need to do the latest thing.
- pixel67 11y ago
  Funny you said that, I was looking into ng2 and they've borrowed a few things from the React community. It's all good, I'm glad to see that "framework A is better than framework B" mentality die away and everyone just uses the right tool for the right job.
percept 11y ago
The problem (from my perspective) is that the job market follows. It's good at that--always following.
- zeemonkee3 11y ago
  And so we use React in our project (even if it makes no sense to) because then we can put it in our resume. And thereby contribute to the problem.
xupybd 11y ago
Totally agree. One problem I find arises from this is that there are no boring workhorses. Time and time again I need boring crud screens, for the admin side of applications, but there is no easy default to choose. ExtJS tends to do the trick, but it's not cheap.
- vmorgulis 11y ago
  > Time and time again I need boring crud screens, for the admin side of applications, but there is no easy default to choose. crud is often a feature of frameworks. crud should be an external tool like documention tools (doxygen...).
zappo2938 11y ago
This week's JavaScript flavor special is vanilla.
catshirt 11y ago
maintaining software is a real thing. for the majority of cases i've seen, these arguments are to save developers time and the company money. my gut & feelies tell me there is truth to "it doesn't really matter what technologies you use" but my brain and experience tell me that is objectively false.
- nostrademons 11y ago
  The reason "it doesn't matter what technologies you use" is because successful software gets rewritten multiple times anyway. It matters a lot eventually, but having an "eventually" to worry about is a nice problem to have. (There's also a big perspective difference between being an entrepreneur writing initial code for a project vs. an engineer hired to maintain & grow that code. Code quality, architecture, and technology choice matters a lot to an engineer who will be working with it directly. It matters a lot less to a business that can swap out engineers until they find ones who enjoy working on that codebase. The fact that you even have money to hire engineers usually indicates that the existing code is getting the job done. The business only gets screwed when the code quality is so bad that nobody can make sense of it, and the environment changes in a way that requires modifications.)
  - catshirt 11y ago
    but, there are many instances where software would not get rewritten with proper technical foresight in the first place. i take your point none the less- there are contexts where it doesn't matter.
daxfohl 11y ago
Would love to see "Enterprise HN" with Node and React and Redux (with server-side rendering), and how it compares (whether horribly or awesomely).
- sundarurfriend 11y ago
  > and how it compares (whether horribly or awesomely). Given only the tech stack, it can go either way, depending on whether the implementor takes the easy, lazy route or actually puts some thought and hardwork into it. The problem is, as per good old Sturgeon's law, 90% of sites take the lazy route, and end up with tangled monstrosities that look like offerings to the Flying Sphaghetti Monster. (Also, it's interesting how quickly 'cool new tech' can become 'Enterprise' shudder when it's widely abused and misused.)
  - ethbro 11y ago
    > Also, it's interesting how quickly 'cool new tech' can become 'Enterprise' shudder when it's widely abused and misused Is this the hipster corollary to coding? Sure, Java was cool when only 100 people were using it...
- Ezhik 11y ago
  Well, there's Designer News...
- kriro 11y ago
  That's already a pretty "modern" enterprise stack. I'd expect enterprise HN to run on Java EE (with an Oracle DB of course) :D
- em500 11y ago
  Have you seen hn.algolia.com?
- staticelf 11y ago
  https://vuejs.github.io/vue-hackernews/#!/news/1 https://vuejs.github.io/vue-hackernews/#!/news/1 Not exactly any of these technologies, but it is using more javascript at least. I think the example is pretty awesome actually.

welder 11y ago

+1 times infinity

deleted 11y ago

[deleted]

ignoramous 11y ago

The img.src trick is used by google-analytics to log metrics cross-domain as well. Pretty neat trick. Another thing to note is the "RESTful" nature of the links embed in the page. I guess its some form of HMAC with SHA1 + Nonce that authenticates requests for the server. It differs for every href. Elegant. auth=311110b7ef0f268cafa8616afcbfcec8d977111e

deleted 11y ago
[deleted]

nathancahill 11y ago

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?

snowwrestler 11y ago
> 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)
kylemathews 11y ago
>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.
BillinghamJ 11y ago
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 11y ago
  > 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.