JavaScript is not suitable for large web apps

http://blogs.adobe.com/bparadie/2012/05/07/the-pew-pew-manifesto

by superasn • 14 years ago

186 204 14 years ago

blogs.adobe.com

marknutter2• 14 years 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• 14 years 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• 14 years 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.

mixitup125• 14 years ago

Also, define large scale. Plenty of large scale applications can and are written in languages like Python.

TazeTSchnitzel4• 14 years 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• 14 years ago

Not exactly - ActionScript3 is pretty much as close as you can get to what JavaScript2 would have been - Ecmascript 4.

codebearded• 14 years 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• 14 years ago

Dynamic typing isn't the problem; weak typing is the problem.

mistercow6• 14 years 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.

munificent5• 14 years 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.)

MartinCron3• 14 years ago

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

Great, so now the documentation for the function will promise to return a motorcycle, but instead return either a bunny or a toaster.

There are lies, damn lies, and boilerplate code comments.

mixitup125• 14 years 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• 14 years 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• 14 years 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• 14 years ago

I switched to Coffeescript and rarely if ever look back...

mistercow6• 14 years 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• 14 years 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/

hellopat• 14 years 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).

pooriaazimi4• 14 years 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.

Androsynth• 14 years ago

doubtful. As a JS dev, I often find myself in situations where I wish I was working with CS instead.

However, this article isnt advocating CoffeeScript (well it is, but it doesnt actually make a case for it), its advocating using a statically typed language. CS gives you classes, but thats not a big deal (module pattern makes it trivial to implement classes in JS).

To scale your web app, the author is advocating writing your apps in Java, C# and actionscript.

Now that I think of it, this is a really poorly laid out argument. It spends most of the time arguing for static typing, then throws in CoffeeScript as a sop to the people who will flame him for advocating Java/C#/AS.

joshontheweb• 14 years ago

I haven't switched to coffeescript but I have worked on several coffeescript codebases. Its not the end of the world, but I don't prefer it. It is an unnecessary level of abstraction and is fragmenting js. It also seems the coffeescript users tend to use haml and sass as well. When I am working on those projects I feel like I am drowning in preprocessors and frequently encounter cryptic errors as a result.

drivingmenuts• 14 years ago

I can't speak for haml, but sass is certainly a welcome tool in dealing with CSS, since it mostly uses CSS syntax, with sensible nesting to keep things orderly. sass takes what you already know and kicks it up one notch (perhaps two, if you want to use variables).

heretohelp6• 14 years ago

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_erik3• 14 years ago

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.

GnarlinBrando2• 14 years ago

Personally I think its great because it is just a different syntax for the same semantics.

pjungwir• 14 years ago

I've used Coffeescript on a couple large Rails projects, and I'd rather stick with Javascript. I haven't encountered any terrible debugging hurdles, but it just seems like obfuscation. And unlike one of your other respondents, I love Sass and Haml. I have nothing against preprocessing per se, but I haven't yet figured out what value CS adds. I appreciate easier iteration, but that's about it. But considering how many people rave about it, I'm willing to learn....

lucisferre2• 14 years ago

This article doesn't really look like it's worth my time to read in depth so I won't comment on it directly. But as far as javascript goes Coffeescript makes a lot of the idiosyncracy of javascript that create constant cognitive friction go away. I personally can't find any good reasons to not use coffeescript.

coenhyde• 14 years ago

I switched to CoffeeScript and continue to use it for 90% of my projects. CS shines in the application domain, but don't use it when writing modules or a complicated application where you'll be debugging lots of logic errors.

pooriaazimi4• 14 years ago

I don't know what this article is about (looks like it's not worth reading), but I've switched to CS (IcedCoffeeScript, to be precise) for my Node.js app (a behemoth of an app!), and am much much happier. Sure, it has problems too, but they are more tolerable than having to do (if typeof(x)=='function' && x!=null) over and over again IMO, and the vast majority of them will be gone when we have SourceMaps (which shouldn't take long, maybe a couple more months).

xd• 14 years 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• 14 years 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• 14 years 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.

mixitup125• 14 years 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• 14 years 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.

pork2• 14 years 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.

chrisbroadfoot• 14 years ago

It's a false analogy. Javascript is just as high level as Java or CoffeeScript.

Sure, it's the "assembly language of the web," but Javascript certainly cannot be compared to assembly language in this way.

