4 ms·

JS isn’t going anywhere.

Silhouette 6y ago
Not any time soon, certainly. But it really should do. It's a language that was designed hastily and without a solid foundation. That was no big deal at the time, but it causes a horrible loss of quality and productivity now that it has become one of the most-used programming languages in the world. JavaScript has a quirky and highly dynamic type system, with lots of edge cases that can cause surprises. See the famous "WAT?" presentation for some examples, though that was only a few minutes long and so could only scratch the surface. JavaScript has awkward syntax, which makes it unnecessarily difficult to write tools and libraries to support it, as well as creating unusual complications like ASI. Modern JavaScript is trying to be half-imperative, half-OO and half-functional programming, and there isn't enough sensible grammar to go around. This makes various idioms you'd often use in each style in other programming languages awkward in JS, while at the same time not providing some of the best features found in languages more specialised for each style. JavaScript has a tiny standard library, and what it does have has plenty of inconsistencies and quirks. This, more than anything else, has led to a catastrophically complicated landscape of large JS programs importing on hundreds of relatively small libraries via transitive dependencies, in a tangled mess that probably no-one has ever even looked through on most projects. That's how you get the left-pad fiasco, but more generally, it's a staggering hit on productivity because everyone has to jump through hoops to do even quite simple tasks and often people choose to jump through slightly different sets of hoops that get a similar end result, so now you have multiple ways of doing the same things in your code and extra bloat in your build. It's also a legal and security nightmare just waiting to happen. TypeScript inherits almost all of the above. It does improve on the type checking, obviously, but even there its type system is actually unsound because its developers made the choice to prefer JS compatibility rather than a completely foolproof type checker. I think that was a reasonable choice, but it doesn't change the fact that the one big feature TS brings to the table is actually flawed because of its JS legacy. None of this should be surprising to anyone who programs JS/TS regularly, but since my previous comment got heavily downvoted I feel the need to defend it with more concrete and objective criticisms. Given the importance of web development in the modern software landscape, I truly believe that adopting much better languages -- languages designed carefully, built on solid theoretical foundations, learning the lessons from decades with JS and other programming experience since JS was created, equipped with a good standard library and essential tools -- could bring a qualitative improvement in many important respects, particularly productivity and reliability, across what is now a vast part of the software industry. I'm not crazy and have no illusions that this will just magically happen tomorrow, but with the advent of WASM, there is at least a chance that with a big backer or two behind it, something new might have a shot at becoming established and, in time, attracting enough support to take over.
- franklyt 6y ago
  I agree with some of what you're saying. Points of contention: 1. It's not necessarily interesting to point out what JavaScript was as a rebuttal of what it is. This is a genetic fallacy. If you think that some mistakes are baked into the cake - you're probably right, though you'd need to expound on that point. However, if you compare JavaScript today to the original JavaScript spec, it's not even close: modern JavaScript is profoundly more suitable as a language for the web. 2. I appreciate the hybrid style of JavaScript. 3. The small JS std-lib problem is only partially true nowadays, and it is a problem easily fleshed out with tried, tested utility libraries, like lodash. 4. TypeScript/jsdoc do not change JavaScript into the language you want it to be, but simple type hints, in my experience, give it some of that expressiveness of a strict type system with most of the power of a dynamic, loosely typed language. 5. I feel profoundly productive in JS. That is, as opposed to other, more "robust" languages, and many developers feel the same way. In fact, I probably feel most productive in node, though I probably could be close in golang with more practice. As a productive tool, it fits the bill, not just for me, but for many programmers. For this reason alone, I don't see any kind of paradigm shift forthcoming, especially if your alternative is something like Rust, which is a strawman position that I won't knock down.
  - Silhouette 6y ago
    FWIW, everything I wrote before was intended to refer to JS and TS as they are today. I would certainly agree that today's JS is much better than the JS of the pre-ES6 era, but the JS of the pre-ES6 era was objectively one of the worst programming languages ever to gain significant adoption, so that's not exactly a high bar to clear. Unfortunately, even with the useful additions to the language, a lot of the historical baggage is here to stay. The dynamic nature of the language means everything is nullable by default, except with JS there are two distinct null-like values. The type coercion rules have all kinds of strange consequences. It can't make up its mind whether to make standard library tools standalone functions or methods called on something and the two don't compose well with JS syntax, which is never great but particularly annoying if you're trying to write code in more of a FP style. Everything is mutable by default and side effects are totally uncontrolled, with the same observation. Idiomatic JS relies on magical global variables, which differ depending on the platform it's running on. It has exceptions but limited tools for using them systematically, particularly in larger programs. Obviously vanilla JS is also missing all the benefits of a more expressive and static type system, which is where TS comes in and why TS has rapidly become the preferred option for many front-end developers as they have more code to work on. However, the TS type system is still ultimately dealing with the underlying JS types and the tools JS provides for working with them, which means it's not entirely sound. Even with the TS additions, you still don't get the kinds of algebraic data types and pattern matching that are entry-level features for languages with good static type systems these days. The standard library is still weak. Yes, it's true that there are many utility libraries you can readily include in your project dependencies to help with that, but that is part of the problem. The benefit of a comprehensive standard library is that everyone has the same version of that functionality available with no extra code required. No need for maybe dozens of extra indirect dependencies in your project because each library you depend on directly has its own preferences for which utilities to use. No need to worry about whether the utility library you picked plays nicely with optimisations like tree-shaking or you've just added extra bloat to your bundle. No need to worry about whether different utility libraries have compatible representations for structured data or follow the same conventions for parameter orders. Lodash and friends are great and they do reduce the problem, but they shouldn't need to exist in the first place. And all of this has consequences for the whole ecosystem, from the capabilities and performance of the tools we use to work with JS/TS code every day to the dependency hell problem, and also for the general programming knowledge and skill of developers who have primarily or only worked in JS and TS. I don't know your own background, so I don't know how to interpret your feeling that you are highly productive in JS. All I can tell you is that as someone who has also programmed in many other languages and in many contexts away from web development, much of the JS ecosystem is very far behind the state of the art. I am hopeful that this will improve in time, even if we do get stuck with JS and derivatives compiled down to it. TS is at least trying to improve one aspect, with a better type system overlaid on top. There are build tools now that Just Work for everyday tasks instead of requiring endless tweaking of configuration files and installation of plugins. There is at least one build tool in development that isn't several orders of magnitude slower than it needs to be, unlike every major bundler/optimiser currently in widespread use within the JS ecosystem. But these incremental improvements, welcome as they are, can only go far as long as the JS heritage underpins everything. The one thing that could improve the performance of the web development community dramatically and across the board, far more than any single new tool or library, is a language designed to do the job properly and taking advantage of everything we've now learned about programming, programming languages and programming for web development.

