<story><title>Modern Javascript: Everything you missed over the last 10 years (2020)</title><url>https://turriate.com/articles/modern-javascript-everything-you-missed-over-10-years</url></story><parent_chain><item><author>hn_throwaway_99</author><text>Couldn&amp;#x27;t disagree more. I was a Java programmer for my entire career until about 2015 or so when I switched to Node, and shortly thereafter to TypeScript.&lt;p&gt;I&amp;#x27;ve commented this many times before, but having a system where &lt;i&gt;everything&lt;/i&gt; is on the same tech stack (i.e. front end in TypeScript with React, back end with TypeScript on Node) has resulted in gargantuan productivity gains, especially for a small team where it&amp;#x27;s trivial for people to cross front end to back end seamlessly. For contrast, I know many teams with a backend in Python and a frontent in React&amp;#x2F;JS, and I&amp;#x27;ve worked on some teams with that setup. In my opinion it&amp;#x27;s virtually all downside compared to a backend in TS, as Python and TS are quite similar from a web programming perspective (I&amp;#x27;m not referring to Python&amp;#x27;s advantage in data science tooling), so all it basically is is a barrier to your front end folks being able to make small enhancements on the backend quickly.&lt;p&gt;Furthermore, TypeScript is a great language and I find myself being so much more productive in it than I was in Java, especially when it comes to refactoring.&lt;p&gt;JavaScript most definitely has its warts and head scratchers after being around for 25 years, but I feel like most of these oddities (truthy&amp;#x2F;falsey, typeof null === &amp;#x27;object&amp;#x27;, undefined vs. null, etc.) can be learned in an hour and written on a half page.</text></item><item><author>DrFell</author><text>JavaScript is a great browser scripting language because it&amp;#x27;s the only browser scripting language.  That&amp;#x27;s a whole realm of good times, and people can and should go nuts with it there.&lt;p&gt;The problem started a decade or so ago with Node.  Too many people only learn JavaScript, become psychologically dependent on it, and they all collectively took it too far outside of a browser.&lt;p&gt;ECMAScript is a general purpose standard, but it was invented retroactively.  Node is not ECMAScript in a server-side ECMAScript engine, it&amp;#x27;s JavaScript in a browser JavaScript engine.  That&amp;#x27;s just too much of a force fit, and has wasted too much potential for me to say anything positive about it.</text></item></parent_chain><comment><author>inopinatus</author><text>If you’ve mainly worked in TS then it explains the blind spot, because JavaScript is chock full of awful missteps built up over the years. There’s a reason my copy of “JavaScript: The Good Parts” is extremely slim next to its sibling, “JavaScript: The Definitive Guide”.&lt;p&gt;So you’ve come to it at a time when the syntax and capabilities have a popular subset that actually starts to fulfil the early promise. And yet, despite the article above, one may still be enormously critical of the anemic and inconsistent standard library, and don’t even get me started on the horrifying dependency shitshow of the node ecosystem that cripples maintainability of anything over 18 months old.&lt;p&gt;Just because we’re all holed up in the throne room, doesn’t mean there aren’t monsters still roaming the sewers, just a few levels down.&lt;p&gt;As for isomorphic code, I strongly encourage my competitors to write backend code in the same fashion and the same breath as the front-end, because the resulting tight coupling and special-case-driven technical debt makes them easy to outmanoeuvre when markets shift. And if they’re reading this then please also consider microservices, graphql,
and nosql data stores whilst you’re at it, for the same great reasons.</text></comment>
<story><title>Modern Javascript: Everything you missed over the last 10 years (2020)</title><url>https://turriate.com/articles/modern-javascript-everything-you-missed-over-10-years</url></story><parent_chain><item><author>hn_throwaway_99</author><text>Couldn&amp;#x27;t disagree more. I was a Java programmer for my entire career until about 2015 or so when I switched to Node, and shortly thereafter to TypeScript.&lt;p&gt;I&amp;#x27;ve commented this many times before, but having a system where &lt;i&gt;everything&lt;/i&gt; is on the same tech stack (i.e. front end in TypeScript with React, back end with TypeScript on Node) has resulted in gargantuan productivity gains, especially for a small team where it&amp;#x27;s trivial for people to cross front end to back end seamlessly. For contrast, I know many teams with a backend in Python and a frontent in React&amp;#x2F;JS, and I&amp;#x27;ve worked on some teams with that setup. In my opinion it&amp;#x27;s virtually all downside compared to a backend in TS, as Python and TS are quite similar from a web programming perspective (I&amp;#x27;m not referring to Python&amp;#x27;s advantage in data science tooling), so all it basically is is a barrier to your front end folks being able to make small enhancements on the backend quickly.&lt;p&gt;Furthermore, TypeScript is a great language and I find myself being so much more productive in it than I was in Java, especially when it comes to refactoring.&lt;p&gt;JavaScript most definitely has its warts and head scratchers after being around for 25 years, but I feel like most of these oddities (truthy&amp;#x2F;falsey, typeof null === &amp;#x27;object&amp;#x27;, undefined vs. null, etc.) can be learned in an hour and written on a half page.</text></item><item><author>DrFell</author><text>JavaScript is a great browser scripting language because it&amp;#x27;s the only browser scripting language.  That&amp;#x27;s a whole realm of good times, and people can and should go nuts with it there.&lt;p&gt;The problem started a decade or so ago with Node.  Too many people only learn JavaScript, become psychologically dependent on it, and they all collectively took it too far outside of a browser.&lt;p&gt;ECMAScript is a general purpose standard, but it was invented retroactively.  Node is not ECMAScript in a server-side ECMAScript engine, it&amp;#x27;s JavaScript in a browser JavaScript engine.  That&amp;#x27;s just too much of a force fit, and has wasted too much potential for me to say anything positive about it.</text></item></parent_chain><comment><author>sillyquiet</author><text>I agree with this - EXCEPT:&lt;p&gt;In a backend where you need a heavy-duty, multithreaded process to handle long-lived computations, node is &lt;i&gt;probably&lt;/i&gt; not the way to go unless you want to pay for all the extra instances you&amp;#x27;d need for the same amount of load.  In my experience, for example, a java-based graphQL server (that spawned multiple connections to various services) needed much much less in the way of resources than the node equivalent serving the same amount of traffic  - AND the latencies were generally much better with the java server, depending on the size of the JSON payloads that it was handling.&lt;p&gt;All that being said, you can certainly architect your way out of that problem and I imagine a relatively small percentages of web applications even HAVE that problem.</text></comment>