12 ms·

JavaScript is not suitable for large web apps

186 points by superasn 14y ago

marknutter 14y ago
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.
- Graphon 14y ago
  The OP seems to be very willing to draw general conclusions when none are warranted. When faced with a project in which code modularization was a problem, his proposed solution was to port the code? Seriously? Port Javascript to Actionscript because the .js was organized into too few modules? mmmm-okay.
- _delirium 14y ago
  Yeah, this doesn't add a whole lot to the debate imo. I'm vaguely sympathetic to the argument that languages with more/better static analysis are better for large-scale development, but that particular argument has a whole lot written about it, and is probably still inconclusive.
  - mixitup12 14y ago
    Also, define large scale. Plenty of large scale applications can and are written in languages like Python.
- TazeTSchnitzel 14y ago
  And it's an Adobe blog. Their employees are quite likely to be biased in favour of their statically-typed variant, ActionScript 3 (well, it has a lot of changes, but it's essentially a JS variant at heart)
  - millions 14y ago
    Not exactly - ActionScript3 is pretty much as close as you can get to what JavaScript2 would have been - Ecmascript 4.
    - cnp 14y ago
      ...yeah, what was to be a beautiful language. So unfortunate that that proposal was squashed.
      - arcos 14y ago
        No, thank Thor that mutant was aborted. ECMAScript 4 got everything wrong, just like AS3 did.
        cnp 14y ago
        An optionally dynamic, yet also statically typed language? Umm... no. It's hard to even imagine arguing about this.
        TazeTSchnitzel 14y ago
        No. The problem with ES4 was that JavaScript is at heart not a traditional procedural OOP language. It's a functional language, and ES4 was trying to change that, a huge step in the wrong direction. They wanted more Java and less Script, but thankfully ES5 has gone the other direction, and given use more Script and less Java.
  - codebearded 14y ago
    I find it very difficult to swallow anything written by the OP from the obstructed view at Adobe. After spending nearly every billable hour for more than three years buried in AS3's woeful inconsistencies, undocumented (or un-addressed) compiler issues, seemingly infinite application-crippling bugs, schizophrenic deprecation- any dev who had the misfortune of being relegated to work primarily in AS3 (and god help you if you had to support AS2 and AS3 applications simultaneously) the mere suggestion that Adobe has an opinion that is anything but a head up its own ass probably makes you break out in hives like i just did.
- kaonashi 14y ago
  Dynamic typing isn't the problem; weak typing is the problem.
- mistercow 14y ago
  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 14y ago
    > 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.)
    - lucisferre 14y ago
      Unfortunately static typing doesn't really fix the automation problems that are most common in software development any better than anything else. I wouldn't mistake a personal preference for static type systems and large complex IDEs for superiority of language or productivity.
- mixitup12 14y ago
  Glad you wrote it so I didn't have to. If you have programmers making bad decisions in any language a project quickly becomes unmaintainable. I say take it back.
- drivebyacct2 14y ago
  >making the argument that dynamically typed languages are not suitable for large web apps is a difficult (not impossible) one to make Is it? And even if it is, why? Because dynamically typed languages are in vogue? Java does fine as a server-side webapp language, as does Dart (on the client too!), as does Go, etc.
jwoah12 14y ago
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?
- allardschip 14y ago
  I switched to Coffeescript and rarely if ever look back...
- mistercow 14y ago
  It's hard to imagine having much regret about a switch to CS since it would be so easy to convert your code back to JS if you ever needed to (and since you could do so incrementally).
- zkirill 14y ago
  Overall, CoffeeScript has made JS development much more enjoyable for me. We had also integrated the compiler very nicely into our build script. This resource has been invaluable: http://js2coffee.org/ http://js2coffee.org/
