
Why Learning Angular 2 Was Excruciating - MilnerRoute
https://hackernoon.com/why-learning-angular-2-was-excruciating-d50dc28acc8a#.p2dy3kxah
======
janfoeh
I've said it before here and I'll say it again: the JS ecosystem is moving in
the wrong direction.

Sometimes I feel that with Javascript, we developers have taken something that
wasn't ours, and we're in the process of destroying the best thing there ever
was about it.

One of its best qualities used to be that you could have absolutely no idea
what you're doing, read a few bad tutorials somewhere on the web, mash your
head onto the keyboard and end up with something horrifying that was
nevertheless close to what you wanted to achieve. It was beautiful,
egalitarian. Like the web is supposed to be.

I've spent quite a bit of time on Stackoverflow, coaching people who you would
not call developers (nor would they themselves) on how to do that one tiny
thing they wanted to add to the site for their bakery, yoga studio or blog.
And almost got it working themselves. I know of no other language that can
tell a similar success story, with that high an impact.

Just insert that <script> for that jQuery plugin here and modify that
initializer over there with a vague understand of how it needs to be adapted
to your situation. Voilà!

But we couldn't let that stand, could we? Because what works for Alice and Bob
doesn't work for somebody writing that 200.000 line image editor or CRM in JS,
and let's face it, that's what the web is about.

So here we are, the single <script> tag having been replaced with compilers,
transpilers, five mutually incompatible build systems, three different module
systems in God knows how many implementations, frameworks changing their API
every ten minutes and five thousand lines of NPM module code to be installed
for even the simplest of tasks.

We did it, gals and guys! The web is safely back in the hands of full-time
professionals (with Hindu cow-like frustration tolerance). Where it belongs.

Bah.

~~~
untog
jQuery isn't dead - they're still releasing new versions. You can still do
everything you used to be able to. But now you can also do _more_ \- you can
sensibly modularise your code. Virtual DOMs bring huge performance boosts with
very little work.

IMO, the JavaScript ecosystem has matured. Sometimes in weird ways that aren't
great, but it's still better to have an irritating package manager than no
package manager at all. But there's no price to be paid here - if you don't
want to use any of it, you don't have to.

~~~
Zelphyr
The problem is, it has become popular in our industry to equate new with
"quality". So, while you're correct that jQuery isn't dead and in fact is more
mature, there are too many who won't use it almost _because_ its mature. Its
not the new shiny that it once was. But frameworks like React and Angular are
very shiny. Even though, in my opinion, they're quite simply a mess.

~~~
untog
I think there is an element of people using things because they are new and
shiny, yes. But plenty of people use React and Angular over jQuery because
they make 1000x more sense when putting together a large web application with
multiple developers contributing to the codebase.

~~~
janfoeh
Sure, for larger projects a good, well-thought out and consistent framework is
a godsend. No doubt about it that plenty of people make very good use of the
frameworks and libraries at our disposal.

But on the other hand I cannot count the number of times I've seen Angular
included for a simple contact form with validation on a static site, React to
render a single trivial dynamic list or a nice, but basic JS lib that only
works in module form via NPM exports.

Sorry if I sound like a fortune cookie, but it's true - if all you've got is a
hammer, everything looks like a nail.

Since 2001 or so, I can count on three fingers the number of variable
collisions I have experienced in small- to medium scale projects. That I as a
newbie now have to understand and manage various module systems in order to
embed a lightbox on my site is a huge jump in complexity for a gain that is at
best negligible in practice.

And while you and I probably have worked on some higher-complexity use cases,
I think we would be kidding ourselves if we assumed that this constitutes the
majority of the web.

Because that's not Facebook-scale, it's the dude around your corner selling
dishwashers and reparing washing machines, trying to get his inventories's
prices from an Excel sheet onto his page with a minimum of fuzz.

------
jkkramer
It's interesting to contrast how Google and Facebook both approach open source
for the web.

Google tends to release code and promote it without really using it much
internally first. Documentation is prolific but confusingly organized and
often fragmented among several versions simultaneously (cough, Google
Analytics).

Facebook, on the other hand, actually seems to use their code before releasing
and promoting it. Look at how they handled GraphQL: spec and reference
implementation released a year ago, clearly labeled as a "Technology Preview".
A lot of design work went into it before that, informed by the problems of
internal product teams. Only a few days ago was it promoted as ready for
production. The spec hardly changed it the last year. Documentation is good,
and they work with the community to improve DX.