Not any time soon, certainly. But it really should do. It's a language that was designed hastily and without a solid foundation. That was no big deal at the time, but it causes a horrible loss of quality and productivity now that it has become one of the most-used programming languages in the world. JavaScript has a quirky and highly dynamic type system, with lots of edge cases that can cause surprises. See the famous "WAT?" presentation for some examples, though that was only a few minutes long and so could only scratch the surface. JavaScript has awkward syntax, which makes it unnecessarily difficult to write tools and libraries to support it, as well as creating unusual complications like ASI. Modern JavaScript is trying to be half-imperative, half-OO and half-functional programming, and there isn't enough sensible grammar to go around. This makes various idioms you'd often use in each style in other programming languages awkward in JS, while at the same time not providing some of the best features found in languages more specialised for each style. JavaScript has a tiny standard library, and what it does have has plenty of inconsistencies and quirks. This, more than anything else, has led to a catastrophically complicated landscape of large JS programs importing on hundreds of relatively small libraries via transitive dependencies, in a tangled mess that probably no-one has ever even looked through on most projects. That's how you get the left-pad fiasco, but more generally, it's a staggering hit on productivity because everyone has to jump through hoops to do even quite simple tasks and often people choose to jump through slightly different sets of hoops that get a similar end result, so now you have multiple ways of doing the same things in your code and extra bloat in your build. It's also a legal and security nightmare just waiting to happen. TypeScript inherits almost all of the above. It does improve on the type checking, obviously, but even there its type system is actually unsound because its developers made the choice to prefer JS compatibility rather than a completely foolproof type checker. I think that was a reasonable choice, but it doesn't change the fact that the one big feature TS brings to the table is actually flawed because of its JS legacy. None of this should be surprising to anyone who programs JS/TS regularly, but since my previous comment got heavily downvoted I feel the need to defend it with more concrete and objective criticisms. Given the importance of web development in the modern software landscape, I truly believe that adopting much better languages -- languages designed carefully, built on solid theoretical foundations, learning the lessons from decades with JS and other programming experience since JS was created, equipped with a good standard library and essential tools -- could bring a qualitative improvement in many important respects, particularly productivity and reliability, across what is now a vast part of the software industry. I'm not crazy and have no illusions that this will just magically happen tomorrow, but with the advent of WASM, there is at least a chance that with a big backer or two behind it, something new might have a shot at becoming established and, in time, attracting enough support to take over.

