4 ms·

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

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.
- franklyt 6y ago
  Care to share what you think would constitute a “good” lingua franca for the web?
  - Silhouette 6y ago
    I think it is precisely the development of WASM as an alternative first class citizen to JS that has the potential to create a new lingua franca. As for what we might one day build on top of it, I'm not sure the ideal language or languages exist yet. I do think there is the potential to have something that retains the relative ease of access that languages like JS, Python and Ruby have offered, but with a much better type system, and perhaps designed with the kind of API-heavy and event-driven programming we use on both the front and back end of many web apps in mind. I suspect that to break into such a huge ecosystem, it would need to have almost transparent interop with JS so in the early days it could use the existing libraries, though I would also hope that many of those libraries would immediately be obsolete or would soon be replaced by native alternatives anyway given that most of them are relatively basic by general programming standards.
    - franklyt 6y ago
      Thanks for your thoughts. The notion of there being no sufficient existing language for web development is an interesting one.

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.

franklyt 6y ago
Care to share what you think would constitute a “good” lingua franca for the web?
- Silhouette 6y ago
  I think it is precisely the development of WASM as an alternative first class citizen to JS that has the potential to create a new lingua franca. As for what we might one day build on top of it, I'm not sure the ideal language or languages exist yet. I do think there is the potential to have something that retains the relative ease of access that languages like JS, Python and Ruby have offered, but with a much better type system, and perhaps designed with the kind of API-heavy and event-driven programming we use on both the front and back end of many web apps in mind. I suspect that to break into such a huge ecosystem, it would need to have almost transparent interop with JS so in the early days it could use the existing libraries, though I would also hope that many of those libraries would immediately be obsolete or would soon be replaced by native alternatives anyway given that most of them are relatively basic by general programming standards.
  - franklyt 6y ago
    Thanks for your thoughts. The notion of there being no sufficient existing language for web development is an interesting one.