
JavaScript as default language and software stack - vladaionescu
http://blog.andreipolmolea.com/you-should-choose-javascript/
======
kaendfinger
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.

~~~
arenaninja
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.

------
mercurial
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.

~~~
smacktoward
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.

~~~
s_kilk
> 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.

~~~
Touche
> 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.

~~~
noir_lord
There is a language that has largely taken over the "not compiled" segment but
it's not JavaScript it's python.

It's _everywhere_ at this point.

~~~
Touche
It's not in my browser. It's not in Nginx. It's not not in my database
(Couch). JavaScript is.

~~~
s_kilk
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.

------
phaedryx
"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.

~~~
notNow
Can you please enlighten us and name some of those "half-baked" features you
frequently encounter in the language?

~~~
phaedryx
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.

~~~
notNow
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?

~~~
noir_lord
> 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.

~~~
notNow
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.'

~~~
noir_lord
'A witty saying proves nothing.' \- Voltaire.

------
voidr
> 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.

------
omouse
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 -_-)

------
interdrift
C# dev here. Coming from statically typed language + dynamic support it just
doesn't make any sense to switch to full dynamic.

~~~
Touche
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.

~~~
douche
Lambdas and LINQ has made this much simpler:

var foo = (param, anotherParam)=>{ /* do stuff */};

~~~
erdeszt
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.

~~~
douche
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.

------
nstart
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.

That said, should you learn JS? Hell. Yes!

~~~
eterpstra
Which hot new JS framework, and what part?

------
wslh
It seems the author forgot to mention one area where server side (read
NodeJS/io.js) JavaScript really sucks: debugging.

It's incredible slow to start a debugging session, making you feel miserable.
See open issues like
[https://github.com/nodejs/node/issues/877](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.

------
ghc
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.

~~~
kaendfinger
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.

------
lojack
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.

~~~
erikpukinskis
"Default to JavaScript" is not "use JavaScript".

~~~
lojack
Yes, I agree, if I "Default to javascript" then I'm evaluating options and
picking Javascript in the absence of a clear choice.

However, if I "Always default to javascript" then I'm picking Javascript
without evaluating any other options.

------
adamwong246
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.

~~~
yongelee
I want to enjoy the programming language im working with though. I don't enjoy
js, but thats where all the work is! makes me sad

------
Dirlewanger
I love when the satire just beats you over the head.

------
mwcampbell
> 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.

------
carsongross
I do not agree.

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](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.

------
ChicagoDave
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.

------
vans
Ahah, nice joke :)

------
scandox
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/](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 :) )...

~~~
vans
Nice ending ;-)

------
zaczac
don't waste your time doing thing big in javascript.

