
JavaScript is not suitable for large web apps - superasn
http://blogs.adobe.com/bparadie/2012/05/07/the-pew-pew-manifesto
======
marknutter
This is more of a rant against dynamically typed languages than against
javascript itself, and making the argument that dynamically typed languages
are not suitable for large web apps is a difficult (not impossible) one to
make. The author also complains about some javascript projects being split up
into enough files, which is hardly a side-effect of using javascript. The
author inherited what sounds like a pretty disorganized javascript application
and is using it as their real world example for why javascript shouldn't be
used to write large web apps. In fact, almost everything in the post is
anecdotal or subjective.

~~~
mistercow
I also find objections like the "createBunnyOrToaster" antipattern to be
really, really uncompelling. You don't need a static type system to make sure
that your functions are sane and consistent, and you don't have to be John
Resig either.

First of all, put a comment at the top of your function that says what to
expect about the return value. You should be doing this anyway because the
return type alone is often not sufficient for future programmers reading your
code.

Secondly, every time you write the word "return", look up at the top of your
function and make sure you are in accordance with what you said the function
would do. If you end up with a paragraph comment about what the return value
will be like, refactor.

~~~
munificent
> You don't need a static type system to make sure that your functions are
> sane and consistent, and you don't have to be John Resig either.

Right, and you _can_ do structured programming in assembly. But when the
language or tools don't help you do that, there are examples like the one the
author points out where developers don't.

Don't mistake _utility_ (what _can_ be done) for _usability_ (what is _easy_
to do). Usability always matters.

> First of all, put a comment at the top of your function that says what to
> expect about the return value.

I want a language that gives me a nice pleasant syntax for doing that.

> Secondly, every time you write the word "return", look up at the top of your
> function and make sure you are in accordance with what you said the function
> would do.

As a programmer, you should be trained that when you see "every time", you
think "automate this". If you and everyone on your team and everyone who has
ever been on your team has to remember to do something every single time, your
code will accumulate a pile of instances of forgetting.

Fixing that is exactly what tools and languages are for. It's a hell of a lot
easier to make a disciplined tool than a more disciplined programmer. (And
when you _have_ made a more disciplined programmer, they typically evidence
that by asking for more disciplined tools.)

~~~
mistercow
_> First of all, put a comment at the top of your function that says what to
expect about the return value.

I want a language that gives me a nice pleasant syntax for doing that._

And I want a magic pony; but as I said, declaring the return type doesn't tell
users anywhere near all they need to know in many cases. Truly self
documenting code doesn't exist, and will probably never exist. And since you
can't usefully discuss the return value without implicitly disclosing its type
in the comments, declaring the type in the code is redundant.

Now granted, there are a few nice features that you get in terms of debugging
by declaring the type in a way that the computer can read. But I don't think I
have personally ever actually run into a bug in a dynamically typed language
that would have been avoided by a static type system.

Conversely, there are some nice things you can do when the compiler isn't
breathing down your neck to make sure that all of your types are consistent.
If we had a static type system that allowed me to do elegant, type-agnostic
things without getting in my way, that would be lovely. Haskell comes close,
but even it falls short of the ideal. Ultimately I have never found the trade
off to be worthwhile.

 _As a programmer, you should be trained that when you see "every time", you
think "automate this"._

I think that's pretty specious. You do need to consistently check to make sure
that your code matches your comments and documentation. You simply can't
automate that because humans and computers do not speak the same language.

~~~
hatsix
>And I want a magic pony;

This magic pony exists. That's what the author is trying to say. You can write
magic pony code, and it can be run as JavaScript. Magic Pony -> JS Conversion!

Also, the OP doesn't have an issue dynamic languages as much as weak typed
languages. It just happens that JS is weak and dynamic, while AS is strong and
static.

Having switched between Java, ActionScript and JavaScript for the last four
years, I can assure you that bugs happen all the time in weakly typed
languages that wouldn't compile in strongly typed languages. Sure, it doesn't
make it past refreshing the browser, but it's not uncommon for a coworker to
check in changes to a JavaScript class that completely breaks a part of the
application that the dev wasn't thinking about.

For instance, I've seen return objects switch from strings to ints because of
how the strings were concatenated (return "Item " + x/ _returns string_ /; ->
return x/ _returns int_ /;). Somewhere else in the function it returns early
with "". Now you have other functions in other classes that check
someFunction().length... error... sometimes...

The point is, you now have to write unit tests to check the TYPE of each
value, and in many cases, it's not easy to tell. To check if an item is an
array in JS, you have to do: Object.prototype.toString.call(obj) === '[object
Array]'...