Achshar• 14 years 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?

mistercow6• 14 years ago

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

kevincennis2• 14 years ago

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

TazeTSchnitzel4• 14 years ago

Funnily enough, that also applies to:

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

jsnk• 14 years ago

node.js is written in JavaScript.

lmm3• 14 years ago

Not true. I've seen some very successful large webapps in poorly-written Java.

pnayak• 14 years ago

yeah agree to this :) poorly structured and architected code written in any language will not scale..

voidr2• 14 years 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.

Arelius3• 14 years 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.

voidr2• 14 years 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.

untog• 14 years 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.

CmdrKrool• 14 years ago

And also because browser-side JavaScript does not have standard modules, where one is able to 'import' another. So even in the development phase, pre-minification, one is discouraged from making new files because of the pain of adding corresponding <script> tags in the HTML file or files and then getting them in the right order, and the larger the project the less you want to be tracking those dependencies manually.

While you can use a module loader library you still have to choose one, learn it and its quirks and adapt other external libraries to use it (some of which might be written for another module loader or - horror of horrors - use their own half-arsed module system).

As for "file-stew" mentioned by the sibling comment, small units are good if you like code reuse. For example, I get sick of writing very basic classes like 'Rect' and 'Vector' (for graphics) over and over again.

daba2• 14 years ago

In my opinion "That’s not so useful, though, if you want to have multiple developers work on the same project." is much more revealing. Has this guy never heard of VCS? If you use a modern VCS it does not make any difference if you split your source into lots of different files or have it all in one. At least not regarding the number of developers working on the project.

trimetric• 14 years 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• 14 years 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_3• 14 years 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.

pohl2• 14 years 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.

heretohelp6• 14 years ago

It actually does a lot to explain why I hate the AWS management console so much.

munificent5• 14 years 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:

_pferreir_3• 14 years 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.

mping2• 14 years ago

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.

cashew• 14 years ago

GWT's RequestFactory feature particularly stands out as a huge productivity win for CRUD apps. Also, many of the weaknesses commonly associated with Java are diminished now that Google's excellent Java libraries (Guava, Guice) have become more widespread (with GWT versions also avaiable).

But I think people try GWT once, realize that the built-in widgets and panels look terrible and never look back. But some of the features that they don't get to trying are the features that really makes GWT worth using (the EventBus, RequestFactory, UiBinder, the excellent localization support, etc.).

GWT also doesn't preclude using any other JavaScript libraries. JSNI (writing native JavaScript within GWT Java source) is relatively easy -- I don't think it is uncommon to pull in JQuery in a GWT app for its effects, for example.

_pferreir_3• 14 years ago

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.

hblanks• 14 years 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• 14 years ago

Try AngularJS ;)

btford• 14 years 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• 14 years 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.

Arelius3• 14 years ago

> 200 average developers

This is the problem, and as you implicate, the exact sort of thing we need to stop doing.

taligent• 14 years 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.

apl• 14 years ago

  > This is the problem, and as you implicate,
  > the exact sort of thing we need to stop doing.

You do see the absurdity here, right? Banking on substantially above-average developers doesn't work at scale, by definition.

heretohelp6• 14 years ago

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

mixitup125• 14 years ago

malandrew2• 14 years ago

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.

krschultz• 14 years ago

I'm not happy that the top reply to the top comment on this post is a blatant ad hominem.

What's your point about JavaScript?

grimlck• 14 years ago

Instead of comparing '20 smarty JQuery guys' with '200 average Java programmers', how about comparing '20 average JQuery programmers' with '20 average Java programmers'? Or comparing '20 smart JQuery guys' with '20 smart Java programmers'.

Hovertruck• 14 years ago

There is no such thing as a jQuery Programmer. There are JavaScript programmers who are familiar with jQuery.

nathan_long• 14 years ago

200 developers of any kind simultaneously working on the same code base sounds like a nightmare to me. I sincerely hope they have many separate projects that communicate via APIs or something.

mcot2• 14 years ago

I guess I am not understanding why you would be compelled to re-write massive Java apps in JavaScript. Especially anything to do with heavy finance algos.

Replacing swing UI's seems like a reasonable thing to tackle using HTML/CSS/JavaScript. You could just pass data back and forth over HTTP if you are talking remote client/server or bundle a local webserver if running host only.

In the case of a platform like Windows 8, you can write actual apps using JavaScript (no server) but you can also write libraries in native code and access them directly from the JS.

