10 ms·

>It's really trendy to complain about JavaScript changing too fast right now but the last few years have brought some great changes to JavaScript. I'd say they

>It's really trendy to complain about JavaScript changing too fast right now but the last few years have brought some great changes to JavaScript. I'd say they've made JS development bearable, but great is really stretching it. We still don't have a type system, static analysis, multi-threading, first-class IDE support, or any of a myriad of other features that are standard in any modern programming language in 2017. I'm hopeful that projects like Blazor[0] and other efforts being made toward bringing real languages to the web via native WASM will put JS to rest once and for all. https://github.com/SteveSanderson/Blazor https://github.com/SteveSanderson/Blazor [0]

ko27 9y ago
> type system, static analysis, first-class IDE support Agree, but we have TypeScript, also static analysis is done for ES6 module dependency > multi-threading This is wrong. JS has service workers, and sharred array buffers.
- aphextron 9y ago
  >This is wrong. JS has service workers, and sharred array buffers. Service Workers are not really threads as the runtime environment is still single threaded no matter what, you just have the ability to spawn a new process. On top of that browser support is sketchy at best, with no planned support for Safari or IE.
  - lauritzsh 9y ago
    It is currently in development for Safari https://webkit.org/status/#specification-service-workers https://webkit.org/status/#specification-service-workers
  - JimDabell 9y ago
    > On top of that browser support is sketchy at best, with no planned support for Safari or IE. Apple is currently working on implementing it in Safari: https://webkit.org/status/#specification-service-workers https://webkit.org/status/#specification-service-workers It's misleading to say that there's no planned support for Internet Explorer – Edge superseded Internet Explorer so all new development is going into Edge, not Internet Explorer. Service Worker support for Edge is under development: https://developer.microsoft.com/en-us/microsoft-edge/platform/status/serviceworker/ https://developer.microsoft.com/en-us/microsoft-edge/platfor...
    - Silhouette 9y ago
      Edge superseded Internet Explorer Microsoft might like to think so, but until all our business clients agree with them, the real IE is still a significant limiting factor in deploying with any JS feature you can't effectively polyfill.
      - JimDabell 9y ago
        Okay, but that's an upgrade issue, not a dead-end issue like a lot of people would assume from being told that there's no plans to add it to Internet Explorer. Features get added to new versions, not old versions. Organisations using old versions will need to upgrade to new versions to get the new features. That's true of anything. It just happens in this case that Microsoft decided to go from Internet Explorer 11 to Edge instead of going to Internet Explorer 12. Saying that there's no plans to add support to Internet Explorer is like saying there's no plans to add support to Firefox 50 – true in a technical sense, but in practice, of course they add new features to new versions rather than old versions, and of course organisations have to upgrade.
        Silhouette 9y ago
        It's not just an upgrade issue. Many organisations aren't running Windows 10 and so have no browser upgrade path to Edge at all. Many organisations still have an older version of IE, probably IE11 but sometimes earlier, as their standard desktop browser. Experience tells us that those organisations aren't in a hurry to upgrade their standard desktop deployment just to get a new browser so web developers can play with the shiny new toys. Did we learn nothing from the XP and IE6 era? So it's all very well talking about newer JS features, but pragmatically, you can't just wish away the need for compatibility with browsers more than a year or two old if your target audience is businesses, governments, or other large organisations. There's an unhealthy complacency among parts of the web dev community, as if something being available in the latest Chrome canary now means it can be used everywhere. That's just not how a distributed system works when you don't fully control the client. Even if it were, you're not just going to retrofit something as significant as multi-threaded architecture into most existing JS code bases. Outside the HN bubble, not everyone gets to start a greenfield JS project every six months. I think aphextron's original comment was fair and realistic: as a practical matter, even with the rapid pace of change in the JS ecosystem, we still can't use a lot of day-to-day features in JS that would be routine in most other modern programming languages.
- alayek 9y ago
  > JS has service workers Do you mean Web Workers? https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers...