- hellopat 14y ago
  I haven't used coffee script myself, but I think you'd be hard pressed to find someone that wrote something in CoffeeScript and regretted it. The biggest arguments against using CoffeeScript (or any language that compiles to JavaScript) that I seem to keep hearing are: 1. JavaScript isn't a very readable language. (I think this is untrue. I've seen some incredibly well written / structured JS) 2. Not everyone knows CoffeeScript, so when you put a project up on GitHub and it's written in CoffeeScript, it's difficult for people who only know the syntax of native JS to understand what's going on. (To counter this - a lot of projects that are written in CoffeeScript are bundled with the compiled JS code as well - which also happens to be very readable IMHO).
  - pooriaazimi 14y ago
    3. (biggest problem IMO): debugging in CS sucks right now. It would be a no-problem with SourceMap though, so we have to endure it just a few more months.
xd 14y ago
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?
- lclarkmichalek 14y ago
  There's no contradiction in saying don't use javascript, use something that compiles to javascript. It's exactly the same as saying don't use C, use something that translates to C (i.e. C++ once). As for his example being anecdotal, almost all code snippets posted in a blog post can be attacked for that, and while it might be valid, it is pretty much impossible for the writer to give _any_ negative example without it being dismissed as "bad code is bad code" etc.
  - FuzzyDunlop 14y ago
    When combined with the assertion that "JS is the browser's assembly language", one can't quite say it's identical, because C isn't the OS's assembly language. Assembly language is.
- mixitup12 14y ago
  Hear hear. He does have a point about that well known low level language 'javaScript'. Must be similar to the high level one of the same name. Also he makes the valid point that bad developers make for a bad project, what a genius. judging by the comments on the actual blog he must be the second coming of Christ.
- Karunamon 14y ago
  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 14y ago
    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.
Achshar 14y ago
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?
mistercow 14y ago
I am shocked — shocked! — that someone from Adobe believes a proposition that implies a continued niche for Adobe in the web development market.
kevincennis 14y ago
"Poorly-written JavaScript is not suitable for large web apps".
- TazeTSchnitzel 14y ago
  Funnily enough, that also applies to: ActionScript, Dart, Java, PHP, node.js, Ruby, Go... ;)
  - jsnk 14y ago
    node.js is written in JavaScript.
    - TazeTSchnitzel 14y ago
      I am aware of that, but I personally use JavaScript to mean the browser language, and all the browser's features (DOM, WebSocket, etc.), but node.js to mean JS in the node.js environment. Same core language, but different environments, so not the same in practise.
    - deleted 14y ago
      [deleted]
    - base698 14y ago
      Large parts are written in C++ :)
      - GnarlinBrando 14y ago
        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 14y ago
        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.
voidr 14y ago
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 14y ago
  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 14y ago
    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 14y ago
      So long as #3 takes #1 into account.
- untog 14y ago
  I know exactly why they do it- to cut down on HTTP requests. But then it's trivial to minify and compact your JS into a single file. It sounds like he's just worked on bad projects.
trimetric 14y ago
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.
Axsuul 14y ago
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.
_pferreir_ 14y ago
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.
- pohl 14y ago
  GWT? Seriously? I cannot think of any large, significant web app that has been written in GWT. I would consider the AWS management console to be significant.
  - heretohelp 14y ago
    It actually does a lot to explain why I hate the AWS management console so much.
    - jrockway 14y ago
      Most people are users of the software, not developers, and so they hate the product because it's bad, not because it's written in Java. Wait, you don't work for Amazon, so I'm confused...
- munificent 14y ago
  AdWords, AdSense, Flights, Hotel Finder, Offers, Wallet, The New Blogger, Chrome Webstore, Product Search, Public Data, New Google Groups, Orkut, Google Takeout, Google Pagespeed, Google WebFonts, Google Tables, Google Health (discontinued), Google Wave (discontinued), PlayN (basis of Angry Birds) http://gwtreferencelist.appspot.com/#AboutPlace http://gwtreferencelist.appspot.com/#AboutPlace:
  - _pferreir_ 14y ago
    OK, I stand corrected. Still, that doesn't make it a good idea. Not to mention that most of those apps are Google products.