Why the difference? Hard to say, but my feeling is that there's a more direct
link between Facebook's product-driven open source work and their bottom line.
There are other startups constantly nipping at their heels, so they need to be
on their game product-wise. Better code -> better products -> profits.

Google is largely impervious in the search and ad space, which is their cash
cow. It almost doesn't matter how good or bad their other products are. The
company is not at risk. Their open source work reflects that.

~~~
jbigelow76
_Google tends to release code and promote it without really using it much
internally first._

According to Brad Green, the Engineering Director over Angular, Google
AdWords, Google Fiber, and some internal tools are all built with NG2. AdWords
is kind of big deal to Google.

Edit: source for AdWords reference,
[http://angularjs.blogspot.com/2015/11/how-google-uses-
angula...](http://angularjs.blogspot.com/2015/11/how-google-uses-
angular-2-with-dart.html)

~~~
robryan
They recently rebuilt google merchant center in angular.

------
plexicle
Your first foray into web development and you picked a large, unfinished (it
wasn't final) framework to learn with? Then you are complaining that there
were breaking changes you had to deal with?

I get your beef with the ecosystem, but this is a very unfair knock on Angular
2. Angular 2 was not the problem here at all.

Am I missing something obvious?

~~~
WalterSear
Unfinished? How about never finished.

>Angular 2 is going to have breaking changes only every 6 months from now on.
So the next one would be around February with Angular 3. Yes exactly, they’re
also finally switching to semantic versioning which is a huge win in my
opinion.

IMHO, breaking changes every six months is the recipe for an shitshow of an
ecosystem.

[http://juristr.com/blog/2016/09/ng2-released/](http://juristr.com/blog/2016/09/ng2-released/)

~~~
RKoutnik
One other project comes to mind that also updates every six months: Ubuntu.
Last I checked, their ecosystem was doing fairly well. I wouldn't consider
Ubuntu "unfinished" unless we're talking about the state of all software
everywhere.

~~~
moloch
Ubuntu also has LTS releases for this exact reason.

~~~
seangrogg
Once the framework has actually shown some degree of maturity I don't think it
would be unfair to ask the Angular team for an LTS version of Angular.

------
stevebmark
To me this is still why React feels like the first front end UI framework that
got it "right." It stays close to vanilla Javascript. There's a tiny API
surface area to learn, and the rest is vanilla Javascript classes and
functions. Angular's API, and apparently Angular 2.0's API, is still large,
and strays far from vanilla Javascript

~~~
stupidcar
Tell me about it! Literally all you need is React.

Oh, plus react-router for routing, I guess. And Redux, obviously. Plus react-
router-redux to link them together, and react-router-scroll for scroll
history. Also react-intl to handle internationalisation. And react-helmet to
do document header stuff. You'll need to use immutable as well, _obviously_ ,
so you'll need redux-immutable. And redux-saga. Hmm, you'll definitely need a
selector library like reselect. Better throw in reactcss too. Gotta get them
inline styles going!

Anyway, just those and a couple dozen other libraries and you're good to go.
Then once you've set up Flow types, Babel compilation, isomorphism, bundling
with hot module reloading in Webpack, linting and testing, you've got a
rockin' React app. Easy as that!

~~~
LouisSayers
Lmao, this is exactly how I've felt, and why I'm using ordinary js with
closures and a bit of jquery for the time being while I get up to speed and
figure out wtf is going on.

"Javascript the good parts" has served me well.

~~~
bombtrack
If what you're trying to accomplish is feasible and maintainable with
"ordinary js ... and a bit of jquery" then using a full React+Flux stack like
the OP outlined is complete overkill. If someone has experience with those
libs and tools then they'll probably use it even for trivial projects. However
that does not mean it's prescribed for _everyone_ to use _every time_ they
need to write a bit of javascript functionality.

I really wish people would qualify what they're trying to accomplish when they
bang on about things being "needlessly complex". Maybe for what they're doing
it totally is and they shouldn't be distracted with React, Flux, Webpack, etc.
There's nothing wrong with that. However, when taking on a project where these
sorts of things are immensely useful, it's nice they exist.

~~~
LouisSayers
Sure, but tell me what isn't feasible? Ok, I'm not creating photoshop in a
browser, but there have been some non-trivial highly interactive apps I've
built and they are still modular and serve their purpose well.

I'm not saying we shouldn't get on react - I'm sure in the end it will serve
myself and others well, but it's a bit of a headf*ck trying to figure out the
whole ecosystem, and how to write a good solid app in it. For anyone that
tries to say "but it's only react with x" \- No it's not! Not for anyone that
cares about the quality of their app, theres a whole heap to learn.

And I am learning, but at the same time I'd rather create a well designed app
with the crummy tech I know than a crummy app in something I just haven't
figured out yet. Luckily I'm doing my own thing so have that choice.

------
seangrogg
I find it hard to take this article seriously when it's about issues with a
framework:

* that was still in beta/upgrading to the official version that was released last week

* that was redesigned from the ground up by a company that is pretty intent on not doing things in JavaScript (see Dart, TypeScript docs but no ES5 docs)

* whose original announcement of versional incompatibility was one of the major reasons its competition became popular

* has clearly been attempting to frankenstein a lot of ideas from other libraries/frameworks in awkward ways

The JavaScript community definitely has warts - I have zero issue with that
statement. But the real problem comes from developers from other language-
communities making blanket statements about the JS community while using tools
that are clearly marked as unstable when they could've just as easily
(actually... much more easily) written said app with any library/framework
that wasn't released _literally a week ago_ or even used raw JS - an API that
hasn't had many breaking changes or compatibility issues in quite a while.

------
lemmsjid
I've found that learning new technologies from first principles is better than
starting with frameworks, unless you're willing to put up with a lot of
ambiguity. For example with Javascript I'd start with basic manipulations
(e.g. get to know the prototype model, the debuggers, the DOM, etc.), work up
to a make-life-easier library like JQuery, then try a framework. It may depend
on your learning style, of course.

~~~
kelvin0
This is exactly the path I've taken. I figured if I start out with
<ShineyNewJSFrameworkMVC> right off the bat, and not understand the
foundation, I'd be screwed in the long run. My reasoning is that once I grasp
JS's quirks/ins/outs (I'm looking at you 'this'), well I'd be ready to see the
light and better choose a framework. So far, I think ReactJS nailed it, but
keep in mind I am fairly new to Web Dev (coming from PC/Console/C++ world) so
YMMV. Also, I would like to thank the good folks at Twitter for Bootstrap, I
don't know how my frontend would look like without it!

~~~
Udik
You'll certainly have a hard time if you think you can use any javascript
framework without knowing javascript itself. Not understanding how 'this'
works is like not understanding how classes work in an oo language, and no
framework will ever hide that from you.

~~~
kelvin0
Although what you mention seems obvious, you have to remember that is quite
easy nowadays to cobble up some functionality with minimal knowledge by
applying ready-made 'recipes' and following the ton of tutorials available in
any language/framework (especially as an experienced programmer). The gotchas
become painful when you start to dig through without prior knowledge of the
nuts and bolts for debugging/profiling/scaling your application.

So I completely agree with you, but I've seen many programmers whip up
something in a weekend and not be able to extend the functionality of their
app because they had no idea how everything fit together in the 'magical
framework' of their choice.

------
robin_reala
Sorry, but sometimes I feel like the only sane person in the madhouse. It’s a
blog! It’s literally just an index page and some display pages! Why could that
possibly need 100s Kb of JS to run it? Of course you’re going to have trouble,
you’ve picked a JCB to do a screwdriver’s job.

~~~
mkozlows
The point is to use the blog as an example to learn the tech, typically.
Picking a familiar, not-too-big problem to solve is a good way to understand
how new tech works.

~~~
nanny
A to-do list would've been a better choice. It's the classic choice for
working with SPA frameworks. I thought the same thing as your parent's
commenter when I read the word "blog".

~~~
bicknergseng
To be honest, TodoMVC is the idea-that-needs-to-die™ for SPAs. IMO, if all the
framework needs to be able to do is described by TodoMVC, you probably don't
need a framework at all. It probably takes way less time to write a todolist
in a vanilla language than to learn an entire application framework to build
it.

~~~
barryhoodlum
And you can write a simple and clean TODO app in any framework. You really
need to see how it manages complexity to evaluate it properly.

------
dkarapetyan
I'm just gonna leave this here: [http://aurelia.io/](http://aurelia.io/).
Aurelia is truly a professional operation.

~~~
DigitalSea
As someone who has been using Aurelia for over 12 months now, I am happy to
see someone post this. A great framework that hasn't really had any major
breaking changes, even when it was alpha, then beta and release candidate.
Keeping it up-to-date has been no effort at all and I have been building with
it since it was basically announced.

The thing I find funny about Angular 2 is all of the breaking changes they
made during the release candidate. The whole point of a RC is no breaking
changes and just bug fixes to get it stable before final release. They rewrote
the router component 3 times alone. Updating from each RC release in itself
was a nightmare for many.

The whole misconception that because Angular 2 is Google affiliated it is the
best framework around needs to die. Angular 2 is a Greentea oriented framework
that isn't built for the public and first and foremost, for Google's own
internal needs first.

Aurelia is incredibly underrated and many of the developers I know who come
from a background in Java and .NET where concepts like dependency injection
are very important absolutely love Aurelia for introducing those concepts in
an easy to use and understand manner.

~~~
adamnemecek
What do you mean by "greentea oriented framework"?

~~~
stickfigure
Greentea is the codename of the internal CRM application at Google that
spawned Angular.

------
SwellJoe
I've pretty much had the same experience with the JavaScript back end. The npm
ecosystem is overwhelming, on several fronts. In many ways, it's great:
70,000+ libraries available with one command. But, my gods...grokking how they
all interact, getting a stack of several libraries to work together, and
rolling that stack into production, are astronomically more complicated than
any other language/platform I've ever used. It makes the Java world seem
simple.

It may settle down with time. I hope it settles down with time. JavaScript has
evolved a lot just in the past couple of years, and so it feels like everybody
kinda went, "Oh, wait, we're doing all of this wrong, we have to start over!"
But, the ecosystem has done it several times now for almost every problem that
needs solving, and it's starting to get old. At some point, shouldn't things
settle on a Best Practices solution that is stable and predictable? I mean,
not for everything, obviously...but, how many times and ways does, say,
routing, need to be solved in incompatible ways?

I dunno. I try to just be excited about all of the amazing building blocks
what I get for free when I buy into the JavaScript ecosystem...but, "free"
starts to look really expensive when it is so painful to deploy it and keep it
running reliably over a period of months and years.

~~~
fernandopj
IMHO the Node/npm ecosystem is far more stable than Angular 1&2/bower.

Node core modules have been remarkably stable since 0.12.x, so most of npm
packages one would install are libraries, with very narrow responsibilities. A
few popular frameworks have also been fairly stable and well understood
(Express, Bluebird).

With Angular, you also have a myriad of libraries available to you, easily
pluggable via Angular DI, but the very core framework has changed a lot... so
in the Javascript frontend, things are much further away from a "battle-tested
best practices" than the backend.

~~~
flukus
> IMHO the Node/npm ecosystem is far more stable than Angular 1&2/bower.

I can't say if it's more stable than bower, but IME it's not stable at all. My
simple blog static site generator breaks every time I write a new blog post.

~~~
pitaj
What do you mean by breaks?

~~~
flukus
I mean the npm dependencies are broken.

------
morinted
Honestly, upgrading npm modules is never fun. This person is trying to learn
the language at the same time -- you just can't expect that to work. You want
to shrinkwrap / freeze your dependencies as soon as you can, and upgrade when
it's clear that you are missing out and the effort to upgrade is worth the
work that it takes to update.

I am using deprecated libraries at work. I just recently upgraded to React
Router v2 when they are already gearing up for v3 (and refactoring for v4).
It's just part of how the ecosystem works. We are lucky that a side effect of
its business is the abundance of useful libraries.

~~~
charrondev
Upgrading dependencies can be a total pain in the ass, and in the end is why
I've been so frustrated with TypeScript. My solution in the end was to just
ignore typing for any 3rd party libraries that don't have them to begin with.
As nice as a d.ts file, dealing with all the type definitions that need
updating along with all the issues with updated the dependencies in the first
place was just too much.

I had a pet project with react and redux that I didn't touch for a few months
as I was busy with other things. I came back to it recently and there are new
major version of: react-redux, redux, react-router, webpack and various
plugins, react-router-redux, react-hotloader, babel, and I'm sure a couple
other things. It was a PITA to set up in the first place, and just a few
months later, it all needed to be reconfigured.

------
fabian2k
I never used Angular 2, but that sounds like the biggest issue is a release
candidate that should have been called a beta or alpha release.

I sometimes tend to try out beta releases when learning something new and
interesting, but that does tend to backfire now and then when it's unstable
enough that I can't tell if I'm doing something wrong, the framework is buggy
or the documentation is simply outdated.

~~~
fixermark
In general, if I understand correctly, "Release candidate" implies "unstable."
The emphasis is on "Candidate," not "Release," i.e. "This bundle _could_ end
up being the final version, but it probably _won 't._"

~~~
tomnipotent
RC absolutely means non-breaking API changes. Bug fixes yes, but the API will
be stable.

~~~
dragonwriter
It does not "absolutely" mean that.

It certainly means API changes are not anticipated, and that there should be a
very significant problem with an API to lead to an API change at that point;
certainly one would hope that fundamental flaws in an API that make it
unsuitable for release would be identified well before an RC.

But its certainly possible to have reasons to make a breaking change from an
RC (e.g. -- not necessarily relevant to a front-end framework, obviously -- a
security vulnerability uncovered that reveals a critical flaw in the logical
design, rather than implementation, of an API.)

~~~
Udik
> its certainly possible to have reasons to make a breaking change from an RC

Sure. After which you issue a new RC, not the final release.

------
adrianpike
I, too, would probably have a bad time if I was trying to learn a framework as
it was being built.

~~~
lghh
That's sort of the problem that the article was addressing. By the time things
have been built, they are old news to the JS community - or at least those
that you see on HN, Medium, blogs, etc. If you mention learning Angular 1
anywhere you get shouted at that it's old and should not be used and to
instead look at Angular 2 and React. By the time those are established, it'll
be on to something else.

And that isn't just the case for frameworks, it extends to tooling as well. JS
is a mess - one that I am involved in first hand - and it's hard to find
stable footing.

~~~
vertex-four
On the other hand, frameworks like Ember are still chugging along quite
happily, and swallowing up any actually good ideas the rest of the community
has. For example, isomorphic apps spawned "fastboot", where with one plugin
you can generate an isomorphic app from your existing Ember project (with some
tweaking), talking to your existing API server.

~~~
flukus
Knockout is stall my goto, ember seems pretty similar to this. I still don't
see what angular react bring to the table that isn't mush simpler with these
tools.

------
jbigelow76
I hear the author's pain. So much churn as I attempted to keep pace with RC
changes. I'm sticking with NG2 cause for the rare times I was writing app code
instead of fighting with NPM I enjoyed the developer experience...

...except for Zone.js errors. Everytime I saw a zone.js error in the call
stack my brain perceived it as a giant middle finger rendered in ASCII in my
console.

------
ausjke
I have been wondering why a one-person project like vue.js seems to be saner
than the big guns such as angularjs and even react-ecosystem?

I have been trying all three recently back and forth and now leaning back to
vuejs while waiting for its 2.0 release.

~~~
rmason
I was an Angular fanboy but one look at version 2 had me reconsidering. I was
introduced to Vue at a local JS developers meeting.

I'm having little problem learning the language. My problem was trying to bite
off the CLI - Webpack is a huge learning curve for me.

From what I understand in Vue 2 they're tackling that by having two different
versions of the CLI, but I haven't checked it out yet. Vue listens to their
developers and really does try harder.

------
kindlep
I think as you yourself have said, it's the pain that comes with using
something that's currently in alpha/beta/etc. True, Google's approach is
different, but the end product is something that has gotten so much input from
the wider community, as apposed to how FB does it. Now I'm not saying one is
better than the other. I'm just saying it's the price for depending and using
some thing thats still literally being worked on. As far as I know, thats
pretty much a wavier on ease of use.

As far as your other conclusions around how this sort of problem exists in
general in the JS community, I think you are wrong :) That's like me saying
the Java community is chaotic because I experienced problems installing Java.

