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.
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.
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.
Apple is currently working on implementing it in Safari:
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/platfor...
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.
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.
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.
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.
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.
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.
(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.
Do you mean Web Workers? https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers...
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.
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.
That's simply not true for JS.
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?
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.
Personally I'm surprised the null/undefined checking feature of TypeScript isn't raved about more which is missing from many typed languages.
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.)
We pack = Webpack?
When we hear about frameworks and build tools we think http://m.imgur.com/gallery/2dykF3D
If you're going to be writing a lot of CSS, then using SASS might save you some time and improve readability. If you're writing a webapp, then a SPA or React app might be the best course. And if it's image heavy, then a tool to automatically compress images would likely make sense.
If this is too complicated to manage, then other tools like task runners or Webpack can help automate the process. Node packaging can be used to sync settings across all project owners.
Taken on their own, it seems like a lot of complexity. But if you're only adding tools when you need them, it's really not that bad.
I wrote my last site in Jekyll + SASS. No Webpack, no gulp, no React. I just didn't need them, so I avoided the complication.
I'm glad they're there if I decide I want them, though.
Some people would consider it a bad thing that eg. Backbone hasnt had a major version in years but it is still perfectly capable for many use cases and it performs well. Of course you have to have more experience and knowledge with JS and frontend development in general to get these results I think.
Of course, you may still want to tweak configuration, and then you have to "eject", which means that all configuration files are dumped in your directory for you to edit, and you basically don't use create_react_app anymore. You now have to get webpack and babel configuration right to make your changes, but you have a solid basis.
Nowadays, I try to never eject, and see create_react_app as a lib providing everything I need. It sometimes prevents me to try new staged js features, but on the other hand I often have new features on update that I didn't bother enough about to eject in previous version.
Such wrappers around build system are probably the way to go. I would love to see something like create_react_app but allowing to provide buildpacks, so we can find in the wild the perfect configuration for our taste.
If you really want to be able to modify the Webpack config for a CRA app, you have a couple other options besides ejecting:
- Create your own custom fork of the react-scripts ( https://github.com/facebookincubator/create-react-app/tree/m... ) package that CRA uses
- Use the react-app-rewired (https://github.com/timarney/react-app-rewired) tool , which lets you override parts of the build config within your project.
They have an excellent, super-comprehensive README that covers practically everything you'd ever need to know about state-of-the-art Frontend JS tooling: https://github.com/facebookincubator/create-react-app/blob/m...
create-react-app itself is great for quick prototyping, but for non-trivial apps, chances are, eventually some esoteric production concern will force you to "eject". At that point, the sheer volume of configuration you'll be left with will be rather overwhelming if you've never dealt with the underlying technologies before, and modifying/extending it can become rather intimidating.
My recommendation is to start your first few projects with create-react-app, to get a feel for what a modern JS dev experience feels like, and then once you find the need to eject, instead of actually ejecting, copy your code over to a new project starting with just a bare minimum Webpack + Babel config, like the one in react-hot-loader-minimal-boilerplate (https://github.com/wkwiatek/react-hot-loader-minimal-boilerp...) and refer to the ejected configs of the create-react-app version of your app and the create-react-app README to port over pieces of tooling that you feel are sorely missing from your create-react-app days, one by one. This way, you'll be left with a much simpler and leaner tooling pipeline that you fully understand and one that you'll be able to extend and maintain much more easily.
I usually refer to the react-hot-loader-minimal-boilerplate config as a baseline simply because I consider es-next transpilation and hot-reloading essential parts of the modern Frontend dev experience. If you don't, you can totally start with something even more barebones.
I still have no clue about frontend web frameworks yet.
Live / Hot reloading might take some setup though.
One thing I am yet to see implemented, is tail-recursion. It's in the spec, but I am yet to find an environment that implements it. Please correct me if I'm wrong.
I too, am learning JS in 2017, and I can't wait to go back (to cljs). Or away, to anything else. I had done some basic stuff before, but for the last days I have been writing some code for a larger SPA.
Just as an example, today I needed to do the simple task of iterating over a dictionary. I expected it to go roughly like this:
dictionary.forEach(this.someMethod);
for (var key in dictionary) {
if (dictionary.hasOwnProperty(key) {
this.someMethod(key, dictionary[key]);
}
} Object.entries(dict).forEach(fn)
_.entries(dict).forEach(fn)Of course, once you're writing typed JavaScript, you're no longer writing JavaScript.
Maybe you should consider that just because a language doesn't work like what you're used to, it doesn't mean it's a bad language. Because saying nowadays that javascript is not worth learning sounds pretty absurd. Sure, you can live without it. But that's probably the most useful language to know as a "second language", for all its various applications and because when you want to add scripting in your tool, you know javascript is a solid choice for its penetration rate.
sql = client.read()
res = remote_db.query(sql)
client.write(res),
The fact that the big web scripting monopoly influences other scripting and embedding markets is self-explanatory.
As for 'second' language, I'm pretty sure I'm not happy to do main work with a 'second' language, because it is second only after top 3-5 that I use on daily basis.