hblanks 14y ago
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.
vtry 14y ago
Try AngularJS ;)
btford 14y ago
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.
dxbydt 14y ago
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.
- Arelius 14y ago
  > 200 average developers This is the problem, and as you implicate, the exact sort of thing we need to stop doing.
  - taligent 14y ago
    Sure. So long as you have a full proof way of identifying the best developers. Hint: the best developers aren't the ones who can recite the API off hand.
mattdeboard 14y ago
>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?
- dougabug 14y ago
  Because a hundred files must be worth ten times as much as ten files. Maybe he gets paid by the file.
- kevincennis 14y ago
  I tend to like having discrete modules of code split up into separate files when I'm building large JavaScript apps (which is really all I do). It helps keep me organized. And I think it also makes version control run more smoothly. Generally, I'll write a little build script in Node that concatenates and minifies all my JS and CSS before actually deploying to production to keep the number of HTTP requests down.
- bitcrusher 14y ago
  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 14y ago
    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.
theojapa 14y ago
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.
felipellrocha 14y ago
"I don't like Javascript, so we Actionscript is the correct answer," sounds a bit like a false dichotomy to me...
orthecreedence 14y ago
"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 14y ago
  "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 14y ago
    Big surprise: junior developers who've only been taught to architect for statically typed language are lost in dynamic languages.
- munificent 14y ago
  > Also, you can't ignore that this is hosted by Adobe... This may be true, but it's an ad hominem attack.
  - lowboy 14y ago
    It might be ad hominem out of context, but I don't feel it's improper to question the motives of someone working for a company that would most likely benefit from a decline in javascript in the app space. http://en.wikipedia.org/wiki/Ad_hominem#Questions_about_the_notion_of_an_ad_hominem_fallacy http://en.wikipedia.org/wiki/Ad_hominem#Questions_about_the_...
jwilliams 14y ago
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/ 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.
gruseom 14y ago
Is there any credible data on static vs. dynamic typing?
- paganel 14y ago
  I'm not a specialist on this topic (i.e. I'm only a programmer, not a computer scientist), but I don't seem to remember any links posted to relevant such studies in any of the "static vs. dynamic typing" flame wars. Also, a little bit OT, I've been a professional programmer for 7 years now (i.e. getting paid to write code) and to this day I'm not sure 100% what's the difference between "0", "NULL", "None" or an empty string. What type does "None" belong to? Can I compare it to the integer 0?
  - anentropic 14y ago
    "I've been a professional programmer for 7 years now (i.e. getting paid to write code) and to this day I'm not sure 100% what's the difference between "0", "NULL", "None" or an empty string. What type does "None" belong to? Can I compare it to the integer 0?" been doing PHP by any chance? ;)
- artsrc 14y ago
  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.
  - neilk 14y ago
    Actually, the study found that static languages were worse. They tested students on two problems. In one there was no significant difference, and in the other the static language performed worse. Here is that study: "An Experiment About Static and Dynamic Type Systems", by Stefan Hanenberg, University of Duisberg-Essen, 2010. http://www.cs.washington.edu/education/courses/cse590n/10au/hanenberg-oopsla2010.pdf http://www.cs.washington.edu/education/courses/cse590n/10au/... However, they didn't use existing languages; they created a brand new language and IDE that had a typed and untyped variant. Whether this confounds or strengthens the case is unclear to me. In any case, I think any survey of static type systems that doesn't include a language with type inference is very flawed. Java's type system is an annoyance in the small, and is a mixed bag in the large. Haskell's type system is a totally different story.
zdmc 14y ago
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.
thisismyname 14y ago
Tell that to twitter (period).
outside1234 14y ago
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.
deleted 14y ago
[deleted]
carlyle 14y ago
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.
dkevswain 14y ago
Tell that to http://lucidchart.com http://lucidchart.com which is almost entirely built using Javascript. Easily one of the most powerful apps on the web today.
cft 14y ago
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 14y ago
  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 14y ago
    Google Docs are written using Google Closure JavaScript library, not Java/GWT
adjwilli 14y ago
JavaScript is not suitable for large web apps because Adobe can't charge developers hundreds of dollars selling buggy tools for it.
- arcos 14y ago
  Thank you, you win the Internet for this comment.