Since this checking needs to be done anyways, I'd rather it be done by the
compiler rather than by a dev remembering to write a test for each
possibility.

~~~
marknutter
> but it's not uncommon for a coworker to check in changes to a JavaScript
> class that completely breaks a part of the application that the dev wasn't
> thinking about

You don't need to write unit tests to check the type of each value, you just
need to have a decent set of integration tests to make sure you aren't
breaking other parts of the app. If errors in the browser after a refresh
don't help you catch it, failing integration tests will. This is how we do
things on my large scale javascript project and it works out just fine; we
have development challenges, for sure, but weak/dynamic typing issues is not
one of them.

~~~
markokocic
The point still stays. Why having to write even integration test for something
that can be easily checked by compiler. Better focus on writing tests that
cover functionality instead of making sure return types are correct.

------
dxbydt
For a certain definition of "large" and for certain domains ( especially
finance ) his argument is very, very valid. 200 average developers working
with GWT->JS are anyday going to be more productive than coding native JS to
get the same functionality. This isn't anti-JS...end of the day if you are on
the web your code is JS. Thing is, how do you get there - do you hire 20
pricey smart JQuery guys, or 200 average Java pgmmers. Pls go to a bank or any
large finance shop - TONS of Java programmers, very familiar with navigating
through verbose boilerplate Java code, very familiar with coding up some risk
function or pricing algorithm in Java...mostly by abusing the heck out of the
optimized collections library and its search & sort algos :) But so long as
the damn pricing function prices corectly, eveybody's happy. So now all that
stuff has been built & is sitting there as desktop apps with dirty swing UIs.
1000s of Java classes. Literally tens of 1000s. Nobody is going to rewrite it
in JQuery/JS/coffeescript => No money, no mandate, no manpower, no expertise,
but primarily no need to do so. GWT has captured precisely that sweet spot.
First get rid of the fancy swing widgets - stick to simple GWT textareas &
lists & panels & checkboxes & stuff. Then get rid of Java collections -
replace with GWT lightweight collections. Then check some corner cases. Then
compile to JS & optimize & you are done. The same shit now works on the web, &
if its buggy you just debug your desktop app because they are essentially
using the same logic. This is just how it is done in large financial shops.
You are simply not going to hire JS folk & teach them financial algos & then
get them to code those up in idiomatic jquery...takes too long. Just train the
existing Java folk who already have the domain expertise to move from
fullblown Java + swing to lightweight collections + GWT. It doesn't have to be
pretty. We are not web shops or consumer frontends...this will still be
accessed by people inside the bank...only not by downloading applets &
standalone java apps, but via native JS.

~~~
heretohelp
>20 pricey smart JQuery guys

See, this is how I knew you knew nothing about JavaScript.

My bets, you're a manager that manages shitty Java coders who "used to code"
and is an obnoxious know-it-all.

Scale of 1-10, how close am I?

Edit:

From your website: "currentlly: BofA" (sic).

Feeling pretty warm on my bet so far.

~~~
malandrew
So so true. If you are hiring "pricey smart [sic] jQuery guys" then you're
probably doing it wrong. You need to be looking for solid software engineers
that know javascript well. If the developers you are hiring think (jQuery ===
javascript) and can't explain the difference between classical and prototypal
inheritance , then you're screwed before you even begin.

~~~
tmzt
Funny, the exact same question came up today. I'm curious what the actual
difference between the two is as it's not apparent. (I use a mixture of
function prototype with the extends pattern and CoffeScript which exports a
function exporting a function.) From what I can see they behave the same as
long as you follow the same pattern when writing a subclass.

~~~
malandrew
The main difference in many cases is memory usage. When cloning in prototypal
inheritance, you point back to the prototype's function, unlike classical
inheritance where you are copying methods on every instantiation.

------
neilk
There are reasonable objections to JavaScript, but this is inane.

He uses an example of someone committing a classic mistake in software design.
This error would be the _same_ in JavaScript or Java. I'd like to see how his
ActionScript translation magically fixed it.

However, the remedies for the mistake differ in each language.

It is somewhat difficult to fix it in Java's statically typed straightjacket
(which I assume is similar in ActionScript). The easiest answer might involve
a Feedable interface. I looked this up and it's not clear if ActionScript
classes can implement multiple interfaces. So if you want your Toaster to be
both Feedable and Heatable, get ready for interfaces extending each other.

In my experience most Java developers don't even do that. They don't think
about revising their approach to the problem. They going to write a method
that does what they want in the class that they want, come hell or high water.
They'll create the BunnyOrToaster class which has methods which all contain
if/else clauses testing if this in 'bunny mode' or 'toaster mode'.