franklyt 6y ago
I agree with some of what you're saying. Points of contention: 1. It's not necessarily interesting to point out what JavaScript was as a rebuttal of what it is. This is a genetic fallacy. If you think that some mistakes are baked into the cake - you're probably right, though you'd need to expound on that point. However, if you compare JavaScript today to the original JavaScript spec, it's not even close: modern JavaScript is profoundly more suitable as a language for the web. 2. I appreciate the hybrid style of JavaScript. 3. The small JS std-lib problem is only partially true nowadays, and it is a problem easily fleshed out with tried, tested utility libraries, like lodash. 4. TypeScript/jsdoc do not change JavaScript into the language you want it to be, but simple type hints, in my experience, give it some of that expressiveness of a strict type system with most of the power of a dynamic, loosely typed language. 5. I feel profoundly productive in JS. That is, as opposed to other, more "robust" languages, and many developers feel the same way. In fact, I probably feel most productive in node, though I probably could be close in golang with more practice. As a productive tool, it fits the bill, not just for me, but for many programmers. For this reason alone, I don't see any kind of paradigm shift forthcoming, especially if your alternative is something like Rust, which is a strawman position that I won't knock down.
- Silhouette 6y ago
  FWIW, everything I wrote before was intended to refer to JS and TS as they are today. I would certainly agree that today's JS is much better than the JS of the pre-ES6 era, but the JS of the pre-ES6 era was objectively one of the worst programming languages ever to gain significant adoption, so that's not exactly a high bar to clear. Unfortunately, even with the useful additions to the language, a lot of the historical baggage is here to stay. The dynamic nature of the language means everything is nullable by default, except with JS there are two distinct null-like values. The type coercion rules have all kinds of strange consequences. It can't make up its mind whether to make standard library tools standalone functions or methods called on something and the two don't compose well with JS syntax, which is never great but particularly annoying if you're trying to write code in more of a FP style. Everything is mutable by default and side effects are totally uncontrolled, with the same observation. Idiomatic JS relies on magical global variables, which differ depending on the platform it's running on. It has exceptions but limited tools for using them systematically, particularly in larger programs. Obviously vanilla JS is also missing all the benefits of a more expressive and static type system, which is where TS comes in and why TS has rapidly become the preferred option for many front-end developers as they have more code to work on. However, the TS type system is still ultimately dealing with the underlying JS types and the tools JS provides for working with them, which means it's not entirely sound. Even with the TS additions, you still don't get the kinds of algebraic data types and pattern matching that are entry-level features for languages with good static type systems these days. The standard library is still weak. Yes, it's true that there are many utility libraries you can readily include in your project dependencies to help with that, but that is part of the problem. The benefit of a comprehensive standard library is that everyone has the same version of that functionality available with no extra code required. No need for maybe dozens of extra indirect dependencies in your project because each library you depend on directly has its own preferences for which utilities to use. No need to worry about whether the utility library you picked plays nicely with optimisations like tree-shaking or you've just added extra bloat to your bundle. No need to worry about whether different utility libraries have compatible representations for structured data or follow the same conventions for parameter orders. Lodash and friends are great and they do reduce the problem, but they shouldn't need to exist in the first place. And all of this has consequences for the whole ecosystem, from the capabilities and performance of the tools we use to work with JS/TS code every day to the dependency hell problem, and also for the general programming knowledge and skill of developers who have primarily or only worked in JS and TS. I don't know your own background, so I don't know how to interpret your feeling that you are highly productive in JS. All I can tell you is that as someone who has also programmed in many other languages and in many contexts away from web development, much of the JS ecosystem is very far behind the state of the art. I am hopeful that this will improve in time, even if we do get stuck with JS and derivatives compiled down to it. TS is at least trying to improve one aspect, with a better type system overlaid on top. There are build tools now that Just Work for everyday tasks instead of requiring endless tweaking of configuration files and installation of plugins. There is at least one build tool in development that isn't several orders of magnitude slower than it needs to be, unlike every major bundler/optimiser currently in widespread use within the JS ecosystem. But these incremental improvements, welcome as they are, can only go far as long as the JS heritage underpins everything. The one thing that could improve the performance of the web development community dramatically and across the board, far more than any single new tool or library, is a language designed to do the job properly and taking advantage of everything we've now learned about programming, programming languages and programming for web development.