deleted 14y ago
[deleted]
penguinbroker 14y ago
tl;dr Shitty programmers should not work on large javascript projects.
korimako 14y ago
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.
malachismith 14y ago
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?
techiferous 14y ago
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.
losethos 14y ago
My answers is always, "More namespaces!"
harel 14y ago
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..
eswangren 14y ago
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"
tmcw 14y ago
Company no longer respected for engineering prowess demonstrates lack of engineering prowess.
williamcotton 14y ago
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.
leesk 14y ago
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 http://bit.ly/M9CSXj
neilk 14y ago
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.
- silentOpen 14y ago
  Algebraic data type http://en.m.wikipedia.org/wiki/Algebraic_data_type http://en.m.wikipedia.org/wiki/Algebraic_data_type
  - neilk 14y ago
    Which is t3h awesome, but not an option in either language under consideration, as far as I know. Unless you used a Haskell-to-JS compiler. I apologize if I implied that static typing = Java's kind of typing.
    - silentOpen 14y ago
      js_of_ocaml http://ocsigen.org/js_of_ocaml/ http://ocsigen.org/js_of_ocaml/
elliotlai 14y ago
"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-assembly http://blog.izs.me/post/10213512387/javascript-is-not-web-as... Yes, I love Haskell and I do some CoffeeScript but JS is a fairly decent language to me : )
jcromartie 14y ago
Pew Pew doesn't look like a large web app to me. But maybe I'm missing something?
mcantelon 14y ago
>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.
eriksank 14y ago
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.
underwater 14y ago
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.
hermanhermitage 14y ago
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 :)
usablebytes 14y ago
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.
einhverfr 14y ago
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.
user49598 14y ago
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.
blrblr 14y ago
I guess Adobe Flash is. /s
nathants 14y ago
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? :)
anmi 14y ago
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.
Jangaroo 14y ago
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!
n-gauge 14y ago
For point 6 of his blog: jsbeautifier.org is your friend
denysonique 14y ago
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,-and-Companies-Using-Node https://github.com/joyent/node/wiki/Projects,-Applications,-... http://documentcloud.github.com/backbone/#examples http://documentcloud.github.com/backbone/#examples
queryly 14y ago
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.
pohl 14y ago
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/Dart-A-Well-Structured-Web-Programming-Language http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012/Dar...
wheeyls 14y ago
Javascript is over! It's the age of Action Script!
bdorman 14y ago
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 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.
goggles99 14y ago
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?

186 points by superasn 14y ago

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.

Graphon 14y ago
The OP seems to be very willing to draw general conclusions when none are warranted. When faced with a project in which code modularization was a problem, his proposed solution was to port the code? Seriously? Port Javascript to Actionscript because the .js was organized into too few modules? mmmm-okay.
_delirium 14y ago
Yeah, this doesn't add a whole lot to the debate imo. I'm vaguely sympathetic to the argument that languages with more/better static analysis are better for large-scale development, but that particular argument has a whole lot written about it, and is probably still inconclusive.
- mixitup12 14y ago
  Also, define large scale. Plenty of large scale applications can and are written in languages like Python.
TazeTSchnitzel 14y ago
And it's an Adobe blog. Their employees are quite likely to be biased in favour of their statically-typed variant, ActionScript 3 (well, it has a lot of changes, but it's essentially a JS variant at heart)
- millions 14y ago
  Not exactly - ActionScript3 is pretty much as close as you can get to what JavaScript2 would have been - Ecmascript 4.
  - cnp 14y ago
    ...yeah, what was to be a beautiful language. So unfortunate that that proposal was squashed.
    - arcos 14y ago
      No, thank Thor that mutant was aborted. ECMAScript 4 got everything wrong, just like AS3 did.
      - cnp 14y ago
        An optionally dynamic, yet also statically typed language? Umm... no. It's hard to even imagine arguing about this.
        TazeTSchnitzel 14y ago
        No. The problem with ES4 was that JavaScript is at heart not a traditional procedural OOP language. It's a functional language, and ES4 was trying to change that, a huge step in the wrong direction. They wanted more Java and less Script, but thankfully ES5 has gone the other direction, and given use more Script and less Java.