In a language like JavaScript, you have other, simpler options, and often more
powerful ones. I don't know for sure, but the mere fact that there are fewer
tricks to learn might mean that it's better for naive to intermediate
programmers. The typical JS way would be to rely on duck typing. If that
disturbs you, you could implement a 'getFeeder' method on both kinds of
objects that returns a closure, which can be executed later. That's what Java
might call a 'Strategy pattern', but it's baked right into the language in JS.

~~~
prophetjohn
>In my experience most Java developers don't even do that. They...

It's awesome how, on Hacker News, people whose job require them primarily
write code in Java are some sort of stupid luddites ready to be easily
generalized as the worst kind of programmer. Way to stay objective, guys.

~~~
neilk
Fair point -- it's unfair to stereotype Java developers. In my mind, I meant
"most developers" and I happened to be talking about Java. But that
distinction wasn't clear.

It's obvious that (in the OP's case) using JavaScript didn't help the problem
either -- but that was my point. Bad design is bad design. I am not making a
strong claim that JS is better.

~~~
alexscheelmeyer
I like how you apologize for stereotyping Java developers by clarifying that
you really wanted to stereotype ALL kinds of developers.

~~~
gridspy
When you think only in A restrictive language, your thinking becomes equally
restricted. Any of us would become rigid if we never used or understood
dynamic languages and only use java or c++ bog standard OOP.

So the comment is less about the developer than it is about the mindset and
the 'easiest path' that emerges from the language design.

------
orthecreedence
"Help! I don't know how to organize code in intelligent ways! This is the
fault of the language we originally decided to use!"

I have to say after writing "large" web apps in PHP and also in 100% JS, I
much prefer JS for front-facing stuff. I've not found organization to be a big
issue...but maybe this is due to the fact that I use a JS framework for most
of my larger apps (but then again, I did in PHP as well).

Like C "feels" like a language for low-level programming and PHP "feels" like
it should be running on a webserver, javascript "feels" like it's right at
home in the browser. And now that browsers are powerful enough to be the
entire front-end, I've come to completely embrace JS for this task.

Javascript is not a bad language. It's a very powerful language. Just like any
other language, if it's poorly organized it's going to be a mess. I can tell
you, from my experience, it _is_ suitable for large web apps!!

Also, you can't ignore that this is hosted by Adobe...

~~~
Zimahl
"Help! I don't know how to organize code in intelligent ways! This is the
fault of the language we originally decided to use!"

The problem might not be you. Once you are done with your organized code and
are moved to another project, some 'junior' dev gets a hold of your stuff and
makes simple mistakes that static-typed languages could've avoided.

I'm not anti-JS btw, just throwing out one possibility.

~~~
unconed
Big surprise: junior developers who've only been taught to architect for
statically typed language are lost in dynamic languages.

------
mistercow
I am shocked — shocked! — that someone from Adobe believes a proposition that
implies a continued niche for Adobe in the web development market.

------
xd
This is utter tripe. It goes from saying don't use javascript to use a high
level language that translates down to javascript.

His main example of why javascript isn't suitable is an anecdote about a badly
developed code base written in javascript. Seriously?

~~~
Karunamon
Don't write programs in assembly. Use a high level language that translates
down to assembly.

Yknow, most every language ever.

If you had read the article, you'd see that the author made this comparison.

~~~
pork
Except Javascript isn't assembly, no matter how much the author would like to
think so. It's a reasonably well featured, multi-paradigm high-level language.

~~~
fingerprinter
Woosh...that is the sound of the point flying over your head.

~~~
pork
you might consider going back to slashdot. i didn't miss his point at all, try
reading my comment again, but this time, try to read the statement "but
Javascript isn't assembly" a little less literally.

------
jwilliams
Some pretty woeful logic in this article.

 _To illustrate his point let me show you my cross-compiled and optimized
JavaScript code of SpriteExample, which is included in Adobe’s online
documentation about the Sprite class. As you can see the JavaScript code is
extremely dense and no longer readable._

This links to <http://jsfiddle.net/bparadie/cbU2X/>

This contains some minified JavaScript... Of course it looks dense & no longer
readable. Run the ActionScript Sprite class through gzip compression and I'm
sure it'd look funky too.

The author also advocates the use of CoffeeScript - which would have the vast
(all?) of the same complaints he's raised against JavaScript.

All in all, a pretty terrible article.

------
voidr
This article only proves the author's incompetence to develop and maintain
large JavaScript projects, nothing more.

> I don’t know why but JavaScript programmers tend to put all of their code
> into few files. That’s not so useful, though, if you want to have multiple
> developers work on the same project. Splitting up the code into multiple
> files enabled us to scale the project.

Let me rephrase that:

