Hacker News Reader

Comment by DrFell | Hacker News Reader

JavaScript is a great browser scripting language because it's the only browser scripting language. That's a whole realm of good times, and people can and should go nuts with it there.

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.

ECMAScript is a general purpose standard, but it was invented retroactively. Node is not ECMAScript in a server-side ECMAScript engine, it's JavaScript in a browser JavaScript engine. That's just too much of a force fit, and has wasted too much potential for me to say anything positive about it.

View on HN

Couldn'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.

I've commented this many times before, but having a system where everything 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'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/JS, and I've worked on some teams with that setup. In my opinion it's virtually all downside compared to a backend in TS, as Python and TS are quite similar from a web programming perspective (I'm not referring to Python'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.

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.

JavaScript most definitely has its warts and head scratchers after being around for 25 years, but I feel like most of these oddities (truthy/falsey, typeof null === 'object', undefined vs. null, etc.) can be learned in an hour and written on a half page.

Is there any Typescript backend framework as mature as Django?

> Python and TS are quite similar from a web programming perspective (I'm not referring to Python'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.

So on the on hand, the languages are "quite similar", yet it cannot possibly be expected that frontend people learn more than a single language? Something doesn't add up here.

You are interpreting GP’s comment very uncharitably, to the point that it actually becomes a completely incorrect interpretation.

GP is pointing out that it is advantageous to have a single language on both front end and backend. And somehow you arrived at “developers cannot be expected to learn more than one language.”

There ARE big advantages to having the exact same language (as opposed to similar languages) on both client and server, especially in an SPA where you want to render something initially on the server, but then update it using the same logic later on the client.

> GP is pointing out that it is advantageous to have a single language on both front end and backend. And somehow you arrived at “developers cannot be expected to learn more than one language.”

Because he considers it a "barrier" to have to switch between languages to do backend-only changes. Which is a completely different use case than the one you're describing.

For an SPA where you're essentially doing frontend on both ends, yes, that's obviously easier when you're only doing it once.

But that's not the general case, and I'd argue that transitioning between different mental contexts for components you're not regularly touching is always going to be a hurdle to developers, regardless of the language used. Blaming it on the language is an useless red herring.

It's definitely a barrier to have to switch languages. You might be super familiar with Chrome's debugger UI (which is excellent, btw), and feel lost when suddenly getting dropped into IntelliJ's.

Also, what if you just have frontend developers who straight up don't know Java or vice versa? I don't see how having a shared language could ever be a bad thing.

I feel like switching languages adds extra friction too. Switching contexts is still a hurdle, but using the same language can make the hurdle shorter.

Having to write the same logic twice in two languages, and then making sure both implementations behave the same way. I don’t know if I’d use the word “barrier”, it’s certainly a significant pain in the ass.

The classic example is of course validation, but plenty of other places it can come up.

Perhaps I'm overthinking things and HTML does this naturally, but is there something for rendering that is what Swagger/OpenAPI is to APIs? Some way of specifying HTML that can be both rendered (and read back for inputs) by multiple implementations.

In theory, that's what template languages like jinja, liquid and twig are for.

But as you can see, there's n+1 standards for it, and in practice none of them has a Javascript implementation good enough for productive use. So it's more a "what if?" scenario, had Angular/React/Vue not taken off.

Learning is great. It expands horizons, potential, and current capabilities. Learning is not producing though. Learning is a cost center. If you want to increase productivity start by minimizing required learning. That exchange is called usability.

Interesting phrasing, I like it. But you can also reduce the cost by making learning easier, whether with good interfaces or naming, or just good docs

> Is there any Typescript backend framework as mature as Django?

No TS framework is as old as Django, and if you're looking for "Django for TS" you won't find exactly that, but Next.js is the current reigning champion for server-side frameworks right now, according to the popular "State of JavaScript" survey https://2020.stateofjs.com/en-US/technologies/back-end-frame... Next is a "both-side" framework, allowing it to do stuff you just can't do in Django.

If you want something much thinner than Next (and thus much thinner than Django), there's Express.

> yet it cannot possibly be expected that frontend people learn more than a single language?

The problem isn't learning two languages, it's interop between two languages.

> No TS framework is as old as Django, and if you're looking for "Django for TS" you won't find exactly that, but Next.js is the current reigning champion for server-side frameworks right now, according to the popular "State of JavaScript" survey https://2020.stateofjs.com/en-US/technologies/back-end-frame...

So by that graph, it has a good chance of being entirely deprecated and/or abandoned in the next 3 years, what a wonderful foundation for a backend.

And it doesn't even have any support for an ORM? Neither does Express? Having to hand-write every single query and migration like it's 1999 again is hardly the cutting edge of IT stacks…

> The problem isn't learning two languages, it's interop between two languages.

How so?

Regarding ORM, it's typically paired with Sequelize or Prisma. (I'm personally using the latter.) I've built Django apps in the past (it's actually how I learned Python in the 2.5 days), but what's nice about Node/TS is that the frameworks are more loosely coupled so you can pick/choose your best components. For example, while I mentioned the ORMs above, you can even go one step further and use a backend headless CMS like Strapi, which will get you the ORM + admin interface that you'd get from Django models.

> what's nice about Node/TS is that the frameworks are more loosely coupled so you can pick/choose your best components.

For about two weeks, then one of them becomes deprecated again and you have to migrate everything all over again…

This isn't really true though. There are plenty of open-source modules in Node which were released more than 5 years ago and are still in use today. People only move to new ones, when they are clearly better. What exactly is wrong with that?

> There are plenty of open-source modules in Node which were released more than 5 years ago and are still in use today.

And how stable was their API over the last five years? It hardly counts if over 5 years the APIs change so much they're basically different libraries at the end.

Django's code churn for even complex projects is on the order of single digit hours per year at worst, the remaining 99.99% of time can go into delivering things customers care about.

I can't say I've seen that sort of stability in anything Javascript-related, apart from maybe jQuery projects. (Which of course have their own problems because jQuery is the wrong abstraction usually.)

On the backend, Express has had a very stable API for 5+ years. On the frontend, React has. However, stable or not there's nothing that competes with Django/Rails/Laravel in the Node ecosystem.

I'm not sure React is the best example. Although the library is backward compatible in theory, it doesn't much matter in practice because almost the entire ecosystem switched to a radically different core abstraction a couple of years ago.

There's nothing stopping you from using class component as opposed to the new functional component though. It works completely fine, as it ever was, and in fact, I know a lot of teams are still using it. The API on that front is indeed surprisingly stable. Furthermore, there haven't been any shiny new thing since hooks, and it starting to feel like boring old tech. It's not the cool kid on the block anymore.

There's nothing stopping you from doing it, but part of the reason a library like React achieves such widespread use is the ecosystem that builds up around it, and if everyone else is using hooks to expose whatever functionality they're building, you are now excluded from the benefits of all of that work.

Well sure, if you don't adopt the new technology then you don't get the benefits of the new technology. But that's true it literally every ecosystem. If you don't upgrade to a C11 compiler, then you can't use libraries using C11 features either.

But in both cases, there's little reason not to upgrade because your old code will still work fine on the new version. And indeed you're free to continue writing new code in the "old" style. Adding additional API surface after 3 years while continuing to maintain and support the old API is hardly unstable!

But that's true it literally every ecosystem. If you don't upgrade to a C11 compiler, then you can't use libraries using C11 features either.

I don't think the situations are equivalent, at least not to any meaningful degree.

With C11, your old code continued to work, your old libraries continued to work, your tools probably required at most minor configuration changes, your new code and libraries were still mostly the same style even if you also used some of the new features, and anyone you were working with who knew one version could very quickly and easily adapt to the other.

With React, you can stop after your old code and libraries continuing to work, except that you might not be able to use those old libraries from new code any more and they might no longer be getting much ongoing development. You still effectively have to learn a whole new version of React API, and find your way around a whole new ecosystem of libraries and tools that operate alongside that new API. So does everyone you're working with. You have the backward compatibility, but only by having two completely different coding styles in the same code base, and if you're hiring new people who only know the new API and ecosystem, they now have to learn the old one as well to work on your code.

If the original point was about whether tools are stable for a long time so you don't have to worry about making major changes or learning big new things, one of these situations is not like the other.

The fact that you can have different coding styles and APIs in your project and it will work is proof that it is backward compatible.

And, this is to be expected, because the React Core team prioritises backwards compatibility as one of the key features of the library. See: https://reactjs.org/docs/faq-versioning.html#commitment-to-s...