- codebearded 14y ago
  I find it very difficult to swallow anything written by the OP from the obstructed view at Adobe. After spending nearly every billable hour for more than three years buried in AS3's woeful inconsistencies, undocumented (or un-addressed) compiler issues, seemingly infinite application-crippling bugs, schizophrenic deprecation- any dev who had the misfortune of being relegated to work primarily in AS3 (and god help you if you had to support AS2 and AS3 applications simultaneously) the mere suggestion that Adobe has an opinion that is anything but a head up its own ass probably makes you break out in hives like i just did.
kaonashi 14y ago
Dynamic typing isn't the problem; weak typing is the problem.
mistercow 14y ago
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 14y ago
  > 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.)
  - lucisferre 14y ago
    Unfortunately static typing doesn't really fix the automation problems that are most common in software development any better than anything else. I wouldn't mistake a personal preference for static type systems and large complex IDEs for superiority of language or productivity.
mixitup12 14y ago
Glad you wrote it so I didn't have to. If you have programmers making bad decisions in any language a project quickly becomes unmaintainable. I say take it back.
drivebyacct2 14y ago
>making the argument that dynamically typed languages are not suitable for large web apps is a difficult (not impossible) one to make Is it? And even if it is, why? Because dynamically typed languages are in vogue? Java does fine as a server-side webapp language, as does Dart (on the client too!), as does Go, etc.

jwoah12 14y ago

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?

allardschip 14y ago
I switched to Coffeescript and rarely if ever look back...
mistercow 14y ago
It's hard to imagine having much regret about a switch to CS since it would be so easy to convert your code back to JS if you ever needed to (and since you could do so incrementally).
zkirill 14y ago
Overall, CoffeeScript has made JS development much more enjoyable for me. We had also integrated the compiler very nicely into our build script. This resource has been invaluable: http://js2coffee.org/ http://js2coffee.org/
hellopat 14y ago
I haven't used coffee script myself, but I think you'd be hard pressed to find someone that wrote something in CoffeeScript and regretted it. The biggest arguments against using CoffeeScript (or any language that compiles to JavaScript) that I seem to keep hearing are: 1. JavaScript isn't a very readable language. (I think this is untrue. I've seen some incredibly well written / structured JS) 2. Not everyone knows CoffeeScript, so when you put a project up on GitHub and it's written in CoffeeScript, it's difficult for people who only know the syntax of native JS to understand what's going on. (To counter this - a lot of projects that are written in CoffeeScript are bundled with the compiled JS code as well - which also happens to be very readable IMHO).
- pooriaazimi 14y ago
  3. (biggest problem IMO): debugging in CS sucks right now. It would be a no-problem with SourceMap though, so we have to endure it just a few more months.

xd 14y ago

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?

lclarkmichalek 14y ago
There's no contradiction in saying don't use javascript, use something that compiles to javascript. It's exactly the same as saying don't use C, use something that translates to C (i.e. C++ once). As for his example being anecdotal, almost all code snippets posted in a blog post can be attacked for that, and while it might be valid, it is pretty much impossible for the writer to give _any_ negative example without it being dismissed as "bad code is bad code" etc.
- FuzzyDunlop 14y ago
  When combined with the assertion that "JS is the browser's assembly language", one can't quite say it's identical, because C isn't the OS's assembly language. Assembly language is.
mixitup12 14y ago
Hear hear. He does have a point about that well known low level language 'javaScript'. Must be similar to the high level one of the same name. Also he makes the valid point that bad developers make for a bad project, what a genius. judging by the comments on the actual blog he must be the second coming of Christ.
Karunamon 14y ago
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 14y ago
  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.

Achshar 14y ago

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?

mistercow 14y ago

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

kevincennis 14y ago

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