"I don’t know why but incompetent programmers tend to put all of their code
into few files."

Last time I checked JavaScript does not have a file count limit.

The author should learn to talk in first person. I'm pretty sure I could write
a horrible ActionScript app, if I wanted to, but that would not make
ActionScript horrible in general.

~~~
Arelius
Ok, seriously, I'm sort of sick of the file-stew meme in software development
these days. Our editors aren't particularly designed for the one-file-per-
function method of development that's been ohh-so-common. Serious, if a file
is under a hundred lines of code, it probably doesn't need to be a separate
file, it only undermines the grouping value that files are useful for.

~~~
voidr
I usually do the following:

\- if function A and B are always used together, than they are one file.

\- if linecount gets to big, split A and B into separate files

\- if function C is shared between modules than it belongs in it's own file

So far it worked out great.

~~~
Arelius
So long as #3 takes #1 into account.

------
williamcotton
What's funny is I spent last year porting a Flash app to Javascript.

The Flash codebase had become unmanageable. We found that the majority of
Flash developers were used to coding up some advertising banner or something
of that ilk and that individuals with experience making large applications
didn't know Flash. Our team was mainly Ruby and web front-end guys and we had
no clue what the Flash guys were up to.

After the change, our web designers could work directly with the markup and
CSS in order to make changes, something that was a nightmare before we
switched over.

Was it just Flash? No, it wasn't, it was a number of issues, mainly poor
architectural decisions and a lack of vision from the technical leads.

All of these issues disappeared mainly because a CTO was brought on who really
knew his stuff.

In summary, it's not the tech, it's the people putting the pieces together,
and most importantly, knowing how to organize the people who are putting the
pieces together.

------
zdmc
Obviously there may be different requirements in different contexts, but I
don't understand why anyone writes large web apps entirely in one language.

I, too, once believed the mantras that "multiple languages present a
maintenance nightmare" and "it's better to keep a common language for the sake
of acquiring new hires" and on and on... But after some years, I disagree with
that rationale.

In my experience, it's been more productive to have some sort of service-
oriented architecture, built around your preferred protocol and data format.
Then you can choose the languages that best suit your project needs (a
decision most often based on the best available libraries). Popular languages
are very similar, and it's easy to cruise between them...

I recognize the need to strike some balance in an organization. You don't want
50 services each in some emerging/obscure language, but I think that most
folks (at least those who frequent this site) are savvy enough to know when
you've hit that threshold. In our organization, we have developers who are
globally distributed, and we write services in a variety of languages. We tend
to standardize on the JVM: Java, Clojure, Groovy, but we've got some C#
services, a lot of XSL, PowerBuilder (yuck), and even VB. I typically have
discretion to use the language of my choice.

ASIDE: I always emphasize the "script" in JavaScript and rarely use it in any
type of OOP style (except for the occasional lightweight library); the
examples in the OP link made me cringe.

------
Achshar
While I agree that JavaScript can be better but suggesting to compile your
code to JavaScript as default is something that I cannot feel comfortable
with. Doing it once or twice if the need be so makes sense but phasing out
JavaScript and writing code in high-level language only to compile it back to
JavaScript does not feel right to me. Why add another layer (compilers) of
code conversion only to increase the surface area for critical bugs?

------
kevincennis
"Poorly-written JavaScript is not suitable for large web apps".

~~~
TazeTSchnitzel
Funnily enough, that also applies to:

ActionScript, Dart, Java, PHP, node.js, Ruby, Go... ;)

~~~
jsnk
node.js is written in JavaScript.

~~~
base698
Large parts are written in C++ :)

~~~
GnarlinBrando
I'm pretty sure that very little of it is actually in js. It's more
appropriate to say that you use javascript to script the node
environment/runtime.

~~~
daba
Actually a pretty decent part is in JS since most of the standard libraries
are purely written in JS. Github claims that nearly 70% of the node repository
is in JavaScript.

------
hblanks
Like many commenters here, I'm not sure I can agree with the author's
position. Plenty of in-browser apps go awry, but that's most often because the
tools people start using (notably jQuery) just don't work well once you have a
large collection of UI components on the page.

That said, the bulk of Google's web applications, for instance, are not
written in GWT or Dart, but rather in JavaScript using Closure Library, and
compiled using the Closure compiler. So I don't think the answer here is to
not use JavaScript (although I can understand why people at Adobe would argue
for that), but rather to use tools like Closure or Angular that make the
process more straightforward.

------
adjwilli
JavaScript is not suitable for large web apps because Adobe can't charge
developers hundreds of dollars selling buggy tools for it.