I think this is just a classic case of "use the right tool for the job".

einhverfr2• 14 years ago

Moreover the original author says

"JavaScript is not suitable for large web apps.

I am serious: Don’t write large web apps in JavaScript."

I don't know how the first flows from the second. Certainly I wouldn't write a large web app in Javascript! I might write Javascript in a large web app though.

So I agree and think the original article overreached.

atesti• 14 years ago

Why exactly would one run financial pricing functions inside the browser? Doesn't this stuff belong in the backend and far out of the users reach? Isn't that insecure or gives up secret stuff?

regularfry2• 14 years ago

I don't think they're running in a browser on the open web.

rehack• 14 years ago

I think your example of an Enterprise Finance app and TONS of Java programmers is over generalizing things a bit, of who can benefit from things like GWT.

I would contest, GWT is used by some people who sort of already grokked some of the points made by this article, some years back. For example, coding in JS giving a feel of coding in assembly, particularly without the help of any good editors.

Another example to break the Enterprise only narrative: 'Google Flights' is done in GWT. And you and me can guess, there won't be 200 avg developers coding that product.

I came from an Enterprise background before our Internet Startup. Few of us coded up our app, in 3 months flat out using mainly Java and GWT.

One of the reasons we chose GWT was that, when we started out IE 6 still had a considerable share, and GWT generated JS which ran on it very well (although slowly).

allanebdrup• 14 years ago

You fail to make a general point about JS. Instead you make the point that jQuery is inadequate for large apps, and I agree. Just because you failed with jQuery dosent mean JS can't be used. I've seen Big JS projects go horribly wrong, but I've alse seen big C# projects go horribly wrong (And COBOL and ...). Every time the projects didn't have good tests, a CI server, nightly builds, structured code reviews, a modular and simple design etc. If you use all the good practices available, big JS projects become maintainable. It shines through in your post that you didn't do it close to right.

mattdeboard• 14 years 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• 14 years ago

Because a hundred files must be worth ten times as much as ten files. Maybe he gets paid by the file.

kevincennis2• 14 years 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• 14 years 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.

artsrc2• 14 years 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• 14 years 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• 14 years ago

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

orthecreedence• 14 years 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• 14 years 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• 14 years ago

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

munificent5• 14 years ago

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

This may be true, but it's an ad hominem attack.

lowboy2• 14 years 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_...

jwilliams• 14 years 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/

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.

gruseom2• 14 years ago

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

paganel• 14 years 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• 14 years 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? ;)

artsrc2• 14 years 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.

neilk4• 14 years 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/...

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.

gruseom2• 14 years ago

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?

zdmc• 14 years 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• 14 years ago

Tell that to twitter (period).

outside1234• 14 years 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.

carlyle• 14 years 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• 14 years ago

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

cft2• 14 years 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• 14 years 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?

cft2• 14 years ago

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

adjwilli• 14 years ago

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

penguinbroker• 14 years ago

tl;dr

Shitty programmers should not work on large javascript projects.

korimako• 14 years 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• 14 years 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• 14 years 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.

harel• 14 years 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• 14 years 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• 14 years ago

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

williamcotton• 14 years 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• 14 years 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

neilk4• 14 years 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.

silentOpen2• 14 years ago

Algebraic data type

http://en.m.wikipedia.org/wiki/Algebraic_data_type

neilk4• 14 years 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.

prophetjohn• 14 years ago

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

neilk4• 14 years ago

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.

hatsix3• 14 years ago

His example was an exaggeration... It seemed obvious to me, but maybe not to everyone else.

A more real-life example is that it's very easy to accidentally return a number when you meant to return a string.

But yes, AS does support multiple interfaces.

elliotlai• 14 years 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-as...

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

jcromartie• 14 years ago

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

mcantelon• 14 years 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• 14 years 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• 14 years 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• 14 years 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• 14 years 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.

einhverfr2• 14 years 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• 14 years 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• 14 years ago

I guess Adobe Flash is. /s

nathants• 14 years 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• 14 years 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• 14 years 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• 14 years ago

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

denysonique• 14 years 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,-...

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

queryly• 14 years 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.

pohl2• 14 years 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/Dar...

wheeyls• 14 years ago

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

bdorman• 14 years 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) 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• 14 years 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?

JavaScript is not suitable for large web apps

Related Stories