It's a matter of opinion. If you get used to strongly typed languages, the idea of having your entire application in something barely typed like Javascript feels horrifying. I may be able to tolerate Javascript-with-a-typesystem (for instance, typescript), but raw JS? I don't see why you'd ever want to do that.
What I'd like is a language I can use that has optional typing where all the libraries follow a strict type system but the application I put on top of it doesn't care.
That is the exact opposite of what I get with TypeScript. I'm left with a lot of dynamic mess libraries that I build my typed application on top of.
if javascript is ok to be primary language, why choose another wrapper language to make it feasible?
it is totally a disaster design in Javascript and the wrapper language should not bail out Javascript. Instead, just let javascript die.
Here's the thing, JavaScript as it is (specifically ES5, a little bit less so with ES6, but even then, still an issue) is too dynamic to reason about very well, especially when using large libraries that do crazy things. Yes, it can be changed to be easier to reason about, but the fundamental issue I see is that too many people are using the very dynamic features of JavaScript.
Javascript could be versioned. If Javascript is changed to be more static and less "forgiving", browsers could ship with one engine to run legacy ES6 code and another to run new code.
Javascript is the C++ of web dev. You bolt a ton of things on top of a shitty language and you hope to obtain a slice of it that is decent in the long run. Except it's still going to be full of terrible quirks and 30 ways to shoot yourself.
I'm sorry, but I don't want this future for programming.
One thing JavaScript gets very right is first-class functions. There's nothing bolt-on about those. It makes it very easy to tolerate warts (which don't come up often anyways).
> Piss poor string handling functions out of the box?
Don't know what you mean by this. As for the other things; like I said, getting first class functions right makes those other things unimportant. Are you running into the problems with DateTime that often? I can't even remember what those problems are. I don't doubt they exist, but I think you're over-inflating the importance.
I think part of the author's point is that JS has now achieved so much critical mass, so to speak, that in the not too distant future it's just going to be the programming language. Being a programmer will be synonymous with writing JavaScript. So it doesn't really matter how you feel about JS per se; it's the language all the tooling will be built around, it's the language young programmers will have learned in school, it's the language that the people who cut the checks will assume by default you'll be using. So justifying using anything else will be an increasingly difficult uphill struggle as you fight against all these factors.
Which will be the day I leave the field. It's okay to toy around with, and decent for some DSL type things, but I think it an absolutely insane proposition to write a few million line codebase exclusively in JavaScript, especially when dealing with sensitive data, complex data structures, and complicated algorithms.
> that in the not too distant future it's just going to be the programming language. Being a programmer will be synonymous with writing JavaScript.
chortle
Not so long ago they were saying the same about Ruby, and Java before that, and so on down a long and winding history of ludicrous one-language-swallows-the-world predictions.
> Not so long ago they were saying the same about Ruby, and Java before that, and so on down a long and winding history of ludicrous one-language-swallows-the-world predictions.
In this case it's not so much a prediction as an observation of what has already been happening.
It might be hard to believe, but the browser is not the be-all and end-all of software.
I'm starting to think theres a JS Bubble forming, inside which people who only ever touch JS and nothing else proclaim that the world and the moon are made entirely of JavaScript.
I disagree with some of your points. We tried writing a big web app in JavaScript, and we were extremely sad to see how hard it is to maintain JavaScript code. I like IDE support as well, and JavaScript provides terrible type inference, clear defined structures and other things needed to get it right. People argue that there is Definitely Typed and other things that provide type interfaces for libraries, but it kinda reminds me of header files in C/C++, because it's not defined with the code. We ended up using Dart because of it's interesting take on Web Development (It doesn't just give us the DOM APIs, it improves them and does the polyfilling and that stuff for us). We have been doing this for multiple years and have had a great success. Also, I have strong opinions about JavaScript, including that it looks like a monkey made it, and that someone literally took all the bad things from other languages and put them together. All in all, it's a matter of preference. I've always gone against the crowd too (I think React is just meh, which is not popular), so there is that.
Though I like React, I agree with the rest of your points.
I've done small-ish projects in Node. There's tons of ways to do JavaScript that your IDE's static analyzers will not like. If you use IIFEs extensively, most of it will not be auto-completed for you. Needeless to say, same thing goes for function signatures -- good luck quickly getting through the parameters and their order (note: it's possible this has changed in the last 12 months).
I like JS well enough -- the functional aspect of strings, arrays, etc. But IDE support is lacking and it makes it hard to retain control as the codebase grows.
The IOT argument is specious and betrays a lack of understanding the challenges in connecting devices; specifically, the choice of controlling language begins at a lower level of the stack. New languages will arise, but they will be statically typed and speak protocols like LonWorks. Don't confuse hobbyist kits that are well suited to JS for actual, useful-in-production programming stacks for IOT.
My company works on an IoT Platform for connecting services and devices together, and I agree. We have found that JavaScript is a poor choice to target. We focus on a language-independent structure. In the real world, nobody is using JavaScript to power anything useful on small devices, it just doesn't fit well with an embedded system.
This starts with the blanket statement that you should always use javascript when starting a new web project and then follows up with two examples of using javascript in non-web environments.
While I agree that Javascript has matured a lot, and it has its place in the backend, I strongly disagree that it should always be used. We need to give thought about why we're using it and make it a conscious choice. It can be that its a single language on the frontend and backend. It can be the abundance of developers. It can be it's evented nature. But blindly making a choice without thought leads to a cargo cult mentality.
Additionally, there is no replacement to backend code. We may one day have good enough abstractions to allow us to mostly forget about the backend, but it will still be there. Bugs will arise where we need to understand how it works, and there will always be some sort of API (whether hidden or not) that we need to be mindful of. The web is a client-server system, and we can't forget that.
"This is not likely to change in the next couple of years while waters still settle. But generally the downsides of using JavaScript are fewer and fewer."
"Give the community time, and they will come up with solutions to most things that are considered impossible today."
Okay, so JavaScript will be better/awesome in the future. I still don't see why my next project should be in JavaScript.
Every time I try to get into full Javascript, I come across so many things that feel half-baked that I decide to wait it out some more and go back to the tried-and-true tools.
It isn't the language itself. I actually like ES2015 and I'm looking forward to improvements. It is digging through NPM trying to find a decent library. It is trying to reconcile versions of node. It is the feeling that everyone it trying to follow the latest hotness.
I think that there will eventually be an abandoned javascript library for every noun, verb, and adjective in the English language.
So you're having issues with a few components of the ecosystem, why are you taking it out on the language itself?
npm modules are not an integral part of the language. It's just an optional add-on that you might explore on your own to get work done for you more easily and more efficiently.
If you're lucky and found a module that fits the bill perfectly for a given project, that's awesome. If not, that's fine too. You can either fork the module and extend it as you like or build a new one from scratch.
I don't know why you would expect to find npm modules that can get the job done 100% for you and all the time?
That's a totally unrealistic expectation and unreasonable.
If everything that we devs need is ready-made and our jobs relegates to only gluing stuff together like entry-level technicians, don't you think that would be detrimental to our profession as a whole as it would be a few clicks away for a bot or an algorithm to automate our jobs away?
> I don't know why you would expect to find npm modules that can get the job done 100% for you all the time?
Get the job I'm doing done 100% of the time, do the job they are supposed to do 90% of the time I'd like that, constant version churn, API changes, strange incompatbilities between things that are supposed to work together not to mention stuff like browserify/watchify which when they work are great and when they don't a complete pain.
Also makes me chuckle whenever it throws a ENOENT not because I don't know what it is but that a high level original browser dependent language is throwing it and not "No such file or directory" or anything friendly.
npm/node reminds me of the implementation of a server side scripting language implemented solely in JavaScript written by people who have only ever heard other server side scripting languages described to them on a broken radio.
Again you're lashing out at JS due to your experience with node or npm which none is part of the language itself.
That's like someone after ordering a regular Big Mac meal (burger + fries + soda), he complains that the dessert portion of the meal either sucks or there are too many options available and some are not optimal enough when actually there was no dessert included in the meal in the first place.
Can we get real for a moment here?
npm/node reminds me of the implementation of a server side scripting language implemented solely in JavaScript written by people who have only ever heard other server side scripting languages described to them on a broken radio.
'Everyone is entitled to his own opinion, but not to his own facts.'
I am not "taking it out on the language". I don't "expect find npm modules that can get the job done 100% for you and all the time". You are putting words in my mouth and then arguing against them.
The article is "JavaScript as default language and software stack"
I'm saying I don't want to use javascript as my default language and software stack. How do I use javascript on the backend without node and npm? Surely it is doable, but why would I want to? Other languages work great on the backend, they have standard libraries, and they have solid tools.
The hard part isn't implementation or building; it's requirements and design. If JavaScript as a default language and software stack gives me more time to design and gather requirements, then hell yes let's do more of it. If it doesn't, well it's about as good as other languages and possibly more dangerous (yay for lack of types -_-)
Back when I did C# I found trying to do functional stuff painful. Maybe it's gotten a bit better, but I recall creating functions being something like
new Func<int> => { stuff here .. }
Or something like that. I found moving to dynamic languages to be a breath of fresh air. I never cared too much about code completion and stuff like that.
Except that this is not working. You have to explicitly type lambdas if you assign them to local variables(or to properties, fields). But I don't see it as big trouble though.
Whoops, you're right. Most of the time I'm using them for LINQ filters or maps, or doing quick and dirty event handler delegates. So basically JQuery-esque usage, except with types.
If pain is measured in keystrokes, then yeah.. functional C# might be somewhat painful.
If you haven't tried it you might consider using F#. It seems to have the best of both worlds. It's got a static type system with functional features, but also a very lightweight and beautiful syntax (heavily influenced by OCaml, fwiw).
Instead of arguing in favor of JavaScript as the default language and software stack we should focus on a standard VM to use the language and libraries we prefer.
Not sure if trolling but... If not trolling, you should always learn how to evaluate what language will be the best tool for the job. If anyone's choice of what language to use is based on a blog post that says "You should use JS" then language choice might be the least of your worries. I'm aware of core contributors of one of the hot new JS frameworks that are swapping out pieces of the back end JS tech for Golang because it makes sense! So this isn't just me pulling nonsense out of a hat.
> it will be the standard language for mobile apps.
For second-class mobile web apps, maybe. But for high-performance native mobile apps that don't waste battery life on interpretation or JIT compilation, plus the overhead of bridging to the native APIs, a dynamically typed language like JavaScript is a bad fit. On iOS, Objective-C has always been compiled ahead-of-time to native code, and so is Swift. Android 5.0 introduced AOT compilation with the Android Runtime. And Windows Mobile has it too, with both C++/CX and .NET Native. Conclusion: All three major mobile platforms prefer AOT compilation, which AFAIK isn't feasible with JavaScript.
TypeScript is probably a better long-term programming tool and is aligned with future EMCA Script specifications.
Back-end I'm torn. I love Restify (Express without the web parts and just the api parts). But I also like ASP.NET Web API a lot too. They both have sizable benefits.
I think it's less about language though than architecture. Microservices and user-driven UX is the future along with stakeholder-driven agile project management.
> Turns out, the amount of work that has gone into making JavaScript awesome surpasses every other language.
I still don't see a Ruby on Rails, Symfony, Spring etc.-like framework for JavaScript in terms of maturity. Sure they are some frameworks, however most of them crash and burn when you want to upload a 1GB file or parse large JSON data arriving via HTTP... or try to extend it.
And I didn't even mention NodeJS's multiple loading and memory limit problem.
Hi, my name is __________ and I'm a mediocre programmer.
I've just kicked off the first 2 weeks of a significant project using only Javascript. This was entirely my own choice. I knew I'd have to write a lot of JS in the browser. So it made sense for me to bite the bullet and try to become as good as I could at JS. Equally I had to make a choice that I believed would work for my client in the medium-term, especially if I was not able to continue with the project at a future date.
This is my perspective (from the intellectual gutter): Javascript is hard to read and hard to reason about. It's also hard to achieve a style that I am entirely comfortable with. It's changing very fast. You learn things on the backend that are years from being universally useable on the frontend. Also: I seem to write so many lines of code.
That said I think I made the right choice. Ultimately the isomorphism argument is correct: at least I'm reasoning about the same kinds of things every day. I just came off 6 months of programming only Elixir and I could have used Phoenix for the backend, but I think I would have found the constant shifts in perspective very disruptive.
Which leads me to my main point: It isn't about the language.
After all, multi-threaded programs in a more conventional language are also very hard to reason about. Shared data is hard to reason about. Immutable data is also hard to reason about (or rather its consequences are hard to reason about). Message passing can also become hard to reason about. Pointers are hard to reason about. Functional composition starts out simple and then...you guessed it: it gets hard to reason about. Once things get to a certain level of complexity, once you get using anything to its full potential you find the place in which it's going to make your head hurt.
And for the plodders among us the answer is: libraries and patterns. Specifically, other people's libraries and other people's patterns.
So my recommendation to anyone that doesn't like Javascript: if you don't have to JS, don't. If you do, at least enjoy the good things:
* Promises: One of those things you only appreciate by trying to do it the other way: http://callbackhell.com/
* ES6: a lot of great features here. Makes an Elixirite feel almost at home: destructuring(pattern matching), arrow functions, generators and iterators
* Libraries: Amazing number of libraries. I have barely had to code one really smart thing myself.
* JSON: Think in JSON all day - now that's nice. Serializing things to Lists, Maps, Tuples and what have you gets old.
And also read books:
* David Herman: Effective Javascript
* Marijn Haverbeke: Eloquent Javascript
* Daniel Parker: Javascript with Promises
* Douglas Crockford: Javascript, The Good Parts (well actually I found this one hard to reason about :) )...
Everybody's fighting about why JS sucks... We know JS sucks. We've ALWAYS known JS sucks. It's not a good language. It's the new PHP. And it will never be good enough to make us all happy.
But you know what? It works... well enough. It's fast... enough. It's simple enough that mere mortals can use it. (Which is a strength, not a weakness!) And now, it works EVERYWHERE. You can get shit done with JS and having good JS experience means you can always find work. Maybe one day I'll work on a magnum opus requiring a "real" language but for now, I'll stick with what gets the work done. Because I'm not a rocket scientist, I'm more like a computer plumber. And I bet most of us fall into that category.
I don't have to like it. But I do have to get stuff done. So I use JS.
1) Web Assembly will make the programming language you use on the front-end an open choice in web development (and, eventually, mobile). Javascript has very poor support for disciplined management of large codebases, and will eventually be abandoned for more sane languages.
2) Technologies like intercooler.js (http://intercoolerjs.org) will minimize the amount of javascript necessary for the majority of web development (and, eventually, mobile) which will allow you to simply choose the best back end technology for your project without concern for matching a front-end language.
65 comments
[ 2.8 ms ] story [ 141 ms ] threadWhat I'd like is a language I can use that has optional typing where all the libraries follow a strict type system but the application I put on top of it doesn't care.
That is the exact opposite of what I get with TypeScript. I'm left with a lot of dynamic mess libraries that I build my typed application on top of.
Steel on top of jello.
Stripped down, functional C with type inference? Yes, please.
Javascript is the C++ of web dev. You bolt a ton of things on top of a shitty language and you hope to obtain a slice of it that is decent in the long run. Except it's still going to be full of terrible quirks and 30 ways to shoot yourself.
I'm sorry, but I don't want this future for programming.
Shitty date/time implementations (unless you're using moment)
Callback hell?
That's just my list for this morning.
Don't know what you mean by this. As for the other things; like I said, getting first class functions right makes those other things unimportant. Are you running into the problems with DateTime that often? I can't even remember what those problems are. I don't doubt they exist, but I think you're over-inflating the importance.
But yeah, if you absolutely want a dynamic language, you have much saner choices with a considerably more robust ecosystem (hello Python).
> I'm sorry, but I don't want this future for programming.
I don't want this present either :)
I think you should start laying off HN, in all honesty.
chortle
Not so long ago they were saying the same about Ruby, and Java before that, and so on down a long and winding history of ludicrous one-language-swallows-the-world predictions.
In this case it's not so much a prediction as an observation of what has already been happening.
It's everywhere at this point.
I'm starting to think theres a JS Bubble forming, inside which people who only ever touch JS and nothing else proclaim that the world and the moon are made entirely of JavaScript.
I've done small-ish projects in Node. There's tons of ways to do JavaScript that your IDE's static analyzers will not like. If you use IIFEs extensively, most of it will not be auto-completed for you. Needeless to say, same thing goes for function signatures -- good luck quickly getting through the parameters and their order (note: it's possible this has changed in the last 12 months).
I like JS well enough -- the functional aspect of strings, arrays, etc. But IDE support is lacking and it makes it hard to retain control as the codebase grows.
While I agree that Javascript has matured a lot, and it has its place in the backend, I strongly disagree that it should always be used. We need to give thought about why we're using it and make it a conscious choice. It can be that its a single language on the frontend and backend. It can be the abundance of developers. It can be it's evented nature. But blindly making a choice without thought leads to a cargo cult mentality.
Additionally, there is no replacement to backend code. We may one day have good enough abstractions to allow us to mostly forget about the backend, but it will still be there. Bugs will arise where we need to understand how it works, and there will always be some sort of API (whether hidden or not) that we need to be mindful of. The web is a client-server system, and we can't forget that.
However, if I "Always default to javascript" then I'm picking Javascript without evaluating any other options.
"Give the community time, and they will come up with solutions to most things that are considered impossible today."
Okay, so JavaScript will be better/awesome in the future. I still don't see why my next project should be in JavaScript.
Every time I try to get into full Javascript, I come across so many things that feel half-baked that I decide to wait it out some more and go back to the tried-and-true tools.
I think that there will eventually be an abandoned javascript library for every noun, verb, and adjective in the English language.
npm modules are not an integral part of the language. It's just an optional add-on that you might explore on your own to get work done for you more easily and more efficiently.
If you're lucky and found a module that fits the bill perfectly for a given project, that's awesome. If not, that's fine too. You can either fork the module and extend it as you like or build a new one from scratch.
I don't know why you would expect to find npm modules that can get the job done 100% for you and all the time?
That's a totally unrealistic expectation and unreasonable.
If everything that we devs need is ready-made and our jobs relegates to only gluing stuff together like entry-level technicians, don't you think that would be detrimental to our profession as a whole as it would be a few clicks away for a bot or an algorithm to automate our jobs away?
Get the job I'm doing done 100% of the time, do the job they are supposed to do 90% of the time I'd like that, constant version churn, API changes, strange incompatbilities between things that are supposed to work together not to mention stuff like browserify/watchify which when they work are great and when they don't a complete pain.
Also makes me chuckle whenever it throws a ENOENT not because I don't know what it is but that a high level original browser dependent language is throwing it and not "No such file or directory" or anything friendly.
npm/node reminds me of the implementation of a server side scripting language implemented solely in JavaScript written by people who have only ever heard other server side scripting languages described to them on a broken radio.
That's like someone after ordering a regular Big Mac meal (burger + fries + soda), he complains that the dessert portion of the meal either sucks or there are too many options available and some are not optimal enough when actually there was no dessert included in the meal in the first place.
Can we get real for a moment here?
npm/node reminds me of the implementation of a server side scripting language implemented solely in JavaScript written by people who have only ever heard other server side scripting languages described to them on a broken radio.
'Everyone is entitled to his own opinion, but not to his own facts.'
The article is "JavaScript as default language and software stack"
I'm saying I don't want to use javascript as my default language and software stack. How do I use javascript on the backend without node and npm? Surely it is doable, but why would I want to? Other languages work great on the backend, they have standard libraries, and they have solid tools.
It's a breath of fresh air even coming off of using python/django for the last few years.
Types are amazing.
var foo = (param, anotherParam)=>{ /* do stuff */};
If you haven't tried it you might consider using F#. It seems to have the best of both worlds. It's got a static type system with functional features, but also a very lightweight and beautiful syntax (heavily influenced by OCaml, fwiw).
It's incredible slow to start a debugging session, making you feel miserable. See open issues like https://github.com/nodejs/node/issues/877
Instead of arguing in favor of JavaScript as the default language and software stack we should focus on a standard VM to use the language and libraries we prefer.
That said, should you learn JS? Hell. Yes!
For second-class mobile web apps, maybe. But for high-performance native mobile apps that don't waste battery life on interpretation or JIT compilation, plus the overhead of bridging to the native APIs, a dynamically typed language like JavaScript is a bad fit. On iOS, Objective-C has always been compiled ahead-of-time to native code, and so is Swift. Android 5.0 introduced AOT compilation with the Android Runtime. And Windows Mobile has it too, with both C++/CX and .NET Native. Conclusion: All three major mobile platforms prefer AOT compilation, which AFAIK isn't feasible with JavaScript.
Back-end I'm torn. I love Restify (Express without the web parts and just the api parts). But I also like ASP.NET Web API a lot too. They both have sizable benefits.
I think it's less about language though than architecture. Microservices and user-driven UX is the future along with stakeholder-driven agile project management.
I still don't see a Ruby on Rails, Symfony, Spring etc.-like framework for JavaScript in terms of maturity. Sure they are some frameworks, however most of them crash and burn when you want to upload a 1GB file or parse large JSON data arriving via HTTP... or try to extend it.
And I didn't even mention NodeJS's multiple loading and memory limit problem.
I've just kicked off the first 2 weeks of a significant project using only Javascript. This was entirely my own choice. I knew I'd have to write a lot of JS in the browser. So it made sense for me to bite the bullet and try to become as good as I could at JS. Equally I had to make a choice that I believed would work for my client in the medium-term, especially if I was not able to continue with the project at a future date.
This is my perspective (from the intellectual gutter): Javascript is hard to read and hard to reason about. It's also hard to achieve a style that I am entirely comfortable with. It's changing very fast. You learn things on the backend that are years from being universally useable on the frontend. Also: I seem to write so many lines of code.
That said I think I made the right choice. Ultimately the isomorphism argument is correct: at least I'm reasoning about the same kinds of things every day. I just came off 6 months of programming only Elixir and I could have used Phoenix for the backend, but I think I would have found the constant shifts in perspective very disruptive.
Which leads me to my main point: It isn't about the language.
After all, multi-threaded programs in a more conventional language are also very hard to reason about. Shared data is hard to reason about. Immutable data is also hard to reason about (or rather its consequences are hard to reason about). Message passing can also become hard to reason about. Pointers are hard to reason about. Functional composition starts out simple and then...you guessed it: it gets hard to reason about. Once things get to a certain level of complexity, once you get using anything to its full potential you find the place in which it's going to make your head hurt.
And for the plodders among us the answer is: libraries and patterns. Specifically, other people's libraries and other people's patterns.
So my recommendation to anyone that doesn't like Javascript: if you don't have to JS, don't. If you do, at least enjoy the good things:
* Promises: One of those things you only appreciate by trying to do it the other way: http://callbackhell.com/ * ES6: a lot of great features here. Makes an Elixirite feel almost at home: destructuring(pattern matching), arrow functions, generators and iterators * Libraries: Amazing number of libraries. I have barely had to code one really smart thing myself. * JSON: Think in JSON all day - now that's nice. Serializing things to Lists, Maps, Tuples and what have you gets old.
And also read books:
* David Herman: Effective Javascript * Marijn Haverbeke: Eloquent Javascript * Daniel Parker: Javascript with Promises * Douglas Crockford: Javascript, The Good Parts (well actually I found this one hard to reason about :) )...
But you know what? It works... well enough. It's fast... enough. It's simple enough that mere mortals can use it. (Which is a strength, not a weakness!) And now, it works EVERYWHERE. You can get shit done with JS and having good JS experience means you can always find work. Maybe one day I'll work on a magnum opus requiring a "real" language but for now, I'll stick with what gets the work done. Because I'm not a rocket scientist, I'm more like a computer plumber. And I bet most of us fall into that category.
I don't have to like it. But I do have to get stuff done. So I use JS.
1) Web Assembly will make the programming language you use on the front-end an open choice in web development (and, eventually, mobile). Javascript has very poor support for disciplined management of large codebases, and will eventually be abandoned for more sane languages.
2) Technologies like intercooler.js (http://intercoolerjs.org) will minimize the amount of javascript necessary for the majority of web development (and, eventually, mobile) which will allow you to simply choose the best back end technology for your project without concern for matching a front-end language.