------
jwoah12
As I read more of these arguments, it makes me think a lot about whether I
should switch to CoffeeScript before my web app gets any larger. Has anyone
switched to CS or another language that compiles to JS, and regretted it?

~~~
heretohelp
CoffeeScript is a syntax, not a language.

His arguments have to do with the semantics of JavaScript, which are identical
to the semantics of CoffeeScript.

~~~
prodigal_erik
Coffeescript has a very similar object model, but it does alter (fix) the
semantics of variable binding and expression statements and some unusably
broken operators, and those involve treating Javascript more like a
compilation target than an equivalent dialect.

~~~
heretohelp
Yesss running s/==/===/g...very semantically different ;)

------
techiferous
The bunny or toaster example seems to me like someone still thinking in a
statically-typed paradigm in a dynamically-typed language.

If you stop relying on instanceof and start using duck typing it would
probably work out better.

Or maybe you should just never write a function called doThisOrDoThat. Seems
like a code smell.

------
korimako
We are currently porting a large web app from Actionscript to Javascript. The
only library that we found that met our needs was Google Closure. It caters
for modules of compressed code to be downloaded as required, much like the
runtime shared libraries in Actionscript. Given the quirks of Javascript
implementation, I don't see how we could have written our web application in
any other language and successfully managed the exceptions.

------
underwater
The author has failed to put any effort into trying to prove his assertion
that the language is at fault. I've seen bad code in all sorts of languages. A
rewrite will naturally produce cleaner code, so I don't see how this proves
anything about the language itself.

Despite this, there is some truth to the assertion that JavaScript projects
can be unwieldy. The main issue with large scale JavaScript development is the
lack of a built in module system. The naive style of using a global namespace
and script tags is prone to resulting in difficult to maintain code.
Thankfully there are frameworks that can solve this issue.

------
trimetric
I do not like language {X}, but I do like language {Y}. Everyone should agree
to write in language {Y}, so that we can all pretend that language {X} does
not exist, and maybe then browsers will just start using {Y} natively.

------
theojapa
Poorly written Javascript is not suitable for large web applications. This
goes for any language. Competent Javascript developers will have many files
that are concatenated into just one or two files as part of their build
environment. Competent Javascript developers will use code quality tools such
as jslint or jshint to find potential problems.

It’s too bad that you inherited a poorly written Javascript project, but that
doesn’t mean the language you’re most familiar with was the best language for
the job. This is a common response. “I know X, let’s use X!!!”

Also, Javascript is a high level language.

------
dkevswain
Tell that to <http://lucidchart.com> which is almost entirely built using
Javascript. Easily one of the most powerful apps on the web today.

------
einhverfr
I don't understand the article. He seems to be confusing using a language in a
project vs using a language as the primary one in a project. We might say
"Assembly language is not suitable for large OS kernels. Do not write your OS
kernel in assembly language."

But I don't think that follows. Assembly language (the article's metaphor) is
something that most OS kernels will use from time to time and in moderation.
Similarly I don't see anything wrong with Javascript for some pieces of a
large web app.

------
gruseom
Is there _any_ credible data on static vs. dynamic typing?

~~~
artsrc
Yes. A couple of weeks back on either hacker news or reddit (I just searched,
and could not find it quickly), there was a seemingly well conducted
experiment, with a large number of students randomized to static and dynamic
languages, that found no statistically significant difference.

~~~
gruseom
If you look at the HN thread where that paper was discussed, people on both
sides were shooting holes in it. That's partly why I'm asking, is there
anything solid on this out there at all? People are just repeating the same
beliefs over and over. We've all heard them a zillion times and we all divide
them into two categories: "shit I agree with" and "bullshit".

What experiments _could_ be done to test these beliefs?

~~~
alexscheelmeyer
I think one would need to start by testing a different question first : "With
everything else being equal, should your language choice be affected by the
level of competence of the developers?". It seems discussions on topics like
this all boil down to clash between the idealist and the pragmatist. Idealist:
"I want to use language X because it is powerful and lets me to Y".
Pragmatist: "but that feature will be abused by the average developer and your
project will suffer". So you can't win. Either you have to work in a mediocre
language that the mediocre developer knows how to use, or you will work in a
great language that the mediocre developer will use to shoot you in the foot.
If the answer to the above question is no, then we can put this discussion to
rest - otherwise we will need to probe further and understand how developer
competence should guide your language choice.