clarus 9y ago
For type systems you have Flow and TypeScript, coming with their IDEs. The Chrome devtools and various plugins helps having a good IDE too. Multi threading is possible but rarely used because the concurrency model of JavaScript is event based. Overall, I think JavaScript has a very rich ecosystem because, if you do Web programming, you do not really have alternatives to JavaScript. So the community made the language support various programming styles, tools and libraries. I do not believe WASM will help bringing more language to the Web than today because it is already possible to compile to JavaScript with good enough performances for most use cases.
alayek 9y ago
> We still don't have a type system, static analysis, multi-threading, first-class IDE support Let me try to address these. Regarding type system, lot of great languages don't have type systems either. But if there's lot of discussion on type systems, it would be because of Flow vs TypeScript. As for static analysis, JS has seen evolution of JSHint, JSLint, JSCS, ESLint, and finally, Prettier. Flow is capable of performing type-checks with dynamic analysis. I am not sure multi-threading is the hallmark of a modern language. Because Go, Elixir etc. are providing great concurrency without exposing threading API to the developer. JavaScript lets you do asynchronous tasks via callback, promises, generators, and latest - async/await. In the browser, you can use web-worker. But in most cases, you won't need it. JS ecosystem has great code editors. I find VSCode to have good support out of the box, with breakpoint debugging. You can also use Atom, or Sublime Text, or Webstorm. If you're missing certain functionality, you can always add open-source plugins.
- crispinb 9y ago
  > JS ecosystem has great code editors. I'm with you on most of your points, but IDE support is still quite crude compared to (say) Java or Kotlin. Once you're fluent with these in a Jetbrains IDE it feels like you're directly manipulating an AST (or something near it) rather than 'editing text'. Javascript (even with Typescript in IDEA/Webstorm) isn't close to this yet.
seanwilson 9y ago
Do you actually code in JavaScript? TypeScript addresses many of these issues and even statically checks for null variable usage which puts it ahead of some mainstream type systems in my opinion. I don't hear people making fun of Python for example and that has a huge following.
- mod 9y ago
  I mean, I do occasionally, but I think one big difference is that nobody is forced to use python. If they want a feature a normal language doesn't have, they can easily choose another. That's simply not true for JS.
  - seanwilson 9y ago
    > I mean, I do occasionally, but I think one big difference is that nobody is forced to use python. If they want a feature a normal language doesn't have, they can easily choose another. Most domains heavily constrain your language choice though...C/C++ for games, Java/Kotlin for native Android, Swift for native iOS, PHP/Node/Python/Java/Ruby for server-side. The libraries you need constrain the choice even more. I'd love to use OCaml everywhere if I could but there's just no support for it. Anyway, my point is complaining that vanilla JavaScript is bad is a real disservice to modern JavaScript. What's so bad about it if you use TypeScript?
    - nojvek 9y ago
      I love JS and especially the variety of tools available. It's a double edged sword. But once you have your tools is great. I love webpack, vscode, Typescript, npm, preact and mocha. All great tools to solve a specific problem. So much better than a number of other language. Have you ever dealt with the horrors of package management with pip because it's inconsistent installs.
      - seanwilson 9y ago
        > So much better than a number of other language. Have you ever dealt with the horrors of package management with pip because it's inconsistent installs. Personally I'm surprised the null/undefined checking feature of TypeScript isn't raved about more which is missing from many typed languages.

ko27 9y ago

> type system, static analysis, first-class IDE support Agree, but we have TypeScript, also static analysis is done for ES6 module dependency > multi-threading This is wrong. JS has service workers, and sharred array buffers.

aphextron 9y ago
>This is wrong. JS has service workers, and sharred array buffers. Service Workers are not really threads as the runtime environment is still single threaded no matter what, you just have the ability to spawn a new process. On top of that browser support is sketchy at best, with no planned support for Safari or IE.
- lauritzsh 9y ago
  It is currently in development for Safari https://webkit.org/status/#specification-service-workers https://webkit.org/status/#specification-service-workers
- JimDabell 9y ago
  > On top of that browser support is sketchy at best, with no planned support for Safari or IE. Apple is currently working on implementing it in Safari: https://webkit.org/status/#specification-service-workers https://webkit.org/status/#specification-service-workers It's misleading to say that there's no planned support for Internet Explorer – Edge superseded Internet Explorer so all new development is going into Edge, not Internet Explorer. Service Worker support for Edge is under development: https://developer.microsoft.com/en-us/microsoft-edge/platform/status/serviceworker/ https://developer.microsoft.com/en-us/microsoft-edge/platfor...
  - Silhouette 9y ago
    Edge superseded Internet Explorer Microsoft might like to think so, but until all our business clients agree with them, the real IE is still a significant limiting factor in deploying with any JS feature you can't effectively polyfill.
    - JimDabell 9y ago
      Okay, but that's an upgrade issue, not a dead-end issue like a lot of people would assume from being told that there's no plans to add it to Internet Explorer. Features get added to new versions, not old versions. Organisations using old versions will need to upgrade to new versions to get the new features. That's true of anything. It just happens in this case that Microsoft decided to go from Internet Explorer 11 to Edge instead of going to Internet Explorer 12. Saying that there's no plans to add support to Internet Explorer is like saying there's no plans to add support to Firefox 50 – true in a technical sense, but in practice, of course they add new features to new versions rather than old versions, and of course organisations have to upgrade.
      - Silhouette 9y ago
        It's not just an upgrade issue. Many organisations aren't running Windows 10 and so have no browser upgrade path to Edge at all. Many organisations still have an older version of IE, probably IE11 but sometimes earlier, as their standard desktop browser. Experience tells us that those organisations aren't in a hurry to upgrade their standard desktop deployment just to get a new browser so web developers can play with the shiny new toys. Did we learn nothing from the XP and IE6 era? So it's all very well talking about newer JS features, but pragmatically, you can't just wish away the need for compatibility with browsers more than a year or two old if your target audience is businesses, governments, or other large organisations. There's an unhealthy complacency among parts of the web dev community, as if something being available in the latest Chrome canary now means it can be used everywhere. That's just not how a distributed system works when you don't fully control the client. Even if it were, you're not just going to retrofit something as significant as multi-threaded architecture into most existing JS code bases. Outside the HN bubble, not everyone gets to start a greenfield JS project every six months. I think aphextron's original comment was fair and realistic: as a practical matter, even with the rapid pace of change in the JS ecosystem, we still can't use a lot of day-to-day features in JS that would be routine in most other modern programming languages.