This is why features and deprecations are announced years in advance of the changes and that when code to support a feature is eventually removed they produce a compatability polyfill in order that teams do not need to do big-bang rewrites (e.g. https://github.com/reactjs/react-lifecycles-compat).

Maybe you disagree with what backwards compatability is? It doesn't mean that new features are backported to old verions of React or that the recommended syntax/API never changes. It does mean that you can rely on modern versions of React being able to run code you wrote 5+ years ago.

I find complaints about the stability of JavaScript kind of ridiculous. Everybody is literally still transpiling down into ES5 (2009) and most only dropped IE11 this year (2013), the main libraries/frameworks tend to make expert use of semver, polyfill old APIs and release codemods to automaticallly perform syntax upgrades. I'm interested whether there are any programming language ecosystems that have done this better? As far as I can see Python 2 to 3 caused hard rewrites, etc.

The fact that you can have different coding styles and APIs in your project and it will work is proof that it is backward compatible.

I don't think anyone is disputing that React is still backward compatible with the old API. The point is that there is a difference between having two APIs that both still work and having one stable API.

Backward compatibility is implied if your API is stable, but that's only one aspect of stability and there are many other practical questions. Will documentation and tutorials from a few years ago still be relevant? Will someone joining your team need to learn anything different before they can be productive? Will other libraries you have used previously that integrate with React still work with your new code? Will new libraries you might want to use today that integrate with React work with your existing code that uses the old React API?

Having multiple integrations with different APIs or different libraries to do the same job is a form of technical debt, and sometimes it can become quite expensive.

Well, there are a lot of things you've said there that aren't quite the whole story.

A lot of modern build processes don't just target vanilla ES5 any more. They'll target something like the most recent two versions of the evergreen browsers and any specific minimum versions of other browsers they need for their particular market. This produces more efficient production code because all major browsers now support much more recent JS natively.

There are also some modern JS APIs that you can't completely polyfill. You have to target a runtime environment that provides real support for those.

Semver is great when it works, but when your culture is to have absurdly deep trees of nested dependencies with hundreds or even thousands of indirect packages involved, things still break often enough to notice.

Major libraries might provide automatic codemods for straightforward, unambiguous changes. However, sometimes you can't divine the original developer intent automatically. Then some manual intervention is required.

I'm interested whether there are any programming language ecosystems that have done this better? As far as I can see Python 2 to 3 caused hard rewrites, etc.

Almost all of them, in my experience. JS, including the ecosystem and culture around it, has by far the worst stability story of any major language I have used.

This is partly a cultural problem. Writing code to last simply isn't part of the mindset or skill set of many people working in web development.

Many tools and libraries we rely on for the most vital functionality are FOSS with at most a small team working on them or maybe just one single person. That means even really successful and widely used projects can easily fade away as those behind them lose interest.

Much of what is built on top is written by people being paid astronomical amounts of money who will job hop in less than two years for even greater astronomical amounts of money. They might make it to senior/staff levels a few years into their careers or maybe become the CTO at a startup, never having either built a new product from scratch or maintained one for 5+ years to see where those decisions they made earlier on come back to haunt them. Then those people are the ones leading and mentoring the next generation of newbies working in the JS community, and the cycle continues.

It's also partly a technical problem. The language doesn't provide much to help with building large-scale software and maintaining it over the long term. What it does provide is relatively recent. The tooling is relatively weak, well behind the state of the art for many other popular languages, which in turn lag the more research-focussed languages where radically different ideas get explored.

I believe a big factor in these cultural and technical problems is the way that you can just change your code and push out a new version any time you want since you have complete control over the servers hosting it. It has also become the norm to depend on online APIs provided by other parties who can do the same. This means concepts like managed releases and support lifetimes and stable interfaces are given less importance.

In striking contrast to all of that, there is code I worked on professionally a couple of decades ago that was written in C and would still compile and run on any modern platform with few or no changes. Likewise, there are professionally developed libraries in ecosystems like Java and .Net, which are platforms widely used for large-scale enterprise software development, that have been around for a decade or more and are still as active as ever. Even in Python, the 2-to-3 shift took place over about a decade, taking the community and the tools and libraries along with it. The language is still mostly compatible with Python 2 code, and there were tools to mechanically update code for most of the main breaking changes, so many of the popular libraries from the Python 2 era are still available and working fine with Python 3.

The only other language I've used where instability was as awful as JS world is Haskell, and that's obviously not a mainstream language in the same sense. It's mostly used by a community who are very open to trying big new ideas and changing how they work frequently, and that's part of its attraction to those people and also probably a reason that ideas from Haskell sometimes drift into more popular use over time but the language itself remains an eccentric choice for production use.

  > The point is that there is a difference between having
  > two APIs that both still work and having one stable API.

This is the direct effect of high levels of backwards compatability. You can't change APIs; you have to create new APIs and then deprecate previous APIs. That's the only way of avoiding a breaking change (other than never changing something and endlessly layering leaky abstractions on top of it).

  > Having multiple integrations with different APIs or
  > different libraries to do the same job is a form of 
  > technical debt, and sometimes it can become quite 
  > expensive.

I disagree. If you don't need to do any work to something it has zero cost. Write tests to its behavior and it can be a blackbox to your team until you truly need to deal with it.

  > A lot of modern build processes don't just target
  > vanilla ES5 any more. They'll target something like 
  > the most recent two versions of the evergreen browsers
  > and any specific minimum versions of other browsers
  > they need for their particular market.

This isn't mainstream yet. Until very recently the majority of companies were targetting IE 11. A lot of companies changed this in 2020 (Microsoft, Atlassian, etc), and additionally due to Node finally supporting ESM and the release of Snowpack and Vite, many open-source developers are finally targetting something greater than ES5. But you're wrong to imply that it's the norm.

  > There are also some modern JS APIs that you can't completely polyfill.

People tended not to use these due to needing to support older browsers. But sometimes APIs could be partially polyfilled to an extent that was sufficient enough to use them (like `Proxy` with `proxy-polyfill`).

  > Almost all of them, in my experience. JS, including the ecosystem and 
  > culture around it, has by far the worst stability story of any major language
  > I have used.

OK, yeah, I'm not seeing this at all. For a start, TC39 has rules against breaking the web (see "One JavaScript", etc: https://tc39wiki.calculist.org/about/faq/). It's due to this choice that we still have mistakes like `typeof null === 'object'`...

Also, I don't think your opinion has wide acceptance within the industry. See comments by Kyle Simpson (https://twitter.com/getify/status/1195362162857910273) or even Yaron Minsky decrying their inability to fix old mistakes (https://twitter.com/yminsky/status/1067926815992410113).

Of course, TC39 is not perfect and there are very rare occasions that minor incompatabilities are introduced (https://tc39.es/ecma262/#sec-additions-and-changes-that-intr...) but "the worst stability story of any major language" is quite an absurd statement if you consider the minutae that has made that list.

  > [...] Much of what is built on top is written by people being paid astronomical amounts 
  > of money who will job hop in less than two years for even greater astronomical amounts
  > of money.

This is all true. But most of the products these people create are also being replaced every 2 years so it's not as big an issue as you think it is. We're able to go back to projects written in JavaScript 10+ years ago and they work in newer browsers, but the majority of projects are thrown away or rewritten for completely different reasons before this point (normally employee attrition on smaller projects is enough to lose the knowledge required to fix bugs or add features and so companies rewrite to get back that understanding).

I guess a form of backwards compatability we don't have is the ability to upgrade a tooling dependency through multiple breaking changes and not find out that the configuration system has been completely overhauled. That is unfortunate. But the code will build/run when you pull it down the first time from your repository. If you then decide to make upgrades to use new tooling you have to know what you're doing -- tooling upgrades are confusing.

  > The language doesn't provide much to help with building large-scale software and 
  > maintaining it over the long term. What it does provide is relatively recent.
  > The tooling is relatively weak, well behind the state of the art for many other
  > popular languages, which in turn lag the more research-focussed languages where
  > radically different ideas get explored.

I disagree. It has testing frameworks, it has automated code formatters, it has linters, it has type checkers, it has tools to automate rewriting 10,000s of lines of code via the AST, it has tools to automate producing changelogs, it has tools to visualise dependencies, it has tools to improve the performance of scaling a monorepo, etc. Some of these tools are significantly worse in other programming language ecosystems or do not even exist.

  > Even in Python, the 2-to-3 shift took place over about a decade, taking the community
  > and the tools and libraries along with it.

Are you trying to tell me that a breaking change that was so bad that it took almost a decade for the community to complete is something that we should aspire to?

I don't think that JavaScript has serious backwards compatability issues at all. Certainly not in the language. Generally not in the major libraries (React, etc). It perhaps has some issues in breaking changes to the tooling which could make upgrades very confusing (e.g. Babel changed how configuration worked a few times and this was painful due to obscure error messages).

On the other hand, I will say this: it is true that the open-source JavaScript community is high on modularisation, scrappy/innovative and prone to releasing something for fun and then ghosting their consumers. In situations where the quality of the package was high enough that you don't need to change anything this presents no issues, but sometimes when you've used a package with a broad vision that the creator has later on bowed out of fulfilling or which has later on produced lots of bugs, that then leads to engineers swapping it out for newer, shinier or better maintained (for now) things... That is the 'stability' issue that we tend to have issues with and it's the reason that I (and a small minority of other people) have started to 'vendor' or inline code into our projects. As Tom MacWright recently wrote "One of my golden rules is that you shouldn’t blackbox things you don’t need to. I like to “use dependencies for efficiency, not ignorance.”" (quality article by the way: https://macwright.com/2021/03/11/vendor-by-default.html).

This is the direct effect of high levels of backwards compatability. You can't change APIs; you have to create new APIs and then deprecate previous APIs.

I don't see how that follows at all. You can't make breaking changes to APIs, but it's fine to extend them or even expose different levels of abstraction as long as the underlying model you're using stays consistent and you provide suitable defaults where necessary.

If you don't need to do any work to something it has zero cost.

This is tautological, but if we're talking about a typical web application then you are working with that code, every time you make a new build. It might sit there as an untouched black box for a while, but if it has any kind of external dependencies or it relies on anything that could change about the language, platform or other parts of your own code, then there is always a risk that it will later break, and then you'd better hope you have someone around who still knows how to fix it.

This isn't mainstream yet. Until very recently the majority of companies were targetting IE 11.

You've made several claims like that, but in the absence of data there's no way to know whether you're correct. For example, preset-env has been in production for 3+ years now and had an extended beta/RC phase before that. It's true that it defaults to ES5 if you don't configure it, but the Babel docs explicitly recommend that you do, and it is literally a one-line change in your package.json to do something more modern and efficient based on Browserslist unless you genuinely need that degree of backward compatibility.

Of course, in some cases, even quite recently, you did need that. A relatively small proportion of business customers stuck in the IE11 era could still represent significant revenue at risk if you dropped support. But it will take more than an unsupported assertion to convince me that this has been the norm for most web development for quite some time. At one of my businesses, we've had literally no-one using IE11 visit a B2C web app for years. At another that mostly does outsourced development work, we've excluded IE support contractually for a long time and no client of any size has pushed back in years. There must be many thousands of other small businesses out there like mine, and I have to assume that they have senior devs who sometimes read the docs for the tools they use too.

OK, yeah, I'm not seeing this at all.

I think that's because you persist in interpreting my comments as being about JS itself, when I've tried repeatedly to emphasize that it is the culture and surrounding ecosystem that are the bigger problems. I'm not talking about the technical committees defining the language. I'm talking about the developer experience of using it in production.

On that score, I stand by my earlier comments. After many years of programming professionally, using many different languages, I have yet to find any more flaky ecosystem than JavaScript's other than the deliberately fast-paced world of Haskell. Nothing else even comes close for how much wasted effort I've seen over the years just keeping all the plates spinning so nothing falls off and breaks.

But most of the products these people create are also being replaced every 2 years so it's not as big an issue as you think it is.

Yes, I understand the commercial argument. The bizarre economics in the web dev industry sometimes make throwing entire projects out and rewriting every 2 years affordable. That doesn't mean it's not a horribly unstable environment, which was the original point of contention, nor that disregarding traditional wisdom about the dangers of big rewrites isn't a bad idea. It just means parts of the industry are so rich that they can afford to have a toxic culture where quality is a second-class citizen and the only answer to producing so much unmaintainable junk is exactly what you said. It's much nicer working in other parts of the software industry where what you're producing is expected to work and to last, but sadly it doesn't always pay as well.

It has testing frameworks, it has automated code formatters, it has linters...

And these kinds of things are advanced tooling, in your view? We had those in our IDEs for building desktop software back in the last century. Except they were automating rewriting millions of lines of code on 2000-era PCs, not 10,000 lines of code on 2020-era PCs.

I'm not sure what other popular programming language ecosystems you think don't have these kinds of tools today or have tools significantly worse. But in web development, TS is the current hotness because the developers finally realised that explicit typing is helpful for building and maintaining more than small systems, and not so long ago build tools adopting tree shaking was being heralded as a great advance for reducing the size of builds, and before that we got the radical new concept of a module import/export system so you could write code in more than one file without jumping through crazy hoops, and before that we discovered that immediate mode UIs and declarative specs are a thing. All of these ideas were well known and widely used elsewhere in the programming world much, much earlier.

Are you trying to tell me that a breaking change that was so bad that it took almost a decade for the community to complete is something that we should aspire to?

It took that long because that backward compatibility and stability we've been talking about meant a lot of older projects didn't need to move any sooner. And yes, having a platform where you can write code and it keeps working and the ecosystem still positively supports it for another decade is definitely something we should aspire to.

Generally not in the major libraries (React, etc).

Don't tell that to anyone who uses React Router. Or who builds their app with Webpack. Or Babel, as you mentioned. And again, it's important to note that you only said backward compatibility here. If we're talking about the broader concept of stability then you also have to include high profile libraries like Moment giving way to more modern alternatives because although they still work, they don't lend themselves to modern programming styles or play so nicely with other tools.

These comments are getting long and I suspect we may have to agree to disagree on some of this, but if you haven't worked much on software in other parts of the industry, I encourage you to look at what is considered the norm and acceptable practice in fields where better quality and greater longevity are more highly valued. If we built security libraries or the embedded software controlling industrial machinery the way a lot of online companies build their web apps, we'd be lucky to survive the night.

I'm trying to respond in good faith, even though I feel you unnecessarily resorted to trying to condescend me.

You wrote:

  > there is a difference between two APIs 
  > that both still work and having one
  > stable API.

As I explained, "this is the direct effect of high levels of backwards compatability. You can't change APIs; you have to create new APIs and then deprecate previous APIs."

I thought my point was obvious, but will explain it with more words:

If never making breaking changes to APIs is a strict requirement, all API changes must be additive. That means backwards compatibility entails the existence of more than one API to do the same thing. It seemed like you were insisting that there should be "one stable API" that never needs changes instead of "two APIs that both still work" and this is unrealistic for something that has existed and responded to changes in use for ~25 years.

  > if it has any kind of external 
  > dependencies or it relies on anything
  > that could change about the language, 
  > platform or other parts of your own 
  > code, then there is always a risk that
  > it will later break

This is a useful point. For dependencies that never make breaking changes you will be OK. But if the dependencies you have are likely to change and likely to be upgraded elsewhere in the codebase and potentially might make breaking changes, we should consider them a risk to the project.

I agree that this should be highlighted -- but, in the context of what you were talking about, which was with regards to code that uses old features of React, you are incorrect. As I mentioned to you, compatibility packages exist for all old React lifecycle methods and deprecated patterns. Therefore, by design, you are not being forced to upgrade the patterns in old parts of your codebase.

I am trying to make specific claims about concrete things that I can evidence. The existence of compatability packages for features that have been deprecated for 5 years invalidates a specific argument about needing to upgrade old React code due to changes in the API.

  > You've made several claims like that, 
  > but in the absence of data there's no 
  > way to know whether you're correct. 
  > For example, preset-env has been in 
  > production for 3+ years now and had
  > an extended beta/RC phase before that.
  > It's true that it defaults to ES5 if 
  > you don't configure it, but the Babel 
  > docs explicitly recommend that you do.
  > [..]
  > But it will take more than an unsupported
  > assertion to convince me that this has
  > been the norm for most web development 
  > for quite some time.

If it defaults to ES5 why are you asking for me to provide evidence as to whether companies have generally targetted IE11? It is the default; it is very unlikely that there is a majority of people that are configuring it...

  > But it will take more than an unsupported
  > assertion to convince me that this has 
  > been the norm for most web development 
  > for quite some time.

My claims are the following:

1. ES5 has been the default for front-end packages published to NPM since it was released (https://twitter.com/_developit/status/1289317757146693632). (I'm linking to Jason Miller's tweets since he has been the one most obssessively pushing for this to change. The problem we've all been having is that the `package.json` fields do not make it explicit what syntax a package is using.)

2. IE11 is in rapid decline (https://twitter.com/TheRealNooshu/status/1348955568459968515) and only recently have big corporations dropped support for it (Atlassian (March 2020): https://blog.developer.atlassian.com/retiring-ie11-support-f... ; Microsoft 365 (August 2021): https://docs.microsoft.com/en-us/lifecycle/announcements/m36... ; LinkedIn, Twitter, etc (2020): https://twitter.com/swyx/status/1260627626739130369). As I said "most only dropped IE11 this year". I guess I was off by one year, but I was talking about recent announcements.

For context, this was to evidence my opinion that the JavaScript community has been very slow moving and careful to output code that is executable by old browsers to the extent that we've supported a browser released in 2013 and used a syntax released in 2009.

  > And these kinds of things are advanced
  > tooling, in your view?

Check back to my text and you will see that I made no such claim.

You claimed that "the language doesn't provide much to help with building large-scale software and maintaining it over the long term" so I demonstrated that we have all of the necessary tooling to do so and invalidated this.

  > We had those in our IDEs for building 
  > desktop software back in the last 
  > century. Except they were automating
  > rewriting millions of lines of code [...]

Can you point me towards examples of the usage of AST rewriting tools that are actively being used by open-source library maintainers in other ecosystems to help their consumers do upgrades in large code-bases (e.g. I can see that `clang` has AST tooling, but I don't see examples online of this being widely used: https://devblogs.microsoft.com/cppblog/exploring-clang-tooli...).

Within the JavaScript ecosystem this is quite popular (1. https://github.com/reactjs/react-codemod ; 2. https://github.com/mui-org/material-ui/tree/HEAD/packages/ma... ; 3. https://github.com/emotion-js/emotion/tree/main/packages/esl... ; etc.) Teams that maintain huge codebases have tooling to safely automate their upgrades and the best library maintainers provide their consumers with these AST transformations.

  > Don't tell that to anyone who uses 
  > React Router. Or who builds their app
  > with Webpack. Or Babel, as you mentioned.

I agree that those particular libraries haven't been maintained well (they make extraordinarily large changes in major versions to the extent that sometimes it might as well be a whole new library).

  > I encourage you to look at what is considered the norm
  > and acceptable practice in fields where better quality 
  > and greater longevity are more highly valued. If we 
  > built security libraries or the embedded software 
  > controlling industrial machinery the way a lot of 
  > online companies build their web apps, we'd be lucky
  > to survive the night.

I think your argument has been a moving target. Originally, you pointed your finger at React saying it has a stability problem, so we showed you that they've been incredibly good at keeping backwards compatibility and that you could upgrade your version of React to regain access to the ecosystem's newest libraries built on top of new APIs without needing to rewrite your legacy code through the usage of compatability packages.

Then you implied that it was an overall JavaScript ecosystem stability problem, so I showed you the level of effort that TC39 and the brower maintainers go to keep backwards compatability. And I showed you that most in our ecosystem have been carefully supporting the lowest commmon demominator users for almost a decade by producing web apps that work in IE 11 and packages that first-class ES5 syntax, and gave you examples of big webapps that only recently broke from this tradition.

Now you are pointing at exceptional cases involving particular poorly maintained libraries and tools, and telling me that we lack tooling to deal with scale (which is a separate concern). If you don't think Webpack and React Router are good citizens with regard to their API stability and this annoys you because you like to be on the latest/greatest then don't use them. I and many others also specifically avoid these libraries/tools and yet don't paint the whole ecosystem with this one brush. (On the topic of tooling, it has only been very recently that we've been getting tooling that can deal with high-scale development, however it is happening now.)

  *  *  *

I think that possibly what you're noticing is the second-order effect of more and more usages of JavaScript and web technologies causing new APIs to steadily be added to the web with the old APIs remaining forevermore. The original APIs were made to display and navigate documents. As the years have passed more and more APIs have been released to support more complex types of applications and this resulted in overall churn in user-space as library creators iterate to produce better domain-specific APIs. We provide a high-level of user-facing stability despite this.

I don't think it is fair to compare what we are trying to achieve to what is important when controlling industrial machinery. The use cases of that are much more static, while in 2021 people on the Web are creating tools like Figma (https://www.figma.com/), Office 365 (https://www.office.com/), Buerli (https://buerli.io/), and Spline (https://spline.design/). This is very far diverged from where we started and the fact it has been achieved without breaking the web is impressive. It's also quite clear to me that high-quality tools like these aren't achievable without the creation of impressive and scalable tooling (some of which has been released to the public).

OK, let's agree to disagree...

I'm sorry if anything I wrote came across as condescending; that was not the intent. You seem reasonable enough, and objectively I agree with much of what you've said. However, I think we've been talking slightly at cross-purposes.

I won't try to go point by point now as these comments have become very long, but overall the difference between our positions (as I intend mine and as I currently understand yours) seems to be that you're focussing on specific technologies like JavaScript or React, while I'm talking more holistically about the entire ecosystem around them.

For example, you have talked about backward compatibility being excellent within JS-the-language, and about React continuing to support its class-based API alongside the functions-and-hooks alternative. That compatibility is not in dispute.

However, when I'm talking about stability, I'm also including everything that is built around JS or around React, the libraries and tools and documentation and people. And in these respects, the JS ecosystem is much faster moving and more fragile than almost any other language I have ever used.

The kind of bifurcation of APIs we've seen with React causes a lot of churn even if the library itself is still backward compatible. If you looked at blog posts or Stack Overflow answers or Reddit discussions about React from as little as three years ago, many of them would have little relevance to the newer API that has obviously become dominant within the community since then. On the other hand, if you hired someone with a couple of years of React experience today and asked them to maintain older code in your system that used the class-based API, they might have no idea what they were looking at. And if you found a useful library to work with React components but it only provides a hook-based API, again you can't use that functionality from your older class-based components. Your old code might still build, but it's essentially unmaintainable unless developers who have come to React more recently first learn what is effectively an entirely different library from their perspective, and even then you're limited in how much you can integrate that older code with more recent contributions to the ecosystem. (This paragraph is an elaboration on the point I was trying to make when I first joined this discussion.)

For the wider JS ecosystem, we've talked about the breaking changes in major tools like Babel and Webpack and in popular libraries like React Router. You suggest that these are "exceptional cases involving particularly poorly maintained libraries and tools". I suggest that there is, unfortunately, nothing exceptional about this sort of abandonment of earlier versions and interfaces within JS world. For one thing, Babel and Webpack aren't just any tools, they are arguably the two biggest names in the JS ecosystem, so when they break, the damage is widespread. For another, they are far from isolated cases. To give another example, Angular was React's big contemporary "competition" and it too essentially abandoned one API in favour of a radical rewrite for version 2, turning any project using the older framework into legacy code almost overnight.

Before React and Angular, we had a string of moderately popular UI libraries built around various levels of data binding. These were must-know technologies in their day for anyone who wanted to work on a project using them, but none remained popular for more than a few years, again leaving all of the individual knowledge and documentation and old code bases largely obsolete.

This pattern isn't unique to UI libraries, either. For example, as JS has evolved and added support for promises and then async/await, many older libraries whose interfaces weren't designed to support that programming style have been left behind, again including some that were very well-known and widely-used.

And with tools, it's a similar picture. Although Webpack is probably the most popular tool for building web app front ends today, over the years we've used shell scripts, self-contained tools like Browserify and Babel, task runners like Gulp and Grunt (with their own surrounding package ecosystems) to co-ordinate the ever-increasing number of tools used in build processes, more comprehensive tools like Webpack (again with a big surrounding package ecosystem) to try to unify everything in one place and bring some structure back, attempts to simplify the horrendous complexity that unification had introduced (the later versions of Webpack and the likes of Parcel), and now we're swinging back towards more specialised tools but in some cases with much better performance such as esbuild, but ironically these newer and better tools may be hard for a lot of projects to adopt because so many people are boxed in by their existing tools and have to wait for someone to provide some plug-in package for those existing tools in order to integrate the new ones. And again, breakage is not unique to Webpack. For example, not long ago, Parcel pushed out a breaking change, and because the effort from the Parcel devs is mostly focussed on the still-in-beta Parcel 2 that naturally has some major limitations of its own, this left teams using Parcel with broken builds either way until they figured out what the problem was and then probably rolled back to an earlier version of Parcel 1.

So I suppose my point is that all of that disruption can and does still happen frequently within the JS ecosystem, despite the backward compatibility of JS itself and the willingness of at least some of the big libraries to continue supporting old APIs after launching new ones. Stability, in the sense I'm using the term, implies a reasonable degree of backward and forward compatibility. The converse, unfortunately, does not hold. A good compatibility story is necessary but far from sufficient for a stable, productive ecosystem.

Come on, as someone that has worked professionally with Django and Next.js, the only similarity they have is that they're both web frameworks. Django is light years ahead than Next.js is it's not even funny.

Here's a very simple metric: Compare the Next.js documentation (https://nextjs.org/docs/getting-started) with Django's (https://docs.djangoproject.com/en/3.2/contents/) - better yet, compare the actual API reference and exported classes/methods.

Yes, Next.js is one of the better Node/Javascript frameworks, but it's incredibly inferior to any other established framework in Python, Java, PHP, Elixir, etc. — unless you only need a static page with some dynamic React components. I am in the unfortunate position of maintaining a more complex Next.JS app, using most of its "advanced" features such as dynamic routing, SSR, GraphQL, API, and it's the most painful project I have ever had the misfortune to work on, because the upstream interface and API is so woefully under-documented, buggy, changes too quickly it's hard to stay up-to-date, etc. etc. I weep every time someone on this forum suggests to start a new project with Next.js.

In theory Javascript on the server and client is a productivity boost, in practice it is not by any measure.

The similarly named (but completely different) Nest.js is much closer to Django than Next. Still a ways behind in terms of maturity, but it seems to be more or less on the right path.

> Yes, Next.js is one of the better Node/Javascript frameworks, but it's incredibly inferior to any other established framework in Python, Java, PHP, Elixir, et

This is like saying a screwdriver is incredibly inferior to a impact hammer.

> In theory Javascript on the server and client is a productivity boost, in practice it is not by any measure.

This is in direct contrast to my personal experience across multiple projects and teams. In practice it IS a productivity boost, because JS does 99% of what anybody needs a web server to do.

> This is like saying a screwdriver is incredibly inferior to a impact hammer.

I'm sorry, isn't the goal of web frameworks, including in this category Django, Next.js, Phoenix, Laravel, Nuxt.js to respond to HTTP requests and present users with an HTML page representing a document or a more complex web application?

> because JS does 99% of what anybody needs a web server to do

Brainfuck is Turing-complete and does 100% of what any other language can do as well. I stand by the fact that having to "know" only one language is great in theory, but in practice it's not. Node and client JS/Webpack are a leaky abstraction it's not very hard to get yourself cut with. In non trivial modules, you'll find it hard to be able to use the same code verbatim on the client and the server. Then add the complexity of server-side rendering, serialisation/hydration, React suspense, code that mysteriously works only when server-side rendered or viceversa, etc. and you'll ask yourself "is this really worth it?"

> code that mysteriously works only when server-side rendered or viceversa, etc.

It sounds like your opinion of server-side javascript comes from experience with badly written and poorly-understood server-side javascript, because none of that jives with my experience in writing node-based web applications.

> because JS does 99% of what anybody needs a web server to do.

Does talking to a DB really account for just 1% of what you want a web server to do?

I think we are into semantics here, but I would posit if your web server is talking directly to a db other than a key-value store for tokens or what have you, your system is architected poorly. Your web server should be talking to a service written in Java or C# or something that handles the db stuff.

edit: to address your point though, yeah, I think 99% of web sites don't need to be talking to a db. That's different from web applications, of course, but most web sites aren't, and shouldn't be, web applications.

Not everything needs to be architected to be "enterprise grade" though. And a lot more languages can handle DB than just Java and C#.

I am in the unfortunate position of maintaining a more complex Next.JS app, using most of its "advanced" features such as dynamic routing, SSR, GraphQL, API, and it's the most painful project I have ever had the misfortune to work on, because the upstream interface and API is so woefully under-documented, buggy, changes too quickly it's hard to stay up-to-date, etc. etc.

Would you give some specific examples of where you've found Next to be buggy or where it's introduced breaking changes? We're evaluating a number of possible Node-related libraries for a new project right now, including Next, and there's no substitute for hearing from people with real experience of using them in production.

Not the parent commenter, but maybe my experience saves you some time.

Next js is awesome, and it is the best alternative in my opinion if you go the SPA route.

Now, things get really, really, really messy and complicated when you start to implement on top of it everything else a typical web application would need. Authentication, validation, i18n, acceptance testing, background tasks or queues, etc....

We started out with next and prisma 2 and wasted a lot of time, in the end we rewrote the whole thing before launch with ruby on rails and turbo, some minimal stimulus and it was awesome. So much easier and simpler, and the application felt a lot more solid and robust.

So, next is awesome if you're doing a landing or relying on an existing backend api, etc.

If you need a full CRUD app, don't waste your time with it.

Thanks for the information. Would you mind elaborating on what made things "really, really, really messy"?

Our use case is fairly typical, basically an SPA doing the heavy lifting, an API on the back end to support it, and then some largely static marketing pages. There is a potential fourth aspect if we want to customise any of those back end pages depending on who is logged in, for example to personalise help pages with the user's own details or to host some account management pages separate to the SPA.

Next is under consideration because our SPA will be React-based, so being able to share components and styles for the rest of the site could be quite a time saver. We're reasonably sure we want to use some Node-based back end for this project, because that would allow us to share substantial functionality between the SPA and API implementations, but this would still apply if we used Express or another alternative to Next.

It looks like the SPA and static pages wouldn't be a problem with Next in your experience, but maybe there could significant problems we haven't anticipated so far with using Next for the API and/or with using server-side rendered but not entirely static content?

Ok, so here are a few examples of the things we didn't like:

1. We were doing SSR, and given we needed authentication we used next-auth [1], which is a great library btw, but the problem is given the architecture you buy into when you do an SPA, we had to check for authentication in three places: 1) In the frontend you need to check if the user is logged in or not and show information accordingly. In getServerSideProps you also need to check for permissions, because otherwise you'd be leaking private information in the "initial data" that gets embedded in the first's request html as json. And then you also need to check for authentication in the API pages/endpoints... each one of these has their own ways to be done (well documented in next-auth's docs) but still, you need to be careful, and it was very, very easy to make a mistake, forget to check on some place, etc. Of course you have tests for preventing this, but still... a lot more fragile than just using devise, or a "middleware" in a traditional MVC application. This is one of the things I refer as being more "solid" or "robust".

2. Validation. Oh my!!!... Prisma, again, is an awesome library. The best I've seen and I've used many similar in the past (django's ORM, ActiveRecord, etc). Prisma is up to that level in my opinion... but it is just the data access layer, on top of that you need to implement your own validation rules. We used Yup [1] for this, which, once again, it's a great library. But then we realized we needed to validate things such as already taken emails... but of course, you would not check by issuing first a get() or select and if you didn't find it you'll create it, because that could lead to race conditions... so the "proper" way to do it is to attempt an insert, and if the insert fails because of an unique index then handle the exception, generate an error message, and make it back to the frontend. All doable, and not that difficult. But still a lot of work, and it is easy to forget about corner cases, etc: fragile.

3. Then we needed to add internationalization. So we mixed in next-i18next [3], which added another axis of complexity because translations need to be available both at SSR time plus at the client side. Plus we also need to translate the error messages from the handling of the unique index exceptions from above....

4. We needed to implement some CLI tasks, (think of equivalents to runing a worker or a sync process, etc) which needed to import some domain logic... but next has its own babel and webpack so you cannot write them with plain node, so we needed to do a lot of hacks with @babel/register so that we could import this code, and then we found problems with our code relying on things such as getConfig that next sets up on boot, but this was a CLI so we were not booting next... so we needed to init the config ourselves.

5. By this point our index page was about 250k of javascript + translations + css... and we were not done yet. And the feeling of the end result was not that great.

And we all had a feeling that any of these libraries might change at any point [4], or go unmaintained, or out of fashion and we were just a team of 3.

I insist, I don't think the problems are in any of these tools, nor in JavaScript itself, nor in the ecosystem. These libraries are great, we really liked them. You would have the exact same problems if you try to use Flask, or Sinatra, or any other "lightweight" solution.... it can be done, and it can work very well for you... but it is 1) much more work, 2) requires very experienced people that really know what they're doing and 3) you'll end up re-implementing django, rails, or similar... in your own way, with less documentation and less real-world battle tested. These problems are caused, in my opinion, by the "architecture" you get in (SPA + separate backend).

We rewrote the thing in 1/4 the time with Rails + sorcery + Tailwind + delayed_job + a few other smaller gems. Just a bunch of models and some "services" (plain ruby objects), hotwire for the "spa feel" and stimulus for things such as date pickers, modals, etc.

I think also something to consider is the team size and skills. If you have, let's say, 5 backend devs, and 5 frontend devs, then it might make sense to get into the SPA + separate backend... it is more work, but it is easier to split it... if you're a small team, and/or want to stay as a small team, then nothing beats Rails (or symfony, etc... never used those others) for this.

Hope it helps, and good luck with your project!

[1] https://next-auth.js.org/ [2] https://www.npmjs.com/package/yup [3] https://www.npmjs.com/package/next-i18next [4] For example, Prisma 1 is a totally different beast from prisma 2.

Thank you, that was a very interesting read.

IIRC Next is a backend-for-frontend framework, not a general purpose one. Unless that changed?

It's a general purpose web framework, that happens to have a tight frontend integration thanks to JS and React. It's still JS + Node, and everything that enables.

There are frameworks like blitz.js(https://blitzjs.com/) coming up which build on top of next.js and provide you a full-stack development environment with react in the frontend. Far superior than what django/rails/laravel can offer.

I quite like Next.JS but this give me a little bit of a pause.

Do you really want to work with a framework that has another framework on top of it? This feels a bit iffy to me.

Our backend is Apollo GraphQL in TS, and it is has provided us numerous benefits:

1. The strong typing of GraphQL is a huge boon for correctness and security.

2. Easy to autogen TS types from GraphQL schema, so we can use the same types throughout our codebase, frontend and backend.

3. Apollo has lots of features that make it easy to scale projects.

And yet – Apollo advertises its easy Python interoperatibility right on the front page, as one of the features that makes scaling easier.¹

GraphQL arguably makes decoupling frontend and backend languages even easier than classic REST APIs, since the GraphQL schema can serve as single source of truth across language barriers.

¹ https://www.apollographql.com/blog/graphql-python-api-comple...

OK, let's unwrap that:

> And yet – Apollo advertises its easy Python interoperatibility right on the front page

Yes, absolutely, there is great support for GraphQL in many different languages.

> , as one of the features that makes scaling easier.¹

To be clear, that is your own commentary and I didn't see anything in the Apollo site that said implementing in Python makes scaling easier. I.e you seem to be implying that somehow implementing in Python is better for scaling, but there is no background to support that.

> GraphQL arguably makes decoupling frontend and backend languages even easier than classic REST APIs, since the GraphQL schema can serve as single source of truth across language barriers.

Yes, I totally agree with that. If you are, say, providing an API to other developers GraphQL is a great choice for a number of reasons, one of which is that there is great language support across pretty much all languages.

But if you are starting a project within a company, and have the luxury of choosing technologies, having the same ecosystem on the front and back ends makes it much easier for people on either team to go across that "boundary" if necessary. This is not just me hypothesizing. For the majority of career, which really started right when web apps started taking off, there was a separate language on the backend (Java for the majority of my career, but also sizable stints where Ruby and Python were the backend languages). Yes, most backend folks understood JS and CSS, and most frontend folks could understand the backend languages, but it was still a huge barrier to people being able to contribute across teams such that it rarely happened. It's only in the past couple of years where I've been in a "TypeScript everywhere" org where I've seen the gigantic change in the team dynamic that this allows.

On the other hand I've seen JavaScript everywhere slow down back end development and increase costs with not much increase in contributions across teams.

I've seen the same. It starts off faster and then as the business grows and features are added the problems scale up. Some symptoms I've seen on projects I've been asked to look over include but aren't limited to throwing Redis around when an in-memory structure would normally suffice because Node is too slow, scaling to 200 CPU's and using up at least 200GB gigs of RAM for a single servioce, when a 25 instances with 8 CPU's, 25GB of RAM could do the same job and cost a lot less, scared to write their own data structures/algo's that may be required as their business scales, etc.

I dunno if it’s even easier than REST given that an OpenAPI spec does the same thing without the scalability concerns of GraphQL

> without the scalability concerns of GraphQL

I hear about this dreadful "scalability" problem with GraphQL and N+1 queries and all other sorts of geysers constantly, but I see a lot more success stories than failures.

idk why people mentioned Next.js which is more Front End framework than Back End, but no one mentioned Nest.js. It is not old as Django but I think Nest is nearest framework to RoR/Django in Node.js

Definitely. NextJS isn't a "backend framework", it's a server-side rendering framework that has some backend abilities to handle simple use-cases.

NestJS is the most full-featured Node framework, but it's lightyears behind Django. Yet I'd still use it given the choice between both, because I prefer Typescript so much better than Python and having a single language through the stack is a game changer, enough that I'm willing to compromise on the frameworak.

Express? https://www.npmjs.com/package/@types/express

I agree with this - EXCEPT:

In a backend where you need a heavy-duty, multithreaded process to handle long-lived computations, node is probably not the way to go unless you want to pay for all the extra instances you'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.

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.

I agree with all of what you said. Note in terms of "architecture your way out of that problem", that's exactly what we did. We have an eventing architecture that uses PubSub to publish to serverless functions that can then do heavier processing asynchronously. And for us, this wasn't a compromise, this architecture has a number of other benefits.

But again, I definitely agree with what you've written, right tool for the job.

Where can I read more about that architecture you aretalking about?

Not op but I assume they mean: a main web server is scheduling large jobs in the background by publishing an event to whatever pub/sub system you want to use (there are many!), lambdas can be subscribed to this system so they trigger off these events and publish a corresponding event back when they're done that the web app is subscribed to etc.

For an example, you can look at how node interacts with OpenCV.

The JS scripts together the compute heavy CV alogrithms, and you can do similar by hosting your computer heavy things behind a service call, while keeping the orchestration parts in node

I would argue while it has other benefits it probably isn't as simple. Simplicity is usually the long term better choice. As the business scales since you've probably set a precedent this pattern will be copied all over the place. After enough times trying to understand who owns the data transformations, what lives where, how to support it when one part of the puzzle fails and trying to wire it all and how all these stacks couple together becomes a nightmare. Unfortunately I've experienced some of these issues coming into organizations after the original developers have left once it became too "big" of a place to work for - few people truly understand the architecture and even when they do its flaky and recovery is hard. YMMV depending on the complexity of your business and age. In the end IMO it just seems like a big workaround to keep using Node.

Typescript makes refactoring easier in what way? Can you do renames without error prone string search and replace? Can you get good autocompletions with ts? If so, that would be really nice

Yes, both work.

Yup! Especially using VsCode, which feels optimized for TS development. Click the var you want to rename, hit F2, rename it, and it renames all instances of the var. If you're renaming an import, it'll do it across all the files automagically. Moving a file? Imports get updated too!

Plus you've got MS's intellisense powering autocomplete. Unfortunately, I don't think it can recognize different foods, but as long as you've typed your variables the autocomplete is pretty good!

EDIT: the OP had a typo, saying food instead of good, for context as to why I made a food joke

None of this is better than the experience in Java though, which is what they were comparing it to. Maybe they were using shit tools?

The gp made this comment (https://news.ycombinator.com/item?id=27168048).

> This biggest "aha" benefit I get from TypeScript is that it is structurally typed, while Java is nominally typed. In my experience it has proven much easier to refactor in TS because I just need to ensure my objects have all the right properties. With Java if I have a Thing1, but a library is updated to add just a single new property so now there is a Thing2 type, well now then all the places I need a Thing2 I have to completely copy over from Thing1 - I can't just add the property and be on my merry way. This happened to me many times in my Java career - I still think I have PTSD having to do a Jersey 1.x upgrade to a Jersey 2.x version across a large codebase. It was a nightmare I've never had anything come close to with Typescript.

Not so much refactoring as upgrading, but tis an example of why duck typing is kinda nice

> maybe they were using shit tools

They weren't using Java, so probably not. ZING!

But seriously... If you want to compare tooling, you shouldn't be comparing a scripting language vs a language like Java... compare Java vs C# and C#'s experience is better than Java's IMO (not REAL experienced with Java but I've done some basic stuff).

Yes to all of your questions.

You forgot to ask, "can you get program flow analysis on top of static analysis for free?" To which the answer is also yes.

It's a bit sad that the bar is so low. If you don't have these, what is your editor even doing for you? Might as well use Notepad

> 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.

I don't really see how. TS doesn't seem to solve any annoying problems I previously had in Java. As a concrete example, it would be nice to have the concept of a DTO as a first-class language feature, but alas, I find myself constantly casting and re-casting, plucking, or writing endless wrappers to make sure properties trickle down (or up). Hell, sometimes I just give up and use `any`. I mean, this is a web-first language that has no concept of sending objects over the wire.. okay then.

TypeScript's generics system is cute, but I think it's mostly academic. And did you look at the toolchain? To get TS working, you need babel or ts-node or webpack, and like 3 different .json config files. Importing a package without TS support? You need to write some stubs yourself in types.d.ts. In fact, the best parts of TypeScript are actually JS (await/async, arrow notation, spread operator, etc.).

The shock wave that TS sends through a JS stack is hard to ignore. It's really annoying. Every tool added TS support in a slightly different way and you always have to keep it in mind no matter what you're doing. Sadly it's just the reality we gotta face. I'm hoping Rome can live up to the hype and be helpful here.

Oh man, so true, between TS mangling and whatever framework you're using (Vue/React/etc.), the stack trace ends up being literally worthless. It's kind of funny to think about: when something goes wrong, I don't even look at the trace (which is 100% what you'd do in any sane language), but rather I just go back and look at the "last thing I changed."

Ah that is true as well. When I said stack I meant like Babel, Storybook, Webpack, Jest, etc. But yeah JS stack traces aren't so fun these days.

You aren't using source maps to transform your stack traces then? I've had very little issue in understanding stack traces in any of the major JS frameworks.

I think esbuild is basically already doing most of what Rome promises

From Rome readme:

> Rome is designed to replace Babel, ESLint, webpack, Prettier, Jest, and others.

Afaik esbuild only intends to be a replacement for 2 out of 5 of those things. It does that well for sure, but if parent commenter's main issue is the amount of different tools, I don't think esbuild will help.

This biggest "aha" benefit I get from TypeScript is that it is structurally typed, while Java is nominally typed. In my experience it has proven much easier to refactor in TS because I just need to ensure my objects have all the right properties. With Java if I have a Thing1, but a library is updated to add just a single new property so now there is a Thing2 type, well now then all the places I need a Thing2 I have to completely copy over from Thing1 - I can't just add the property and be on my merry way. This happened to me many times in my Java career - I still think I have PTSD having to do a Jersey 1.x upgrade to a Jersey 2.x version across a large codebase. It was a nightmare I've never had anything come close to with Typescript.

> I mean, this is a web-first language that has no concept of sending objects over the wire.. okay then.

I have no idea what you're talking about here. I use GraphQL with auto typegen of my TS types and I get typed data objects everywhere.

> TypeScript's generics system is cute, but I think it's mostly academic.

TBH this remark just makes me thing you really don't know much about TS. I use generics extensively, find them very helpful and are easy to use.

I'll give you the point on initial TS setup being non-trivial. Hopefully advances in tooling (things like Deno, which I'm not actually a huge fan of, or other projects like Rome) will make this easier, but even then I found this to be a "one and done" cost.

Note that the upgrade pain with Java was not due to typing; rather, it was due to using a library directly instead of creating a class to interface with it. In other words, inadequate abstraction.

I find that making those classes is a pain in java, but really easy in typescript

> Note that the upgrade pain with Java was not due to typing; rather, it was due to using a library directly instead of creating a class to interface with it. In other words, inadequate abstraction.

I'd look into what Jersey actually is before you say something like this, because what you've said really doesn't make sense.

How so?

Yikes, is this really the expected way to do things in Java? That sounds frustratingly verbose. But I guess that is expected with Java.

There is a reason for nominal typing though, because nominal types represent an interface contract that generally goes beyond just having the right type signature, but instead it is also about semantics. It's about the parts not covered by the type system, which the compiler therefore can't check. It depends on the kind of objects you are generally working with, but beyond pure data I find nominal typing preferable, because it makes it explicit that an implementation X conforming to interface contract Y is not just a matter of type signatures.

This is just you not being familiar with the language

People are talking the other points to death but on the toolchain front, you might enjoy https://github.com/evanw/esbuild, which is rapidly gaining in popularity. Just 1 thing for bundling, transpilation etc. And its terrifically fast since its written in Go (ironic I know).

There is also swc which is fast because... its written in Rust https://swc.rs/

But there is also sucrase which is fast because.. its written in TypeScript? https://github.com/alangpierce/sucrase

At my last company I created a few tools that became key to my org, which was front end/JS oriented. Being able to write them in JS meant anyone could contribute fixes and features trivially, with zero ramp up time. That is a really nice benefit of Node. Imagine if Rails developers couldn't use Ruby for their tooling. Node really filled a nice gap here.

It would be amazing if there were other languages available for front-end development in the browser, no? Even if you think that JS is so wonderful, then having competition would still be good, or no? Currently JavaScript has a monopoly in the browser and monopolies are always bad. Bad for innovation and everything else.

It would be better if there were no oddities in a language. One of the reasons why everyone hates PHP is that it is full of inconsistencies, odd design choices, weird naming and unexpected behaviour. JS has at least some of these.

If there was a second of third language available in the browser, then that too could be used to develop back-end applications and would have the benefits you describe - that you can use the same language for both stacks etc. For example - if you could front-end stuff in Python, would it be amazing or bad? Or would the current JS devs just fear for their jobs because of it?

There are, you can write C# in browser easily.

Or write in TypeScript, or ClojureScript, or....

If you have existing code base / libraries in C#, then what's the point

Give WASM a go

> having a system where everything 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

How so? Is it just about being able to use a single set of tools, libraries, habits, etc? Or are there particular things which are easier when the language is common? Are you sharing code between front-end and back-end.

I do very lightweight front-end coding these days. It's usually some variation on populating and updating a table from a websocket, maybe with some simple filtering and toggling in response to user interaction. There, i can't think of any particular advantage to having both ends in the same language, but then mine is quite an unusual use case.

There’s a lot of compelling reasons to share code particularly at network boundaries. Using something like io-ts/zod/etc gives you simple, declarative, type safe validation. Being able to share that behavior is an enormous productivity boost in and of itself.

Sharing validation for forms is definitely really nice.

It feels like it should be possible to do that cross-language, generating some JS validation rules from Java annotations, say, but i have never seen it done.

The way it’s usually done is with a generalized language-agnostic spec like OpenAPI/JSON Schema. Because the definitions are standardized, you can effectively build tools in any language that should provide the same validation, to the extent they’re compliant and the spec is unambiguous.

These approaches can of course be combined, where the sorts of validators I mentioned generate (or even build their primitives around) those more verbose standards.

Mainly it has to do with teams. In most orgs there is something analogous to "a backend team" and "a frontend team", because the concerns and expertise are quite different.

Oftentimes, however, a frontend dev may need some small extra bit of data or functionality from the backend, and vice versa. If the ecosystems are very different, then the amount of time it takes to set up that separate ecosystem, remind yourself of the relatively minor syntax difference e.g. between TS and Python, update your dependencies, etc. can be a big barrier, so often the answer is to just throw a ticket over to the team on the other side and wait.

If, on the other hand, you can just quickly get into the other codebase, make a small PR and get it reviewed quickly, it can drastically improve the team's overall productivity.

I've always had front-end and back-end owned by the same team, and in the same repo, despite being in separate languages. The repo has a single build script which builds all parts of the project, whatever language they are in. Implementing almost any feature involves touching both front-end and back-end code, so people stay fresh. All of this seems like table stakes to me.

Maybe some organisations have separate teams working on the two parts of an application, which honestly just seems stupid, but that's not a necessary consequence of using different languages.

The first post also misses something fundamental about modern software: servers programming is becoming more browser-like.

> Node is not ECMAScript in a server-side ECMAScript engine, it's JavaScript in a browser JavaScript engine. That's just too much of a force fit

And what makes V8 a "browser JS engine"? A focus on:

- rapid startup. Code starts running immediately, JITs quickly. The VM is designed for latency, not just for throughput.

- excellent sandboxing. The VM is designed to run untrusted code.

- no blocking code. Designed for callbacks and promises. No threading, no thread.sleep(), no mutex, etc. Makes is much easier for non-expert developers to write fast & reasonably correct code.

Now look at things like Cloudflare Edge workers, Lambda etc. Modern server environments share all of those same design goals.

Server-side JS/TS not only has the advantage of a single codebase. It also brings the design and engineering advantages of a browser VM to the server.

Your examples doesn’t really read as a prototypical server application.

Rapid startup: lambda is a tiny subset, and not really server application. A server app could take minutes and would still be okay, because they are designed to run for a long time. Even in case of scaling minutes are more than okay since deploying a new instance takes a similar amount of time.

excellent sandboxing: you usually only run your own code connected to db and other very privileged services. If there is a vulnerability it is a very big problem with or without sandbox

no blocking code: i’m not up to date, but node doesn’t have a strong parallelism story at all, compared to the JVM, Go, .NET

"A server app could take minutes and would still be okay, because they are designed to run for a long time."

Wby would you want to maintain a long-running server process if you don't have to? And, wny do you think you have to?

A typical most basic website, awaiting requests and serving static/dynamic content is not a short-living process, I don’t see what is controversial about that.

At the end of the day, most web servers are about serving requests. A short lived function model fits that more closely.

So you think starting up a whole process, establishing connections to a db and serving the request would have any sort of acceptable latency and/or throughput? At that point, you could write your server in bash as well.. also, I think it would be ridiculously expensive.

Lambda is great for seldom run functions, like running some analysis/conversion on user uploaded profile pictures or the like.

To answer your (intended-to-be-rhetorical) question: yes! NextJS webapps deployed to Vercel / AWS lambdas have excellent performance characteristics.

Lambda containers serve multiple requests. You just write the code as if you were handling a single request. And on the contrary, Lambda latency is worst when you have spiky traffic patterns (such as for a seldom run function). Of course, if you can tolerate the cold start latency overhead, Lambda is also a cost effective solution for those seldom run functions.

Also, specifically for Aurora, Lambda supports transparent connection pooling. It is just no longer a concern of your application code.

Disclaimer: I work on serverless services at AWS. I’m definitely biased :)

Thanks for the correction! My point was not at all to “bash” Lambdas, just to point out the (in my opinion) incorrectness of grand(grand?)parent’s comment.

Though I suppose Lambdas don’t use separate traditional OS processes to serve requests, do they?

"[A long-running, traditional server process] awaiting requests... is not a short-living process."

That's an irrelevant tautology; the question was why you believe a long-running traditional server process is necessary.

There's many reasons why you would want the server, and reasons why you may not want it. Data structures and algorithms that as you scale give you an edge in the specialized problem domain you are in is usually one that I've seen. How many services have I've seen deployed that scale the DB to many cores and CPU's just to avoid some startup time? This is a problem I sadly see in a lot of Node stacks, and its easy to look good when you write a simple component to replace all that complexity and costs decrease as a result.

Most of the "serverless" things delegate to a server in the end anyway - whether they be a database, a managed service, etc. Something has to stay alive, be a server and own the state after all - serverless doesn't make the problem go away just passes the buck. For run of the mill small scale websites or websites that fit a particular paradigm lambda works fine. But it doesn't suit all apps, and its hard to make all problems fit it currently. As businesses scale custom solutions can scale better.

Either way you try to argue this, it's hard to make the case that Java/Javascript is better at any of those things than another language. Productivity be damned, your dinky jar file will get smoked on almost every quantifiable level if you pit it against against a C++ or Rust rewrite. What GP is saying is that the only reason people praise Javascript is because it's a unique language, and I think it's a fair appraisal. Javascript is in a class of it's own, for better or worse, and since it has no real competitors, it's easy to dismiss detractors.

Whenever I encounter Node, issues almost always follow. Whether it's NPM's delightfully useless error messages or a stream of neverending warnings filling up stdout, it quite literally never fails to cause a problem. Maybe Node should focus on saving it's reputation, because I for one run in the other direction of it. Hell, especially in the case of Node, I hope that Deno comes to replace most of it's core functionality. Putting up with half-assed software on a half-functional runtime only leaves me with a quarter of the patience I started with.

I kinda get this but syntax is one thing, understanding the context you're working in is another.

> For contrast, I know many teams with a backend in Python and a frontent in React/JS, and I've worked on some teams with that setup. In my opinion it's virtually all downside compared to a backend in TS, as Python and TS are quite similar from a web programming perspective (I'm not referring to Python'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.

How big of a problem is this?

At the end of the day all that really matters is that the external representations that get handed off are the same and that everyone makes the same assumptions. Given the same set of fields manipulating a POJO with Java streams is not all that different from using modern Javascript on a blob.

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”.

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.

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.

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.

I have also stopped trying to discourage people from cargo culting facebook’s stack for their 3-person teams or even solo. If someone insists on 10x the complexity and 100x the work, let them.

JavaScript is becoming bearable but still too painful for anyone who has touched ruby for example.

Meanwhile I’m learning closure and loving every second of it.

I find the Facebook stack to have a lot of boilerplate, but overall it's very simple rather than complex.

You always know exactly how to implement what you want, without having to think very hard.

You can do something small by yourself by writing less code, but using less code makes it more complex since you have to think a lot harder to understand the code when you come back to it in a few years

I will pipe up for client-side TypeScript in conjunction with Ruby-based services. I’ve been contributing PRs for Hotwire and it is the first time in 25 years I didn’t actively resent working in JS of any dialect.

Thank you for your contributions. I am super excited about Hotwire - and spending less time doing more.

Haha ruby of all things. The language where they create aliases in standard library to make the code "read like natural language"... With a framework that promotes mixins as a service layer/code sharing abstraction and fat models/controllers.

I get not wanting to start with a super complex stack, but Ruby and Rails are the worst mainstream framework maintainability wise it's obvious why it fell out of favour.

I've heard someone describe Ruby On Rails as: "lots of great magical wands that make great palaces appear out of thin air but always ends up spawning dragons you have to fight"

Reminds me of this talk https://youtu.be/gfh-VCTwMw8

> There’s a reason my copy of “JavaScript: The Good Parts” is extremely slim next to its sibling, “JavaScript: The Definitive Guide”.

The reason is that these two books don't fulfill the same goal. The Good Parts is a rather short walk through the language and reads more like a "get started quickly" guide. The other goes into much more detail. That doesn't mean the latter's size os due to it covering all the bad stuff whereas the former doesn't. It's just a clever title but it's an apples and oranges comparison and I'd suggest not using it as some sort of supporting argument.

Whether JavaScript is good or bad as a whole is a different question (I think it is), I'm simply taking issue with that meme (that originally popped up in picture form, the two books side by side, rather than text).

> There’s a reason my copy of “JavaScript: The Good Parts” is extremely slim next to its sibling, “JavaScript: The Definitive Guide”.

Because one's a style guide and one's a complete API reference?

Even as a style guide, it's unnecessarily terse in some cases. IIRC, there's a line that says (paraphrasing):

> Don't use continue. I've never seen a loop with a continue that wouldn't be better without it.

And that's it. No examples, no objective criteria, we're just supposed to take the man at his word on this. Whether or not I agree with this particular case, I don't enjoy argument from authority in most forms, especially not in one where you are supposed to learn about a better style of programming.

I have a lot of experience in both python, typescript and react. I would still opt for python on the backend, simply because it's a nicer language to work with. Debugging is a joy, and it feels like the library ecosystem is more comprehensive and stable.

This is of course subjective, and maybe I'm biased due to having a lot more experience with python than JavaScript.

I didn't do much web dev but is having the same language for the front and back end a real time saver? For a skilled programmer, switching language is not a big deal. I'd say that for a front end developer to touch the back end, learning the required bits of Python or whatever is used is not the biggest problem.

Front and back do different things, have different requirements. You control the architecture on the back end for instance, not on the front. The back end deals with data modeling and processing, the front with layout, very different task, very different skills, and the language is just a small part of it.

There is some overlap, for exemple I remember having to code a clock twice, once on the back end of to show it correctly the first time, and once on the front to have it refreshed in real time, the code could have been shared, but these occurrences where code can just be copy-pasted are not that common.

And BTW, most of my web dev was JS/PHP/SQL, and I actually liked all three languages for what they did. JS, I had no choice, but it did event handling well. PHP was good at generating HTML from a database and SQL, despite its age is still king for querying databases. I wouldn't want to use these languages for anything else.

The piece that's really nice is being able to share your data model definitions. Not having to define your interface once in one language, the again in another language is very nice.

There's tools to make it easier, but using them still means you have to pull in another stack into your workings/you're stuck with whatever limitations the tool has

The real advantages in my opinion will be found in deno where instead of managing separate node and web implementation of everything, you can use one implementation for both b

> For a skilled programmer, switching language is not a big deal.

I disagree, but with nuance. I consider myself a skilled programmer, and I have switched languages many times throughout my career, and you are correct, it is not much of a big deal. There have also been times in my career where I've been responsible for whole swaths of an app from back to front end where the backend was in Java and the front was in HTML/CSS/"old school" JS (this was back in the JSP/server-side days). And yes, in that case it was not hard to switch back and forth.

The problem, though, is that, as you point out very well, the back and front ends have very different requirements, and so in most organizations you have separate teams focused on the front end and back end. If I'm a front end dev, I'm going to be spending day-in day-out working in Javascript and my JS ecosystem. It's not that it's hard for me to, for example, learn and use Python, the issue is that since I'm not "practicing" it every day it definitely gets rusty, and as time moves on the ecosystem moves on such that my environment likely needs some tweaking (venv vs. pipenv vs. virtualenv vs. conda - honestly it's been a while so I have no idea what is in widest use these days).

So if I'm on the front end, and I need say one extra piece of data that I know is stored in the DB exposed in some specific API call, for what is likely a trivial change for a backend dev, well now the time it takes for me to get my backend env in sync (again, which maybe I haven't bothered with in 3 months), refresh my knowledge of Python, work through any dependency update issues etc. I may have can often be longer than the time it takes to make the simple code change. So what usually happens is the front end dev just doesn't bother, they submit a ticket for the backend dev to do it and wait to sync until the next sprint.

Compare this with what happens when front and back end are both in TS - the front end dev usually has a short chat with the backend dev to make sure the changes will be OK, but since everything is immediately familiar can go and make the change just as quickly as the backend dev, without needing to wait for the backend dev to have time to do it.

I have seen this cultural change in depth over the past couple years, and it is just a pretty shocking change if you've ever experienced it if you've been used to teams that were more "siloed" between front and back ends.

Optimizing the common case is much more effective in my experience. Setting up an environment should be scripted anyway. And having to refresh your knowledge of Python implies a while since you needed it.

> For a skilled programmer, switching language is not a big deal.

Not exactly.

It is easy in web space, but switching language is a big deal if the previous and next language have huge differences in concepts and on which layer of the stack lives.

For example, switching from language that has a complete runtime and GC to a language that does not, is a bit hard. In JS we have things like Promise.all, and setTimeout, and such to control concurrent async operations. On language like c/c++/rust where you produce abstract machine, you have to choose how to operate and regulate those async operations.

> everything is on the same tech stack ... has resulted in gargantuan productivity gains

i highly doubt that - i don't disagree you got productivity gains, but it's not from being the same stack, but it's from experience gained doing it.

If what you say is true, why doesn't people use GWT (google web toolkit) and java on the backend to get this productivity gain? It has existed even earlier than typescript, and is compiled to be quite fast. It's even more integrated as a stack, and anyone knowing java is able to use it fairly easily.

That’s analogous to using React on the backend. Kind of a non sequitur

no - react is a library, and in fact people do use react on the backend (for server side rendering).

we are talking about tech stack - most broadly the language (and compiler). GWT is a compiler from java to javascript. it cannot be compared to react (even tho GWT has a front-end UI component - but that's optional in GWT).

Oh that’s interesting. I’ve only ever known about GWT as a view renderer.

If there are productivity gains to be had please share it with the hoards of nodeJS 'full stack' devs at my company who suck up all wages, dont produce anything, and make people hate digital

> switched to Node, and shortly thereafter to TypeScript

Undergoing a similar path. My problem is that the moment I switch to TypeScript and start writing my code becomes very similar to Spring. And at that point I have to ask a question of why would I not just write Java. Node on the other hand feels like node.

There are a couple of things that JavaScript got so incredibly correct:

* Lexical scope natively without syntax or conventions

* Functions as first class citizens

* Inheritance, classes, OOP are not forced on you and can be ignored/omitted entirely from your code

Those few things are what has kept me hooked on the language.

> Node is not ECMAScript in a server-side ECMAScript engine, it's JavaScript in a browser JavaScript engine.

What does that even mean? The APIs are completely unrelated and Node does different things that don’t make sense in the browser.

That last bullet is my main complaint with java and c#.

C# just removed the requirement to start code with a class or a main method; you can just start typing into the file.

I like this so much. In fact they are investigating the idea of #!/usr/bin/dotnet on a .cs file!

> * Lexical scope natively without syntax or conventions

I assume you mean over the alternative, dynamic scoping like in e-Lisp. But you realize that JavaScript's scoping rules are entirely wonky, e.g. that "var" declarations are lifted to the function level?

To be more specific the term is hoist which means the declarations are pushed to the top of the scope at run time for maximum availability, and var is function scoped instead of block scoped. Block scoping is often more specific because a function body is a block as well.

Right but we have `let` now which solves that problem.

Not completely, `let` also has a weird temporal dead zone[1], which is basically a dynamic check.

[1] https://www.freecodecamp.org/news/what-is-the-temporal-dead-...

That's a good thing, and I'm not sure what you mean about it being a dynamic check.

It's a dynamic error if you access a let-bound variable before it is actually initialized. In most other languages that have lexically-scoped declarations, it simply would not be visible. So I think JS's choice is actually a regression.

var is a terrible example of that. Just don't use it.

A good example would be the scoping in for loops and maybe arrow functions. For loops are goofy but virtually never an issue, and arrow functions are awesome.

They were referring to `let`

>a couple of things that JavaScript got so incredibly correct: . . . Lexical scope natively without syntax or conventions

What language of the last 28 years doesn't "natively" lexically scope its variables?

JavaScript is different in that it use the function as the lexical scope rather then the angel brackets. This forces you to think about the code as functions, rather then blocks. And in turn helps you think of the code in three dimensions where time is one dimension, making it easier to understand code that runs asynchronously.

Because people coming from other languages find this confusing the let (and const) keyword was specified (ES6/2015) for block/angel-bracket lexical scope. Whereas var is function scoped.

Not Javascript. If I forget a var or let, it's global.

Strict mode throws an error on implied globals. Use of modules forces strict mode.

And that's all "extra" syntax.

strict mode is the default in everything now and had been for many many years.

It isn't the default for a browser "<script>" tag.

It's the default for <script type="module">, which you should use anyway for anything serious.

And here I thought scope was kind of disaster in JS:

- `const fooFunc = () => {}` is treated differently than `function fooFunc() {}` in declaration and subsequent access.

- A function's invocation context changes depending on how it was declared (fat arrow vs. function declaration)

Don't get me wrong: I love JS, but this is not one of the things I felt made it intuitive.

The this context changes, but I recommend developers not use this. That isn’t a scope issue though.

There would be no point in having two ways to do the exact same thing if function-style declaration and arrow-style declaration implementations were identical. Why would they add a new feature to the language if it was purely syntactic sugar?

>> Node is not ECMAScript in a server-side ECMAScript engine, it's JavaScript in a browser JavaScript engine.

>What does that even mean? The APIs are completely unrelated and Node does different things that don’t make sense in the browser.

I have taken the privilege of rewriting the quoted part of the parent comment,

Node runs javascript on the server side in an engine built for the browser. It does not run ECMAScript with an engine specially made for server side apps.

And those things are outweighed by things JavaScript got so incredibly wrong... like === vs == and some of the weirdness when you GASP use == as any other language would do.

JS is like PHP... only a popular language because it's been around a long time and it's easy to get started. Otherwise, there are SOOO many better programming language out that the ONLY reason JS still has traction is it became the "default" web language.

This comment is so weird. JavaScript got scoping completely wrong, and none of those were particularly novel when it was designed and they are almost universal now so I don't know why they would keep you hooked on JavaScript!

Maybe try some other languages...

10 years ago I would have agreed with you, but in recent years Javascript (and moreso Typescript) are just exceedingly pleasant to use. I'm using Typescript in backend services despite knowing Python and C# well just because I like it.

I can imagine that the original argument does not apply to the languages which compile to JS. But IMO the fact that there is so many derived languages covering the mess which JS is only supports the argument against it.

TypeScript is just JavaScript with type annotations. The runtime semantics are identical. JavaScript itself has improved to the point where it's great to work with, and arguably the nicest of the common dynamically types "scripting" langauges (python, ruby, PHP, perl).

Completely agree. I used to work mainly in Ruby, and I guess I miss its rich standard library, but overall TypeScript is such a joy to work with that now I use it for almost everything.

Couldn't agree more. I started in this field as a javascript programmer. I've since expanded my toolkit to include typescript, elixir, plpgsql and now gaining proficiency in rust.

I'm continually frustrated by my colleagues refusal to step outside the javascript ecosystem. Don't get me wrong, JS certainly has its place but its not ALWAYS the best tool for the job. I see a lot of people reach for node as their go to backend tech choice simply because its the ONLY tool in their toolbox.

Unless you're building a small focused microservice where the functionality involves calling out to a library with working tested code that does what you want, I think node is honestly a poor choice. To qualify my statement, I spent the first 7 years of my professional career building software with nodejs.

The sweet spot is much smaller than the scope of projects people throw at it.

* quick MVP? rails has more libraries that are drop in.

* Performance? go and elixir have node beat for multicore perf

* websockets? compared to phoenix channels, everything in node for serving websocket apis are a toy.

Lambda functions though? yea nodejs kicks but there!

TypeScript is a pretty good language for writing web servers, as long as you don’t need to do computationally heavy parallel computing. And you can still do that, but it’s very awkward.

I’ve done plenty of backend work in all of TS, Scala, Go, Python and PHP. Scala is my personal favourite, but it’s not as practical for teams as TS or Go, which are both very productive languages, with good enough type safety and performance, that new devs can learn quickly. And I’d easily choose TS over PHP or Python for a large system.

Plus, it IS pretty nice being able to use a single language everywhere. My current company is TS RESTful services with TS/React on the web, and TS/React Native on mobile, pretty hard to beat how easy it is to do full stack dev work for most ppl in this setup.

> computationally heavy parallel computing.

JS has no parallel computing support, so it is not an option. And when I say parallel computing, I don't mean distributed computing, I mean utilizing hundreds (thousands) of cores on a single die, like NVIDIA architectures. (It's a black art, even addition algorithms can confuse the newcomer.)

The best course is to do what every other language does when it comes to simple-parallel operations, like Gauss-Jordan elimination: use a dedicated, optimized library, like NumPY.

I really hope some day there will be a numpy for JS. NumJS is dead, and Google's TensorFlowJS is excellent for utilizing GPUs, but a dog when trying to do simple operations (the load/store async nature doesn't quite fit with most use cases.) I suspect WebAsm will facilitate the parallel nature of tensor operations without having to move

It sounds like you want something a bit like WebGPU: https://gpuweb.github.io/gpuweb/

Close, but I don't want to have to switch memory models, e.g. upload/download. What I want is the incredibly diverse numerical computing support and logical syntax of NumPY but in the same process & memory space. The W3C endeavor is something a little different. Thanks tho!!

I think you will be interested to read this article about the future of data programming in JavaScript (http://benschmidt.org/post/2020-01-15/2020-01-15-webgpu/).

I do think that this kind of thing will be able to be built on top of WebGPU (I saw this experimental POC that did so recently: https://github.com/milhidaka/webgpu-blas). The only issue is that since JavaScript doesn't support operator overloading even if a production-level library was created the code would be a little less readable.

This article nails it. While Python is such an elegant language for scientific research, it falls on its face when it comes to packaged applications (and as stated in my other posts, it's awkward async support compared to Node). I realllly hope scientific computing moves into NodeJS, or, Python gets better at asyncio and cross-platform packaging.

Node does have worker threads. They’re awkward because no shared memory, lots of serialization overhead and boiler plate, but if you’ve got heavy data processing to do on say a 4-8 CPU machine, you can certainly split it up between 4-8 CPU threads.

Node supports SharedArrayBuffer. It’s not perfect, but is usable.

In truth, assemblyscript or rust running in wasm is probably the best solution going forward.

True, but regardless, the kind of ergonomic, low overhead parallel computing available in Scala or Go just isn’t possible in Node. In Scala or Go, parallel computing is barely anymore difficult than synchronous computing, in Node it’s quite the pain in the ass once you want to start passing objects with methods and whatnot between threads.

That's process parallelism, not compute parallelism. To radically different things.

I've avoided using node worker threads in favor child.fork, which then resolves to IPC through process.on and process.send, which is like any other process management.

From my perspective (mostly a Python user), Javascript is a fine language for general-purpose scripting and server dev, and Node is more than fast enough to handle typical workflows.

Why do you think it's not a good language for this?

Also, I see a lot of value in using a one single language that can truly do everything: frontend, server, and scripting.

I guess you could use Python or Ruby like that with Wasm, but I haven't seen evidence of people doing that.

Like JavaScript, one can argue that the only thing wrong with node is the ecosystem/developer community. Things like npm as just not curated enough given the large number of JavaScript developers and the attendant variability in quality of output. Node itself is an almost perfect call-back driven even loop for Unix network io, which till go and go routines/channels was the conceptually simplest way to use the CPUs you are paying for, saturate the network, and have subtle threading issues. (Python gevent was also good at that, but had more implicit magic which is bad for reasoning about code).

But I am hopeful that when I finish reading the article I will not have to reuse my jquery / d3 based framework for doing quick data viz things (which I only started doing with great reluctance because people don’t go wow over tabular data even if the data is wow-ing. The first request to make it pretty, i switched to mono space fonts. But jquery is showing its age.

I don't know what's wrong with me. I hate JavaScript. I tried learning react and redux and just gave up. All this to put a button and a field on a page. React was basically invented by John carmack to do doom 3 and copied to render web pages. Is this really required!? It's not a 3d games engine. I've worked on web apps that require a lot of page updates per minute and I still hate react. I stay the hell away from front end web Dev as it just feels like hell. Sorry drunken rant.

Edit: I also worked on a node app that should have been written in a staticall typed language. Bugs that could have been caught at compile time literally caused me utter misery in on call overtime. All because some guy in our team demanded we wrote it in node. This was way before type script. I actually feel physical pain thinking about.

Perhaps give it another try, but with TypeScript. Im a front end dev and yes, I feel the JS pain. I look back at how I used to do things and think "wtf". TS completely changed this and brought it back to sanity.

I’m pretty sure the real issue is backend vs UI rather than JS/HTML. If you’ve worked with a few alternatives, the web suddenly doesn’t look too bad. Sure, a couple solutions are probably nicer, but they are mostly platform locked and way slower to develop on.

UI programming is literally the fine art of handling what your most exasperating client is capable of inflicting on your UI.

I suspect this is the core complaint.

at least part of the problem is that Javascript and webdev have really low barriers to entry, which is positive in the sense that anyone can do it, but the problem is that anyone can reach that unhappy valley of knowledgeable enough to do a lot of damage without realizing it.

If you put bad developers on other languages they usually end up running into some wall first but Javascript is pretty forgiving.

You should really try learning react first without redux. Redux is for managing global state. It's rarely needed but has become the defacto solution for react state for some reason.

React on its own is much simpler, once you grok the react compositional model. I don't know how you can do that while using redux too.

We specifically recommend that most folks should _not_ try learning Redux until after they're already comfortable with React:

https://redux.js.org/tutorials/essentials/part-1-overview-co...

That's great! (Although redux enthusiasts I've met tend to disagree with that philosophy).

Yeah, unfortunately there's been lots of folks out there who have tried to insist that Redux should be used everywhere, all the time, and ignored the guidance we've offered over the years on when it _might_ make sense to use Redux.

"React was basically invented by John carmack to do doom 3 and copied to render web pages. "

Does anyone have any reading material on this? I've never heard it and a quick Google turned up nothing, but I'd love to read about it. Unless it's a joke that went over my head...?

https://m.youtube.com/watch?v=nYkdrAPrdcw#

32 minutes in.

> Too many people only learn JavaScript, become psychologically dependent on it, and they all collectively took it too far outside of a browser.

Do you have any evidence for this? Because there's plenty of reasons why you'd share the same code in the browser and the server. Being able to do SSR and sharing validation logic are two huge and obvious reasons. Ever try to exactly duplicate validation rules between the browser and PHP? What about when they use weird regexp rules?

I have a site builder codebase that renders previews instantly as you make changes, then uses the same code on the server to render the HTML and CSS for visitors. That would be otherwise be outright impossible to do without writing the same code again in another language.

Here is my perspective: There are plenty of reasons to use the same language on FE and BE but for me the main problem is the JS standard library.

Let me give you one example:

Lets say you want to validate if a string is a valid URL. What is a good way to do this in JS?

Just for reference in Ruby for example I can do:

   URI.parse(input).kind_of?(URI::HTTP)

No gems or any other engines needed.

The URL constructor.

Oh wow, how I missed that. I stand corrected!

Seems like JS standard library is better than I thought.

> Being able to do SSR and sharing validation logic are two huge and obvious reasons. Ever try to exactly duplicate validation rules between the browser and PHP? What about when they use weird regexp rules?

PHP is adding support for FFI to any C ABI-compatible language, and you can run the exact same code in the browser via emscripten or a WASM polyfill. As a bonus, emscripten/WASM compiled code will also be more efficient in the browser than plain JavaScript or Typescript.

> As a bonus, emscripten/WASM compiled code will also be more efficient in the browser than plain JavaScript or Typescript.

Small gains compared to the cost of implementing. 10-20%. Now you're asking your full-stack developers to know PHP, JS, C, and WASM.

It seems silly to add a third language to your stack just so you can share code between the other two languages.

NodeJS is important for more reasons than "it's just JavaScript". It is asynchronous from the bottom-up, and it is literally a challenge to force asynchronous patterns into a synchronous ones, which is almost always a hack because async requires a lot of thought. This is a boon to IIoT control, where the pejorative "web server" is literally the endpoint for 10's of thousands of IoT edge nodes. NodeJS fits in with this architecture perfectly compared to the shoehorning required to make it work with PHP, (C/C++), Python or Java. (N.B.: I am not a java programmer, but we did review using Java, too, but it was voted down for other reasons.)

If there is another asynchronous language that is as well defined as NodeJS and has as much library support, I would very much like to study it.

This. I grew up with Lisp and Smalltalk, yeah I am that old, but today I love Node to build web apps.

It’s a fantastic environment for asynchronous programming. It also has a built-in REPL for a management interface via TCP or Unix sockets. It doesn’t really need any additional packages (I hate the dependency hell that npm saddles you with, and people don’t seem to know that Node already has http, https, and websocket upgrades built in, so you often don’t need any “frameworks” or libraries).

Give me Node, and I can build an entire web app from scratch. Most of the time you don’t even need to use JS in the browser. Just html and CSS are enough. Web apps the way God intended.

I don’t use Typescript either. Its type checking isn’t worth the hassle of poor tooling and inscrutable stack traces.

IMHO, TypeScript is only useful if you are using a build tool because it requires so much configuration. I switched to WebPack for very large Electron projects and I'm hooked on it. The syntactic sugar protects me from myself, and the importing is cleaner. I also finally made the switch to VSCode, which while bloated and awkward to configure, is pretty dang amazing when working correctly w.r.t. linting and code inspection.

Lot's of projects are popping up using ElectronJS, which is Node+Chromium. I have written many, and they are literally write-once-run-everywhere. Node serialport and node libusb have some speed issues on macOS, but require literally no alteration, utterly seamless.

The idea as "Node is just web" is dead in the water. Hugely popular ElectronJS(Node) apps are:

* Saleae - An inexpensive logic analyzer - https://www.saleae.com/

* Balena - a flash programmer for SDmicro and USB drives - https://www.balena.io/etcher/

* BetaFlight Configurator - the seminal drone (quad/hex/octo) configuration tool - https://github.com/betaflight/betaflight-configurator

[FYI: Python is far, far behind in packaging cross-platform apps and requires gigabytes of support libraries. People complain about Electron size, but they are only comparing it to native apps.]

> The problem started a decade or so ago with Node.

What problem, specifically? People enjoy writing Javascript. It has a ton of fantastic resources online, it is easy to debug and deploy, it's quick to pick up and forgiving of mistakes.

> Too many people only learn JavaScript, become psychologically dependent on it

You sound like Immortan Joe warning people not to become dependent on water in Mad Max. Let people enjoy the language they enjoy developing in.

> they all collectively took it too far outside of a browser.

What does this even mean? What's "too far" even mean? People want to write code, let them?

Unbelievable that this is voted to the top on Hacker News. The comment literally gives not one concrete example or reason by JavaScript is "bad". I'd expect more from you all here.

This happens every time a Javascript topic comes up - hundreds of comments just regurgitating the same "Javascript is bad" memes. It's bad enough that's there's no real point in reading the comments on JS submissions since there's rarely discussion about the article.

I am professional who used python, Java in my Career, and TypeScript is simply the best.

“Too many people only learn JavaScript, become psychological dependent o it “ is simply a false narrative from people who are stuck with obsolete web dev tech stack and refuse to learn better tools

What makes matters worse is that javascript is being pushed as the golden standard language and replacing pseudocode. In recent years I've stumbled across multiple articles on serious topics and concepts such as complex algorithms for compression or image processing and two scrolls down and I see an implementation in javascript.

insert ragequit gif here

So what? It's an incredibly productive language that CAN DO "complex algorithms for compression or image processing."

It's accessible, popular, easy enough to use, and ubiquitous. All the ingredients for success.

Does it belong on mission-critical spaceships? Whether you like it or not, the answer is yes, of course it does. https://os-system.com/blog/javascript-in-space-spacex-devs-h...

The fact that you can put a 900 bhp engine in a 40 year old rusty Citroen, doesn't make it a good idea(JavaScript being the Citroen). There's a good reason why operating systems are written in low level languages and not toy languages that are meant to make sites jiggle. JavaScript is just a convenient excuse to write slow, horrible, unreadable and unmanageable code without having people pointing it out because no one expects JavaScript to be anything other than an endless mess of spaghetti. Even in the case of space x is just a tool for shiny buttons and that's it. That still doesn't make it a good idea. Some time ago I saw in a video that the Audi entertainment system is written in typescript and as much as Audis are great cars, the entertainment system feels painfully clunky compared to a cheap 120 euro Android phone. JavaScript and node are horrible technologies that should be abolished and replaced by something that doesn't require a 14-core Xeon and 32gb of RAM to run semi-decently.

So what, is that not everyone loves it. Devs shouldn’t be forced to use a language that they hate using.

Thankfully WASM is a remedy for this, and over the next decade devs will be able to build full stack across web and mobile in Swift or any other language they prefer.

What I’m hearing is:

Because the language wasn’t planned to support all of this from the start, we just shouldn’t use it.

There’s lots of great reasons to use a full JS / TS stack. There’s lots of reasons not to.

Doesn’t mean it’s inherently bad. This is the same logic used against PHP every day yet it’s used all over.

> it's the only browser scripting language

IE did support VBScript, and only finally "killed" it in 2019

https://blogs.windows.com/msedgedev/2019/08/02/update-disabl...

ActionScript is also an ECMAScript language, and it's kinda ridiculous to see that JS still hasn't quite caught up. Out of things that modern JS lacks, AS had Java-like interfaces and you could specify types on variables.

(Yes, I know about TypeScript.)

As someone who first learned to code with AS2/3, I agree it was quite disorienting when I first tried to make a few games with HTML5/JS.

I do think you're not giving TypeScript enough credit -- I felt right at home the first time I used TS, and the type system is much more sophisticated than anything ActionScript ever had. As long as you're of the "favor composition over inheritance" mindset, which I'd argue is better, even for games, TypeScript is a fantastic spiritual successor to ActionScript!

Unfortunately there's no TypeScript-based game engine that makes it so easy to combine code with animations / sound. Nothing has really filled the void that Flash left behind.

This is wrong lol. V8 changed the whole paradigm. Thinking of Javascript as still just a browser language is the flaw.

JavaScript does not have a monopoly in web browsers. Microsoft supported vbScript and Google made a better and faster JavaScript (Dart) which also ran natively in the browser. But neither didn't take off. You can still "compile" for the browser though, the funny thing is that a lot if not most of the code running on the most popular web sites has gone through at least one compile step. So people don't actually program in JavaScript, it has become more of a compilation target.

Most browsers didn't support VBScript or Dart.

TypeScript and JSX are the most popular languages that compile to JavaScript as far as I know. They're very close to JavaScript because people learned straying too far created problems.

Don't do much JS, but this is actually what makes me the most sad. My formative programming years were during an era where there were many competing technologies on most given platforms.

Now days, if I do mobile iOS, I have to do Swift, Kotlin for Android, and as you say JS for browsers. I wish we lived in a world where the platform didn't design the stack so much.

The only reason I'm using node.js is because I can do this:

  let num = 0;

  route('/url').post(data => num++);

What other languages can I do this in that are better? I simply want to have a variable I can access and mutate from inside closures and let it live in memory without the need for databases or file systems.

every language?

To be fair, threads complicate things.

yeah but most languages have stuff like Atomic integers or other things.

I want a language where it's as natural as my example above, and normally an object or array so the integer was just to simplify the example. Do you have any suggestions?

I want to declare a variable and then be able to access/modify the same variable through a closure in a callback for incoming requests, so I guess that requires it to be single-threaded.

(I'm using this for game state where it's very convenient to just declare a persistent data structure in code directly without without having to use any additional abstraction.)

well without atomic access your state would be wrong. there are languages that allow stuff like that, but if you do it you can still have the wrong number. i.e. in c# something like you wrote is possible but when getting multiple requests, the number might be wrong at the end.

you always have some tradeoffs because in your case when you would run it with a multi threaded js engine your variable would be as broken as the c# one. that's why java does not allow it by default to modify a variable inside a thread that is declared outside.

> Node is not ECMAScript in a server-side ECMAScript engine, it's JavaScript in a browser JavaScript engine.

Why would your custom ECMAScript server be any faster or more stable than any of the existing browser engines? If you look at the resources behind those engines, I don't know who would match that effort doing the same on the server.

My guess is the browser JS engines are optimized for quick compilation and execution. While a backend engine could optimize for longer, persist runtime.

Reply on news.ycombinator.com