TazeTSchnitzel 14y ago
Funnily enough, that also applies to: ActionScript, Dart, Java, PHP, node.js, Ruby, Go... ;)
- jsnk 14y ago
  node.js is written in JavaScript.
  - TazeTSchnitzel 14y ago
    I am aware of that, but I personally use JavaScript to mean the browser language, and all the browser's features (DOM, WebSocket, etc.), but node.js to mean JS in the node.js environment. Same core language, but different environments, so not the same in practise.
  - deleted 14y ago
    [deleted]
  - base698 14y ago
    Large parts are written in C++ :)
    - GnarlinBrando 14y ago
      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 14y ago
        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.

voidr 14y ago

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 14y ago
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 14y ago
  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 14y ago
    So long as #3 takes #1 into account.
untog 14y ago
I know exactly why they do it- to cut down on HTTP requests. But then it's trivial to minify and compact your JS into a single file. It sounds like he's just worked on bad projects.

trimetric 14y ago

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.

Axsuul 14y ago

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.

_pferreir_ 14y ago

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.

pohl 14y ago
GWT? Seriously? I cannot think of any large, significant web app that has been written in GWT. I would consider the AWS management console to be significant.
- heretohelp 14y ago
  It actually does a lot to explain why I hate the AWS management console so much.
  - jrockway 14y ago
    Most people are users of the software, not developers, and so they hate the product because it's bad, not because it's written in Java. Wait, you don't work for Amazon, so I'm confused...
munificent 14y ago
AdWords, AdSense, Flights, Hotel Finder, Offers, Wallet, The New Blogger, Chrome Webstore, Product Search, Public Data, New Google Groups, Orkut, Google Takeout, Google Pagespeed, Google WebFonts, Google Tables, Google Health (discontinued), Google Wave (discontinued), PlayN (basis of Angry Birds) http://gwtreferencelist.appspot.com/#AboutPlace http://gwtreferencelist.appspot.com/#AboutPlace:
- _pferreir_ 14y ago
  OK, I stand corrected. Still, that doesn't make it a good idea. Not to mention that most of those apps are Google products.

hblanks 14y ago

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.

vtry 14y ago

Try AngularJS ;)

btford 14y ago

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.

dxbydt 14y ago

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.

Arelius 14y ago
> 200 average developers This is the problem, and as you implicate, the exact sort of thing we need to stop doing.
- taligent 14y ago
  Sure. So long as you have a full proof way of identifying the best developers. Hint: the best developers aren't the ones who can recite the API off hand.

mattdeboard 14y ago

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

dougabug 14y ago
Because a hundred files must be worth ten times as much as ten files. Maybe he gets paid by the file.
kevincennis 14y ago
I tend to like having discrete modules of code split up into separate files when I'm building large JavaScript apps (which is really all I do). It helps keep me organized. And I think it also makes version control run more smoothly. Generally, I'll write a little build script in Node that concatenates and minifies all my JS and CSS before actually deploying to production to keep the number of HTTP requests down.
bitcrusher 14y ago
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 14y ago
  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.

theojapa 14y ago

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.

felipellrocha 14y ago

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

orthecreedence 14y ago

"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 14y ago
"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 14y ago
  Big surprise: junior developers who've only been taught to architect for statically typed language are lost in dynamic languages.
munificent 14y ago
> Also, you can't ignore that this is hosted by Adobe... This may be true, but it's an ad hominem attack.
- lowboy 14y ago
  It might be ad hominem out of context, but I don't feel it's improper to question the motives of someone working for a company that would most likely benefit from a decline in javascript in the app space. http://en.wikipedia.org/wiki/Ad_hominem#Questions_about_the_notion_of_an_ad_hominem_fallacy http://en.wikipedia.org/wiki/Ad_hominem#Questions_about_the_...

jwilliams 14y ago

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

gruseom 14y ago

Is there any credible data on static vs. dynamic typing?