------
bdorman
I've been a part of some fairly large JS projects. I think you can develop
solid software in either case. It boils down to the developer in most cases.
Having said that, there's no doubt you're given the ability to do a lot more
around enforcing structure with constructs such as abstract classes or
interfaces. the timing of this post is interesting as I recently put a project
up on github (<https://github.com/vannatech/blade>) for essentially coding
JavaScript in a .NET-ish environment. I think maybe even as valuable as some
of the thing strong typing brings is the ability to make use of the IDE (you
get Visual Studio, assembly referencing etc). For building reusable components
I feel like it's definitely the way to go. For annotating a page to add UI
features, I'd push for JS. Then there's a lot of area between that where it
could vary depending on other factors. Overall I can agree on some levels with
the post. But I think, as in most things, it's important to understand the
underlying technologies. Abstracting away JavaScript and the browser related
APIs will inevitably lead to bad results.

------
Jangaroo
It seems to me this is a discussion on two levels: statically versus
dynamically/weakly typed languages in general, and ActionScript versus
JavaScript in particular.

Concerning the first aspect, the most important advantage I see in static
typing is not that is finds bugs (tests are better in that discipline), but
that it leads to much better IDE support. Only in a statically typed language,
the IDE can definitely find out which class, method or field your code
actually refers to, which allows for code navigation, documentation lookup,
and last but not least intelligent refactoring support.

Concerning ActionScript versus JavaScript, I must say that I like and respect
JavaScript a lot and want to keep its "good parts" (a la Crockford), but I
also want to be able to take advantage of static typing for the reasons given
above. Thus, although the company I work for is not affiliated with Adobe in
any way (rather on the contrary), we were looking for the statically typed
language that is closest to JavaScript and finally chose ActionScript 3. We
then built a cross-compiler from ActionScript to JavaScript years before
Adobe/Bernd Paradies did. We have improved and been working with this tool
since 2004 (starting with JavaScript 2/ECMAScript 4) and never regretted
following this approach. In contrast to Adobe's tool, "Jangaroo" is Open
Source and ready to use now. It focuses on integrating with, not replacing
JavaScript, and we help solve problems like dependency management for
JavaScript and reuse such solutions for generated JavaScript code. Jangaroo's
generated JavaScript code does _not_ look like assembly language, but as much
as the AS3 source code as possible.

It's not always black or white, I believe we can use the best of both worlds!

------
cft
Unlike Steve Job's statement about ActionScript, Adobe's statement about
JavaScript will not change the web landscape. Look at Google Docs for example!

~~~
tonyarkles
I don't know the answer to this question, but it's worth posing: Is Google
Docs written directly in JS? Or is it compiled down from, say, GWT?

~~~
cft
Google Docs are written using Google Closure JavaScript library, not Java/GWT

------
usablebytes
As long as you keep using frameworks, yes!

Instead just use a base library to give you a cross-browser wrapper and few
more utils, then develop the whole application core layer on top it to
separate it from your sandbox. Write all processing in core JavaScript unless
you are trying to access DOM where the library (usually jQuery) wrappers would
come into picture. This would give you immense power to control what you
develop; will be highly scalable and of course, not to forget, performance.

Don't even complain if you have server side frameworks which will generate
JavaScript for you; that will never work and is only good till your project is
in Mock-up (prototype) stage.

The problem seems, you don't have good UI guys.

------
user49598
Sheesh fellas, lighten up, he has some interesting things to say. He's not
laying out the 10 web commandments, just some opinions about software design.
And his thoughts have some merit. It is distinctly hard to build large
applications with a language as dynamic as javascript. At least in python and
ruby you have classes. In javascript all you can do is duck type. Also
javascripts scope is great for being the worlds most flexable language but not
for building large web apps or hiring devs for that matter.

JS is a great and flexible language that runs on more devices than practically
any other language. But it is hard to write large web apps in it.

------
hermanhermitage
It would be interesting to see someone go through a public repository and
compare error rates / bug fixes between dynamic and static languages
implementing the same kind of products. Might not point out differences in the
approach but at least in the entire ecosystem (tools+developers+code).

At a certain distance you can swap the approaches anyway (but for syntax):

static as dynamic: Use Thing = HashMap<String, Thing> instead of objects.
dynamic as static: Put assert(type(x)=="int") everywhere.

As to building large apps. If you need to build a large app (ie you cant
divide it into isolated subsystems) then your goose is already well and truly
cooked :)

------
outside1234
yes, "spaghetti code is not suitable for large web apps" nor apps in general.

that is why things like Ember.js are springing to life - to give the structure
necessary to build large web apps without them devolving into spaghetti.

------
denysonique
Node.js and Backbone/Underscore.js make it easier to write large scale
JavaScript web applications. Trello.com -- Uses Node.js on the backend and
Backbone.js on the frontend

Klout.com -- same as above

More examples if you are interested:

[https://github.com/joyent/node/wiki/Projects,-Applications,-...](https://github.com/joyent/node/wiki/Projects,-Applications,-and-
Companies-Using-Node)