Unfortunatly, I think you may have bitten off more than you can chew with
jumping in to web development with an in-progress framework which is also
using completely new build/development workflow. But I guess the rewards are
worth it since you really are at the bleeding edge :)

------
andrewclunn
The best thing about Angular 2 is that Angular 1 is now stable. I say this as
a web developer currently coding apps in Angular 1 for production. This is
gonna be a python 3 moment all over again.

~~~
mrits
I liked Angular 1. It only took a few days to get the hang of it. If Angular 2
or React are really the future of front end then I'm not going to go back. I'm
happy doing some backend dev in Go right now. After I finally figured out all
the parts of modern front end development I was already sick of it all.

~~~
Ygg2
I hate Angular and how it makes simple code hard to debug.

Not to mention stupid behavior, like Angular app behavior depend on order of
components clicked.

------
heisenbit
NPM and semantic versioning allows to manage all the dependencies. However the
fine granular nature of js packages, the large number of dependencies, lack of
governance and possibly discipline result in an experience that is very
different from the Java environment.

------
georgefrick
I'm going to cry foul. Lines like "has a umd now. whatever a umd is.... "
Stack Overflow copy pasta developers. If you're an associate level developer;
the project should be setup for you. If you are above that, you should
understand some of the internals and build tools to the point where you are
comfortable wiring them.