paganel 14y ago
I'm not a specialist on this topic (i.e. I'm only a programmer, not a computer scientist), but I don't seem to remember any links posted to relevant such studies in any of the "static vs. dynamic typing" flame wars. Also, a little bit OT, I've been a professional programmer for 7 years now (i.e. getting paid to write code) and to this day I'm not sure 100% what's the difference between "0", "NULL", "None" or an empty string. What type does "None" belong to? Can I compare it to the integer 0?
- anentropic 14y ago
  "I've been a professional programmer for 7 years now (i.e. getting paid to write code) and to this day I'm not sure 100% what's the difference between "0", "NULL", "None" or an empty string. What type does "None" belong to? Can I compare it to the integer 0?" been doing PHP by any chance? ;)
artsrc 14y ago
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.
- neilk 14y ago
  Actually, the study found that static languages were worse. They tested students on two problems. In one there was no significant difference, and in the other the static language performed worse. Here is that study: "An Experiment About Static and Dynamic Type Systems", by Stefan Hanenberg, University of Duisberg-Essen, 2010. http://www.cs.washington.edu/education/courses/cse590n/10au/hanenberg-oopsla2010.pdf http://www.cs.washington.edu/education/courses/cse590n/10au/... However, they didn't use existing languages; they created a brand new language and IDE that had a typed and untyped variant. Whether this confounds or strengthens the case is unclear to me. In any case, I think any survey of static type systems that doesn't include a language with type inference is very flawed. Java's type system is an annoyance in the small, and is a mixed bag in the large. Haskell's type system is a totally different story.

zdmc 14y ago

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.

thisismyname 14y ago

Tell that to twitter (period).

outside1234 14y ago

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.

deleted 14y ago

[deleted]

carlyle 14y ago

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.

dkevswain 14y ago

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

cft 14y ago

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 14y ago
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 14y ago
  Google Docs are written using Google Closure JavaScript library, not Java/GWT

adjwilli 14y ago

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

arcos 14y ago
Thank you, you win the Internet for this comment.

deleted 14y ago

[deleted]

penguinbroker 14y ago

tl;dr Shitty programmers should not work on large javascript projects.

korimako 14y ago

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.

malachismith 14y ago

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?

techiferous 14y ago

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.

losethos 14y ago

My answers is always, "More namespaces!"

harel 14y ago

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

eswangren 14y ago

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"

tmcw 14y ago

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

williamcotton 14y ago

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.

leesk 14y ago

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 http://bit.ly/M9CSXj

neilk 14y ago

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.

silentOpen 14y ago
Algebraic data type http://en.m.wikipedia.org/wiki/Algebraic_data_type http://en.m.wikipedia.org/wiki/Algebraic_data_type
- neilk 14y ago
  Which is t3h awesome, but not an option in either language under consideration, as far as I know. Unless you used a Haskell-to-JS compiler. I apologize if I implied that static typing = Java's kind of typing.
  - silentOpen 14y ago
    js_of_ocaml http://ocsigen.org/js_of_ocaml/ http://ocsigen.org/js_of_ocaml/

elliotlai 14y ago

"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-assembly http://blog.izs.me/post/10213512387/javascript-is-not-web-as... Yes, I love Haskell and I do some CoffeeScript but JS is a fairly decent language to me : )

jcromartie 14y ago

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

mcantelon 14y ago

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

eriksank 14y ago

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.

underwater 14y ago

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.

hermanhermitage 14y ago

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 :)

usablebytes 14y ago

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.

einhverfr 14y ago

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.

user49598 14y ago

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.

blrblr 14y ago

I guess Adobe Flash is. /s

nathants 14y ago

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? :)

anmi 14y ago

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.

Jangaroo 14y ago

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!

n-gauge 14y ago

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

denysonique 14y ago

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,-and-Companies-Using-Node https://github.com/joyent/node/wiki/Projects,-Applications,-... http://documentcloud.github.com/backbone/#examples http://documentcloud.github.com/backbone/#examples

queryly 14y ago

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.

pohl 14y ago

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/Dart-A-Well-Structured-Web-Programming-Language http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012/Dar...

wheeyls 14y ago

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

bdorman 14y ago

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

goggles99 14y ago

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?