<http://documentcloud.github.com/backbone/#examples>

------
carlyle
RequireJS or one of its AMD cousins would have been all that you needed to
handle the "too few files" problem that prevented you from scaling the
project's development.

------
mcantelon
>The code naturally distributed itself from about 10 files to over 100 files
when creating ActionScript classes. ... I don’t know why but JavaScript
programmers tend to put all of their code into few files.

Good JS programmers don't. Classes and inheritance work fine in JS.

>Just to be clear: You can write bunny-and-toaster code in ActionScript, too.

Right. This rant isn't about a bad language, it's about bad development
practices.

------
nathants
i dont know why nobody ever talks about pyjs.org. to me it takes the best
ideas of gwt, simplifies it, and then lets you use python instead of java.
sure its a little bleeding edge, and not being heavily developed (because it
already works good enough?), but who cares. i dont need the worlds fanciest
framework with new features every five minutes. i dont need pythons
metaclasses for browser apps. i just need simple, bare bones widgets that wrap
html and to be able to write python. javascript is fine, but python is just so
much more productive. syntactic sugar counts. readability counts. and python
will never run native in the browser so we all need to move on.

pyjs works great _now_ , and makes one highly productive. it just needs a
bigger community of users (and developers?). so anyone asking the types of
questions raised here should try it. then you can bash it on hn, right? :)

------
felipellrocha
"I don't like Javascript, so we Actionscript is the correct answer," sounds a
bit like a false dichotomy to me...

------
btford
Did they lint or unit test their code? Without having a way to verify that
parts of your app work at a smaller level, of course it's going to get hairy
when it starts to grow. Although a compile step verifies types, unit tests do
that plus check against runtime errors. This is not a language problem.

------
elliotlai
"JavaScript is the browser’s assembly language."

This reminds me of a blog post by @izs

[http://blog.izs.me/post/10213512387/javascript-is-not-web-
as...](http://blog.izs.me/post/10213512387/javascript-is-not-web-assembly)

Yes, I love Haskell and I do some CoffeeScript but JS is a fairly decent
language to me : )

------
anmi
I used to write 10-20kloc projects in javascript. Don't know if its large
enough for you but i dont feel any problem to maintain large js applictions
written by good programmers. Try CoffeeScript anyway. BTW "jQuery programmer"
sounds obnoxiously we are javascript programmers.

------
pohl
On the same subject, Gilad Bracha gave an excellent talk about Dart at
lang.NEXT recently...

[http://channel9.msdn.com/Events/Lang-NEXT/Lang-
NEXT-2012/Dar...](http://channel9.msdn.com/Events/Lang-NEXT/Lang-
NEXT-2012/Dart-A-Well-Structured-Web-Programming-Language)

------
tmcw
Company no longer respected for engineering prowess demonstrates lack of
engineering prowess.

------
Axsuul
The title of this article is very misleading. There's nothing wrong with the
language itself. If you don't separate your application into layers, then of
course it's going to be hard to maintain and bring new developers up to speed.

------
leesk
Compile to JavaScript? It's dangerous if you don't know what it really does in
the blackbox. I just wrote a article discussing this topic several days ago.
<http://bit.ly/M9CSXj>

------
mattdeboard
>Splitting up the code into multiple files enabled us to scale the project.

I really don't get this at all. More files == more scalable? Someone more
knowledgeable about ... whatever topic is relevant here care to explain this
to me?

~~~
bitcrusher
He means "scale the number of people working on the project at one time."

He's basically saying that if you have 10 files and 2 developers the chances
of collision (or merging issues) is small, but having 20 developers working
from 10 files makes things more sticky.

To some degree, he's not incorrect, in that over time, you'll spend more time
managing the merging and conflict process than you will writing code.

Obviously, there are modern tools that will help alleviate this problem, but
the deeper you go, the worse it is. This was the reason that "old" VCS had
exclusive locks.

~~~
artsrc
If you change an interface, and someone else adds a new client to the
interface locking does not help. So file based locking does not guarantee that
merge conflicts won't occur.

Managing essential merge issues relates to success at dividing work up into
highly cohesive, loosely coupled units. The accidental merge issues are not a
big deal in good environments.

------
malachismith
This whole thing smells like link-bait to me. I mean, I'm guessing this is the
first time a post from Adobe has been high up on Hacker News in what….
forever?

------
penguinbroker
tl;dr

Shitty programmers should not work on large javascript projects.

------
queryly
if you outsource your development, the work will still get done, but just
don't expect it to be the leader in the field.

by the same token, you can always get the work done with compiling-js
approach, but don't expect it to be the winning product.