alayek 9y ago
> JS has service workers Do you mean Web Workers? https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers...

clarus 9y ago

For type systems you have Flow and TypeScript, coming with their IDEs. The Chrome devtools and various plugins helps having a good IDE too. Multi threading is possible but rarely used because the concurrency model of JavaScript is event based. Overall, I think JavaScript has a very rich ecosystem because, if you do Web programming, you do not really have alternatives to JavaScript. So the community made the language support various programming styles, tools and libraries. I do not believe WASM will help bringing more language to the Web than today because it is already possible to compile to JavaScript with good enough performances for most use cases.

alayek 9y ago

> We still don't have a type system, static analysis, multi-threading, first-class IDE support Let me try to address these. Regarding type system, lot of great languages don't have type systems either. But if there's lot of discussion on type systems, it would be because of Flow vs TypeScript. As for static analysis, JS has seen evolution of JSHint, JSLint, JSCS, ESLint, and finally, Prettier. Flow is capable of performing type-checks with dynamic analysis. I am not sure multi-threading is the hallmark of a modern language. Because Go, Elixir etc. are providing great concurrency without exposing threading API to the developer. JavaScript lets you do asynchronous tasks via callback, promises, generators, and latest - async/await. In the browser, you can use web-worker. But in most cases, you won't need it. JS ecosystem has great code editors. I find VSCode to have good support out of the box, with breakpoint debugging. You can also use Atom, or Sublime Text, or Webstorm. If you're missing certain functionality, you can always add open-source plugins.

crispinb 9y ago
> JS ecosystem has great code editors. I'm with you on most of your points, but IDE support is still quite crude compared to (say) Java or Kotlin. Once you're fluent with these in a Jetbrains IDE it feels like you're directly manipulating an AST (or something near it) rather than 'editing text'. Javascript (even with Typescript in IDEA/Webstorm) isn't close to this yet.

seanwilson 9y ago

Do you actually code in JavaScript? TypeScript addresses many of these issues and even statically checks for null variable usage which puts it ahead of some mainstream type systems in my opinion. I don't hear people making fun of Python for example and that has a huge following.

mod 9y ago
I mean, I do occasionally, but I think one big difference is that nobody is forced to use python. If they want a feature a normal language doesn't have, they can easily choose another. That's simply not true for JS.
- seanwilson 9y ago
  > I mean, I do occasionally, but I think one big difference is that nobody is forced to use python. If they want a feature a normal language doesn't have, they can easily choose another. Most domains heavily constrain your language choice though...C/C++ for games, Java/Kotlin for native Android, Swift for native iOS, PHP/Node/Python/Java/Ruby for server-side. The libraries you need constrain the choice even more. I'd love to use OCaml everywhere if I could but there's just no support for it. Anyway, my point is complaining that vanilla JavaScript is bad is a real disservice to modern JavaScript. What's so bad about it if you use TypeScript?
  - nojvek 9y ago
    I love JS and especially the variety of tools available. It's a double edged sword. But once you have your tools is great. I love webpack, vscode, Typescript, npm, preact and mocha. All great tools to solve a specific problem. So much better than a number of other language. Have you ever dealt with the horrors of package management with pip because it's inconsistent installs.
    - seanwilson 9y ago
      > So much better than a number of other language. Have you ever dealt with the horrors of package management with pip because it's inconsistent installs. Personally I'm surprised the null/undefined checking feature of TypeScript isn't raved about more which is missing from many typed languages.