>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.
> 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.
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.
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.
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.
> 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?
You can use practically any language for games or web servers; they are certainly not constrained to the ones you listed. Game engines are usually written in C++ but the logic usually isn't. Even more importantly, the reason they're written in C++ is because it's usually the best tool for the job, NOT because nothing else is available. Nothing prevents you from writing a game engine in Rust or JavaScript or assembly language or whatever you want. And on servers, anything really does go.
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.
> 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.
Most domains constrain your language choice into something that fits that domain.
It is just mobile and web that constrain your choice into some arbitrary stuff that may or may not work well, and it's your problem to deal with the consequences.
ATM Angular 4 w/Typescript in VS Code is in my top 5 favourite language/dev environment combinations.
It has working code completion and is fast. It lacks refactoring and doesn't help me with debugging though.
(Java with any of the three big IDEs occupies three spots but I haven't made up my mind about exact order except first place. Also these are my favourites - they are not necessarily everyone elses favourites.)
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.
>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.
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:
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.
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.
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.
> 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.
That's an upgrade issue. They are using older software and a feature you'd like to use is being added to a newer version of that software. Yes, upgrades aren't always convenient or timely, but it's still just an upgrade issue, not a technology you have to give up on because two major browser vendors aren't interested in developing it.
> 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.
I'm not wishing away the need to support older versions. I'm just saying that this is something we'll be able to use eventually, not something we'll never be able to use because two major browser vendors refuse to implement it. It's an upgrade issue.
Well, OK, but by that argument almost anything is just an upgrade issue, so I'm not sure that really gets us anywhere.
In particular, it doesn't solve the practical problem that even with all the recent developments in the JS ecosystem, as things stand today a lot of front-end web developers don't have access to language features and programming techniques that are widely available in other environments.
Unfortunately, this is just an inherent problem in the way that web tools have been repurposed for more general software development: the developers don't control a significant part of the infrastructure, so they will always have to code to the least common denominator among their target market.
> Well, OK, but by that argument almost anything is just an upgrade issue, so I'm not sure that really gets us anywhere.
That makes no sense. My argument is very narrow, clearly applies here, and I don't see how it applies to "almost anything".
> In particular, it doesn't solve the practical problem that even with all the recent developments in the JS ecosystem, as things stand today a lot of front-end web developers don't have access to language features and programming techniques that are widely available in other environments.
That doesn't really have much to do with what I've been saying.
Maybe we're talking at cross-purposes, but you seem to be saying that
(a) it doesn't matter that there was no support for a feature planned for IE, because it is planned for Edge
and
(b) IE and Edge are essentially the same browser, and one is just the upgrade for the other.
I contend that this is what Microsoft's marketing department would like everyone to think, but the reality in larger organisations (and for those developing web sites and apps aimed at those organisations) is that they are two completely different browsers. In many cases, the only way you can "upgrade" from one to the other would be literally upgrading the entire organisation's standard desktop environment, including the OS.
If you're going to contend that a missing feature in one product is only an upgrade issue because you can change the entire OS and then install a completely different product to do the same job and then get that feature then I don't know what wouldn't be "just" an upgrade issue.
For all practical purposes, Edge is the next version of Internet Explorer. New features aren't being added to Internet Explorer 11, only to Edge. Yes, Edge has higher system requirements than Internet Explorer 11, but that's not relevant to my point. The same was true of Internet Explorer 9, which didn't run on Windows XP, but that didn't mean Internet Explorer 9 wasn't the next version along from Internet Explorer 8 or that it was "a completely different browser" or "a completely different product". It just means it's got higher system requirements, that's all.
The only thing the higher system requirements mean in practice is that the timetable for upgrading is delayed for some organisations. Those that aren't on Windows 10 will upgrade later than those that are. This means that it's not a blocker for using service workers, just a pretty typical delay while we wait for organisations to upgrade. As I keep saying, it's just an upgrade issue.
Saying that Microsoft aren't adding support for service workers to Internet Explorer while leaving out the massive fact that this is because Internet Explorer is the legacy version and they are adding it to the next version along, Edge, gives a radically different impression to what is actually happening. It implies that we'll never be able to use service workers because a major browser vendor isn't supporting it, when the reality is the opposite – that Microsoft are adding it to the next version of their browser and that all web developers have to do is wait for people to upgrade.
This is then compounded by the claim that Apple are doing the same thing – which is also untrue. Apple are adding service worker support to Safari right now, you can even go and look at the code yourself.
Yes, I understand that in terms of IT operations, the upgrade from Internet Explorer 11 to Edge is not without its complications. But it doesn't matter to the point I'm making. This is an upgrade issue, not a "multiple browser vendors have killed service workers" issue.
> If you're going to contend that a missing feature in one product is only an upgrade issue because you can change the entire OS and then install a completely different product to do the same job and then get that feature then I don't know what wouldn't be "just" an upgrade issue.
Changing from a previous version of Windows to Windows 10 is an upgrade. Changing from a previous version of Internet Explorer to Edge is an upgrade. It's quite clear why I'm calling this an upgrade issue, and I don't see how you can think that logic applies to things other than upgrades.
An example of what wouldn't be an upgrade issue is what I am explicitly contrasting against here. Two major browser vendors refusing to implement service workers wouldn't be an upgrade issue. If Microsoft and Apple won't add support for service workers to their browsers, then developers can't just wait for people to upgrade because newer versions won't include support either.
That's why it's so relevant to say "hang on, that's not right, both Microsoft and Apple are adding support to the latest versions of their browsers". It's the difference between service workers eventually being usable with a great deal of cross-browser support, and service workers being dead outside of small niches.
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 [0]