------
jcromartie
Pew Pew doesn't look like a large web app to me. But maybe I'm missing
something?

------
thisismyname
Tell that to twitter (period).

------
n-gauge
For point 6 of his blog: jsbeautifier.org is your friend

------
wheeyls
Javascript is over! It's the age of Action Script!

------
harel
Why do people post such rubbish and how the hell does this get 100 points?
This kind of content can damage young minds.

It should have the HN equivalent of reddit's NSFW tag..

------
blrblr
I guess Adobe Flash is. /s

------
eswangren
Though I understand what the author meant, I had to giggle a by when I read
"don't use JavaScript... Use a high level language"

------
goggles99
FACT: Javascript/HTML/CSS holds the biggest monopoly any piece of technology
ever has. There is almost NO viable alternative if you want to program for the
web. Even the notoriously closed IOS has far more (over 20 popular languages
now can be used to compile an app's UI and logic code for)

The title is true BUT for another reason.

It is not suitable because there are so many great languages and language
experts - but relatively few who are JS experts.

Why does javascript have a monopoly on browsers? Why can't there be some kind
of WBVM (web browser virtual machine) that X language can be compiled down to?
Why does JS have to be the assembly language of the web? This fact only makes
things difficult and messy to have most languages cross compile to. I think
that the W3C are a bunch of idiots for not pushing for something like this.
They are stifling innovation more than Microsoft (or anyone else I can
remember) ever has IMO. There SHOULD be an open standard for this.

Only very high level JS experts could pull off a large web application in JS.
This accounts for maybe 5% of US businesses. Throw in High level experts for X
language and now you probably have 60%+ of businesses who could accomplish
such a thing. The Same goes for the browser UI as well (HTML and CSS pffff)
How about the VM having the ability to draw all these elements instead of
merely pushing HTML/CSS in our faces as an only option). We could use superior
technologies like Flex, XAML, ETC. instead of HTML/CSS.

You love Javascript? great, but don't push it in my face. I have 3 favorite
languages and JS is not anywhere near them.

The web browser is a platform (though it lives inside another platform) but
one which is among most proprietary ever.

Why aren't more people pissed off about this?

------
eriksank
Javascript forces everybody to use the same language, while there are so many
people who are religiously fanatical about their own little pet language. So,
yes, to whomever it applies, go ahead and cross-compile from whatever you like
to Javascript and let's put an end to the problem.

------
vtry
Try AngularJS ;)

------
_pferreir_
GWT? Seriously? I cannot think of any large, significant web app that has been
written in GWT.

I thought it would be clear by now that we do not need Java Enterprise in our
web browsers. The web seems to be moving the other way - we have lightweight
libs such as jQuery, underscore, backbone etc... and they seem to provide JS
with the necessary building blocks for larger, maintainable systems.

~~~
mping
GWT doesn't get the fair share of respect it deserves. It's not enterprise
java (j2ee and such), it's a toolkit that (amongst other things) lets you
write and debug java, that gets compiled to javascript in the end. GWT is not
modular in the same sense as jQuery/underscore/backbone/any other js library,
that's its weakness but also its strength. Also, the same modularity of those
libs is simultaneously its strength and weakness. You plug jQuery mobile and
backbone, you have to hack the router. You plug backbone with rails, you have
to hack backbone.sync; but that's okay, we're all hackers.

If you want to dismiss GWT because it's java that's ok, but there are alot of
good reasons (some non-technical) to choose java instead of CS or whatever. In
fact, if you look at the history of GWT, they had all these "enterprise"
patterns such as EventBus or Composite Views, or any other thing that the
backbone/spine/etc camps are re-writing right now.

~~~
_pferreir_
I know what GWT is. I agree that it provides out of the box certain
functionalities that require a bit of "glue code" when using other frameworks.

However, the whole "just write a desktop app and we will turn it into a web
app" philosophy doesn't seem very web-oriented to me. Yes, it works, it's
easy, but if one day you want to change your client-side code (i.e. use a
different framework or something) you'll most likely have to change the server
side as well. It just seems to be too RPC-centered and too monolithic. But
maybe I'm wrong.

~~~
mping
You can do standard REST, or whatever you want with GWT. IMHO what really
sucks with GWT is the language; Java really sucks sometimes and its full of
ceremony. Also, I think they made the same mistake that the Swing guys did:
they provided for a toolkit but they didn't provide a framework, ie, a
standard way of putting it all together.

Anyway, you can check what the jBoss guys are doing with GWT, looks good even
for Java: <http://www.jboss.org/errai> I think that if Java ever gets proper
closures it will may be more of an acceptable solution for some cases.