Also, this has already been discussed; we get it. RC5/6/7 sucked for everyone
(well, except those of us who were eagerly waiting for forms 2.0). Must we do
daily "omg rc5 was painful" posts?

The change to ngModule took 15 minutes btw, more if you count all the code you
got to _remove_ from other components.

------
oferzelig
I don't get how come this item has received (at the time of this writing) 204
upvotes, whereas an earlier item on the very same blog post only received 6:

[https://news.ycombinator.com/item?id=12529981](https://news.ycombinator.com/item?id=12529981)

------
wstrange
I'd urge folks to give Angular Dart a try. It avoids much of the pain of
Javascript and Javascript tooling.

------
crispyambulance
Honestly, what framework (web or otherwise) has ever NOT been a complete CF to
get started with-- especially when one is "winging-it" by themselves doing new
things using new tools?

How much frustration is "normal"? How much "confusion" is normal? I say A LOT
of both.

------
JohnnyConatus
TL;DR - developer learns the meaning of Release Candidate or rather...does
not:

"To be fair, I have been using versions of the library that have thus far not
been officially released. Maybe, you say, it’s my fault for trying to download
and use a version of the library that is still in alpha/beta/release candidate
and expecting it to work and be relatively easy to use. Perhaps you are right.
But, considering the fact that hundreds of thousands of developers are already
using Angular 2, we should ask ourselves the question: is it responsible to
release libraries that are still very much a work in progress?"

They told you it was an RC, but now that a lot of people have started using
it, you want them to no longer treat it as an RC. (And like a true whiner who
likely will never contribute a single line of code, you want this all for
free, of course.)

~~~
olavgg
A release candidate is NOT supposed to have breaking changes.... its a friggin
"release candidate".

Projects with lot of breaking changes for minor releases should raise red
flags, so steer away! Instead of wasting valuable time being bleeding edge,
take a deep breath, turn your focus 180 degrees and say to yourself: I think
will check it out in 5 years. There are a lot of other great, stable and
mature web frameworks out there.

~~~
dragonwriter
> A release candidate is NOT supposed to have breaking changes....

A release candidate isn't a release, and the release may have breaking changes
from the RC, and obviously an RC of anything that would be a semver major
release may have breaking changes from the previous actual release. So, in
either direction, an RC may have breaking changes.

 _Ideally_ , the last RC should not have breaking changes between it and the
actual release, but we wouldn't need a "candidate" if we knew things would be
ideal.

~~~
olavgg
No no and no. Breaking changes are not ok, not even slightly!

It's not acceptable after an alpha release, It's especially not acceptable
after a beta release. And it is offensive against developers to have breaking
changes from the first release candidate and onwards.

Even for major releases, breaking changes is a VERY BAD thing. But sometimes
it is unfortunately unavoidable.

------
Zyst
I was reading and stopped half way, it really comes across as disingenuous
when you yourself picked an ecosystem that wasn't stable, then the main
complaint in the article was about the lack of stability and how the
JavaScript ecosystem "Sure is crazy!".

I seriously do not understand what your expectation was.

------
shitgoose
now you understand how some of us feel about Java... ironically, JS is just a
natural evolution of Java, taken to a logical conclusion, so to speak.

~~~
aikah
You forgot an important difference between JS and Java : the tooling is
inferior. Sure you can use Typescript which makes thing a little bit better,
but good luck with out dated type definitions or libraries that do not have
type definitions, good luck with templates can't be validated ( forgot some
directive ? misspelled a component name ? too bad you're fucked ... ). Java is
verbose but there is a fairly large number of tools and IDE that make
programming painless. JS on the other hand, good luck maintaining those 1
million LOC codebases ...

~~~
shitgoose
this is all true, but i think the problem of JS is not the lack of generics
and types, but the mindset - an honest conviction that one should pile up one
layer of code on top of another like there is no tomorrow. this is the common
trait between Java and JS developers. the sheer complexity of the system is
the problem, not tooling. old farts like me think that complexity is bad and
we try to avoid it at all cost. young generation thinks that complexity is
_good_ and try to increase it at every opportunity they have.

------
resmote
jQuery Mobile got it right. You can have a powerful, RWD site and barely have
to muck with the JavaScript nightmare.

------
iLemming
keep calm and learn Clojurescript. it will make you happy, I guarantee it.

------
carapace
"2.0.0-alpha.8–2"

