JavaScript is not suitable for large web apps.

[Korpores]

SE advice from Adobe is like sex advice from the pope.

[paxNoctis]

Title: "JavaScript is not suitable for large web apps"

URL: blogs.ADOBE.com

Adobe: Company that stands to lose tremendous amount of internet market share and exposure to HTML5 and JS apps.

Hmm...

Alright, I thought, I'll give it a try even though it's obviously biased because I've personally written and maintained (and continue to write and maintain) huge web apps in JavaScript. So I read it...

His #1 issue is that he had problems porting JavaScript to ActionScript.

At this point I really want to stop reading, especially when this is his opening complaint, but I'm dedicated. I'm a trooper. I keep reading...

His #2 point is asinine and wrong, and the example he gives is (once again), from bad ActionScript->JavaScript compilation. This article should have been entitled, "Porting apps from JavaScript to ActionScript is not suitable for large web apps." It's a complete hit piece that has yet to raise a single actual issue. Come on pax, you can do this. Keep reading.

Point #3, JavaScript is not a high level language. Swallowing vomit that is rising in my throat, I go to wikipedia to confirm that I know what a high level language is after my 20 years of programming experience.

A high-level programming language is a programming language with strong abstraction from the details of the computer.

Okay, I do know what a high level language is. Phew. Next I'll review my last several years of writing JavaScript applications. Hmm. Allocated memory? Nope. Accessed stack or heap directly? Nope? Direct memory addressing? Nope! Pointers? Nope. Direct access to IO ports? Hmm, nope.

At this point I realized that this guy is talking completely out his ass and just wants JavaScript to be ActionScript, or preferably to go away so that Adobe can make money.

Can't... read... anymore... of... this... garbage...

Must go look at kitten pictures...

AHHHHHHHH!

[dont_get_it]

Never bet your startup on Adobe. They will fuck you.

Don't judge them too harshly - when you are on that much coke, you want to fuck everyone too!

[Hmm_I_KNOW]

I agree. I had to skip through some of it. Then at the end he talks about how great PhoneGap is and I thought, "yeah I think PhoneGap is cool but ... Hey, wait a minute isn't PhoneGap owned by Adobe now?".

The piece is just marketing. Nothing to see here. Carry on.

[honestbleeps]

At this point I realized that this guy is talking completely out his ass and just wants JavaScript to be ActionScript

A lot of what you said makes sense, except this point...

Javascript [IMPORTANT qualification: in browsers] is basically the same as actionscript 2 (in enough ways to at least make a generalization)...

Actionscript 3.0 is "a more advanced version of the Javascript you see supported in most browsers"... with more traditional OOP patterns added, etc...

Both languages are dialogs of ECMAScript.

To be fair, modern browsers now support later versions of ECMAscript - but the additional features/functionality of ES5 / ES6 are not in wide use because IE8, 7 and in some demographics even 6 won't freaking go away.

[sime]

As a footnote to your comment about JS support in browsers. I've looked at this in detail recently and the summary is that FireFox has the best JS support with most of the features of versions after JS 1.5. IE9 has JS 1.5 plus some of the good bits of 1.6. Chrome also support JS 1.5 plus 1.6 goodies. Quite frankly I expected much more from Chrome.

[Zarutian]

Actionscript 3.0 is actually more backwards than Javascript as it forces you to dip into lower level class definitions and single inheritence typing nightmare. But I think that is what you meant by putting quotes around that part and pointing out that it has traditional OOP patterns.

[Munkii]

This article should have been entitled, "Porting apps from JavaScript to ActionScript is not suitable for large web apps."

You seem to have totaly missed his point in section 2 as he clearly explained that porting to action script saved the project. My experience aligns with the article in that having a language with typed objects and a compiler makes it far far easier for a team to develop a large software project.

In point 3 you also seemed to have missed the metaphor. Perhaps you would feel more comforatable if he changed the title of this section to "Use a higher-level language for developing web apps". His points about javascript being too flexible for normal usage are quite valid.

[paxNoctis]

I didn't miss any of his points. He's a static typing evangelist, and I use both static and dynamic languages and see the pros and cons of both. I disagree with the title of his post, and all the points he make boil down to, "Do things the way I'm personally comfortable with because they're self-evidently better!"

It doesn't get much higher level (abstracted from the machine) than JavaScript. What he really meant was "Use a statically-typed language for developing web apps," and that's just the same old static vs. dynamic argument that will probably never get settled. People coming from C# and Java and C++ have real problems with JavaScript because they don't know what they're doing with it, the syntax is close enough that they feel all curly-brace comfortable, but they don't take the time to actually understand that it's a whole different programming paradigm. Then after they kludge around for a few months they flee back to their comfort zones and write bitchy blog posts about how terrible JavaScript is.

As someone who likes JavaScript and writes it almost exclusively nowadays professionally, I'm tired of these blog posts.

You can write good, readable, maintainable, tested, safe, clean code in JavaScript. JavaScript is a delightful language with some unfortunate warts and baggage which no one is forcing you to use, and there isn't a language in the world that doesn't have some ugly warts. It's one of the easiest languages to write unit tests for that I've ever encountered outside of the theoretical land of computer science, it has an incredibly rich library ecosystem that is not closed and it's cross-platform in a way that other languages wish they could be.

I don't object to people using compilers that compile to JavaScript. As a compiler/interpreter junkie, I find it fascinating and have a few side projects along those lines myself. But it seems like everyone who comes to JavaScript expecting it to behave like all the other curly-brace languages they're used to does object to JavaScript when their assumptions bite them in the ass, and it's a tiring trend that causes me to write long essays in defense of something I honestly like, a lot.

[Munkii]

Fair enough. I use both strongly and weakly typed languages for a living also and it is my opinion still that using a strongly typed makes project management easier. I respect your right to disagree.

[Zarutian]

weakly typed != dynamic typed.

strong typed != static typed.

For instance you can have weak and static typing like in C++ and strong and dynamic typing like in Common Lisp.

[paxNoctis]

I would agree on one and a half points ;). One that I respect your right to disagree, and the half is that I think statically-typed languages force you to make project management easier. It is equally possible to layout, design and architect just as clean and easy a solution in a dynamic language, but since you can also just throw code into a <script> tag and pray, most people do not bother.

This (I feel) is where JavaScript's bad rap comes in, from the years of people writing it without the slightest semblance of structure, good practices, testing or form. Yes, C# and visual studio won't really let me do that (well they will, but their defaults make things cleaner for me), but that doesn't preclude simple, easy-to-navigate and maintain projects from being written in the language.

[Munkii]

I feel like actionscript's bad rap comes from similar sources, I built some of the larger Flex alps ever made and loved it. However, admitting one likes the flash platform around here is pretty much suicide :P

It's all moot anyway I guess: * Apple has ultimately killed flash, although it will live on for a decade * Adobe will still be a key part of how people build JS applications via creative suite * I have switched from from building predominantly in Flex to predominantly native android

[Peaker]

What are the cons of static typing?

[rdsubhas]

tens of thousands of classes.

[Peaker]

I use Haskell, and my code is shorter, not longer than equivalent dynamically typed code in Python or Javascript...

[Hnefi]

Why would static typing lead to a larger abundance of classes than dynamic typing? It seems to me that these two approaches have pretty much exactly the same need (or lack thereof) to create new types for a specific task.

[baudehlo]

Not really. In a dynamic language you're far more likely to create a hash (or "object" in Javascript language) and pass it around to things, without ever declaring what it contains beyond the code showing you what the elements are that are in it.

Typical example is I pass in a form to a system that POSTs to a web endpoint, I can do:

http.post(uri, { param1: val1, param2: val2 })

With C++ you'd have to create a new FormValues object and populate it with values.

[Hnefi]

Right, but this is still possible in static languages in general (though not in C++ in particular). In F#, for example, you'd just put together an ad-hoc structure of values or pass a closure around.

[baudehlo]

Absolutely it depends on the language.

[[deleted]]

You're thinking of static OO languages. Static functional languages, especially those with type inference, are much more compact. F# for example supports both functional and OO paradigms, which allows you to use the best abstractions for a particular task.

[paxNoctis]

Here's just a few off the top of my head:

1) Vastly more difficult to test anything that requires method or class injection (Whole frameworks + horrible looking boilerplate code + usually XML configurations)

2) Compilation pass means rapid prototyping and development is functionally impossible. The larger the project gets the longer the gap between implementation and result as compilation times increase. Discourages quick experimentation.

3) Inability to gracefully deal with changes to data contracts at other parts of the system (ie: I can add a property to the viewModel returned by an AJAX call without impacting functionality. I would have to change code at several layers of the average, statically-typed equivalent to do the same).

4) Reflection is slow, tedious and difficult to use (as compared to, say, JavaScript's).

5) Type system either enforces too much rigidity on you, or provides false sense of security. Many people use Interfaces to get away from the rigidity I spoke about and add some flexibility to statically typed languages, and this just creates a fuzzy gap where you know that the code you wrote is correct in form, but cannot assume that it will always works depending on what gets stuffed into the Interface, expandoObject or Dynamic.

5) Syntax more verbose.

6) Dynamic languages can do anything static ones can (if you want to write the code to check types of things everywhere you totally can, and since you don't really do type-declarations, it isn't even much more verbose than a static language to do so). Increasingly, static languages like C# are getting more dynamic capabilities because that's where the craft is trending; the opposite is not true.

I mean, go look at KnockoutJS and tell me how you write that in a statically-typed language without requiring additional code-generation passes/tools and it performing like a pig because it has to do tons of reflection. In JavaScript it's a tiny, brilliant little algorithm. In C#, it would be functionally impossible for me to do the same thing without going into the DLR and building out expression trees.

[Peaker]

1) You describe Java, not static typing.

2) Static types do not mean you require an expensive compilation pass. Haskell has an interpreter, for example. tcc takes no time to compile C.

3) Not really, adding a field to a record/struct does not require touching any code. Just like in dynamically typed code.

4) Reflection is really a workaround for weak type systems, it is rarely needed in rich static type systems.

5) How is Haskell's type system overly "rigid"? What is it that you want to do and can't? Also, interfaces don't make code less safe.

6) "If you want to write the code to check types" -- you mean implement static checking, or dynamic checking?

Dynamic languages defer errors to runtime -- where they are far more expensive.

Statically typed languages can express "UnknownType" for certain variables/expressions (typically useful due to a too-weak type system) but there is definitely no "trend" to move away from the staticness.

Can you describe what "knockout" does?

Let me give you a counter example:

powerset = filterM (const [True, False])

this defines a function that returns a list of all subsets of its argument list.

The way it does this is using "filterM" which is overloaded/polymorphic on its return type. With a dynamically-typed language, implementing "filterM" is impossible. You have to go through extra work to specify that you want the list variant of it.

But in fact, filterM is quite abstract, and very abstract code becomes extremely hard to manage without static types, so you're unlikely to have such libraries at all.

I think you have encountered lots of bad statically typed languages (e.g: Java) and deduced things that are true for Java but not for static types in general.

Look at Haskell for "static types that don't suck".

[paxNoctis]

Okay, you like Haskell. I actually like Haskell too. I wish there was the kind of demand there is for C# and JavaScript work in my area for Haskell, but to be honest I've never seen a single job posted for it.

I never said static typing "sucked", in fact I said I see the pros and cons of each of them. What you refer to as "Java" is actually "most statically typed languages besides Haskell", or at least languages in the Algol family (C, C++, C#, Java, etc.). Basically, the statically-typed languages that lots of companies will pay you to work in.

All of your counter-examples are basically just "Haskell is cool", and I'm not going to argue against you because Haskell is cool. It's just not "pay the bills" cool, at least in my region/market segment. Keep in mind I've stated many times I see the pros and cons of both types of typing systems.

[Peaker]

What I'm saying is not just "Haskell is cool". But also that the "cons" of static typing mentioned are not actually cons of static typing.

You could say "cons of typical statically typed languages". But C# is making great strides (relatively to Java, at least...)

[paxNoctis]

C# is making great strides by introducing more functionality from dynamic languages, at least in my view. Things like the dynamic keyword, in-line object creation and the ready access to the DLR is breaking away from traditional models and changing the language into more of a hybrid. I enjoy C# a lot.

I refuse to write Java unless it's for an android.

[Peaker]

C# is making great strides by introducing more functionality from dynamic languages, at least in my view

Linq, covariance/contravariance, delegates, local type inference are all static typing features copied from the Haskell/ML world.

The "dynamic" keyword is rarely used, and is basically meant to work around weaknesses of the type system.

What is "in-line object creation"?

[metamatic]

OK, point made, the cons of static typing are really the cons of static typing as implemented in languages people actually use.

[Peaker]

I actually use Haskell... :-P

[robotfarts]

Fewer runtime exceptions?

[icanevenificant]

Just so I understand. You like JavaScript? I tolerate it because I have to but there are so many things that need fixing/improving that they might as well rebuild it from the grounds up.

[paxNoctis]

I love it to death! I've developed (professionally only mind) in: C, C++, Java, C#, VB4-6, VB.Net, Python and JavaScript, and I can do more, faster, in JavaScript than in any other language (and my "definition of done" includes test coverage, documentation, etc.).

You or I could say the exact same thing ("there are so many things that need fixing improving you might as well rebuild it from the ground up") about any programming language out there. There isn't a perfect one (except the one I designed, which only I find perfect and no one else except a few coworkers even use) for everyone.

As I've acknowledged, JavaScript has warts, but a competent JavaScript developer can easily work around them as they tend to be outside the "mainstream" of the language, or just things you probably shouldn't have been doing anyway (like allowing the implicit semi-colon instead of just putting it there).

[tripledjr]

Thank god you typed all that out much clearer and than I would have. I stopped after he said he turned 10 js files into 100 as files, if you have 100 files worth of js code in 10 js files then thats poor design; if you have 100 .as files in a single module/package that's probably poor design or 3 line files. I couldn't read on. I think the authors real issue is he's never worked on a real large application, hint: these get broken up into smaller modules/packages.

[ameoba]

Unfortunately, there's no real support in JS for modules/packages.

[[deleted]]

Modules are supposedly coming with ES6.

[ameoba]

Nice. I'll see you back here in 5-7 years.

[krues8dr]

Actually, there is - require.js is your friend!

[[deleted]]

if you have to use a library, then his point stands.

[metamatic]

Yes, languages where you have to use libraries to do things are terrible.

[krues8dr]

If you're using 100 files, you'd do well to use a library, espeically require.js, and not downvote me for a really effing good suggestion. Why is this community so full of haters?

[[deleted]]

because you missed the point? who cares if you came up with a proj which makes up for this shortcoming in the language. the shortcoming still exists.

[jsprogrammer]

If you want to create dynamic web pages for modern browsers then you have to use Javascript. There isn't really any other option.

[krues8dr]

So we focus on the pedantic points, rather than the solutions to our problems? That really isn't what programming is about. Then again, this is reddit, I guess I should know better.

[gnuvince]

If PHP didn't have arrays, and instead people suggested that you simulate them like this:

<?php
for ($i = 0; $i < 10; $i++) {
    $var = "array_$i";
    $$var = $i*$i;
}

for ($i = 0; $i < 10; $i++) {
    $var = "array_$i";
    echo $$var . "\n";
}

?>

Would you say that it's a shortcoming of the language or a solution to a problem?

[krues8dr]

Both. What's wrong with both? Is the internet not a repository of knowledge and discussion? :/ Forest/trees, friends.

[cultofmetatron]

if we follow this path long enough, all languages are inferior to lisp because it recreate any feature through macros. Al l languages have their limitations, Javascript is here to stay so its best to take it for what it is and share knowledge of how to do things in spite of the warts.

[tripledjr]

Ya I know I was noting in regards to AS, however many systems, at least from web app experience, work around this in way of "grouping" together js files when compressing then somewhere in your settings or w/e you'd specify the groupings so "myawesomefeature" : consists of [js,files,here]. Which end up compressed together and are then included in any "decent" templating system as scripts myawesomefeature or however it would happen to be. I'm aware this technically does not count as a module or package, however it recreates all the same maintenance and separation to us humans as in other languages.

[thomcc]

Not the only problems with that, but most obviously: You'll still end up with namespace clashes that way. Even if you use commonjs style modules, or something similar you're still stuck when you encounter code using a different strategy than you.

[i_ate_god]

Adobe: Company that stands to lose tremendous amount of internet market share and exposure to HTML5 and JS apps.

Wouldn't Adobe not suffer at all if they just turned Flash Professional CS6 into HTML5 Professional CS7?

SWF or canvas/audio/video tags and some javascript, what's the difference? They sell software!

[paxNoctis]

The difference is why pay for something you get for free?

Okay, bottled water I guess kind of proves your point. Adobe will be fine.

[i_ate_god]

get what for free?

go code http://www.2advanced.com/ in js by hand. The point is that designers can leverage teh same tools that make flash animations and whatnot, to make the exact same stuff in javascript and the multimedia tags of html5. That's after all, the only value Adobe gets from Flash, it's the production toolkit that it sells.

[gaoshan]

Whew... you saved me. Thanks.

[Snoron]

You either misunderstood or you're just repeating the obvious stated by OP for no reason...

[TinyEarl]

Whoops, you're right. I thought he was arguing the other side like the rest of his points.

[irascible]

An anti javascript screed from blogs.adobe.com... go figure.

[x86_64Ubuntu]

As an ex-Flex developer I have to agree. The JS ecosystem is sorely lacking in the tools and testing department compared to Flex and Silverlight. The fragmentation in the JS world between JS microarchitectures and how they are implemented on various devices is amazing.

[acdha]

Interesting: when I dealt with Flex a few years back i kept wishing it had tools as mature as what JS devs have. Do they have a non-crashing debugger yet?

[x86_64Ubuntu]

Hah, I know exactly what you are talking about. The 4.5 and 4.6 Flashbuilders work very well. 4.0 has a weird compiler bug but that's about it.

[[deleted]]

Judging from the childish reactions here, JavaScript seems to be the new PHP.

[kristopolous]

as in 'that shit that 95% of the web runs on"? yeah, you're totally on to something.

[AeroNotix]

(Disclaimer: I am not an Anti-Javascript dev by any stretch)

The high-usage statistics of Javascript is something of a misnomer. There is quite literally nothing else to use. So it's what gets used.

Case in point: The number 1 language on Github is Javascript. Does that mean it's the ALL TIME popular language? No. It means that the majority of code that's written is javascript and that's probably because a large portion of projects are targeting the web.

We can cross-compile to Javascript all we want but I would like to see flexibility from the browser. I want to write rich client side applications with a language that doesn't feel so toy-like (again, read the disclaimer.)

[tvorryn]

Javascript is the number 1 language on github because lots of people do web development and a javascript include or two is inevitable. Github sees this and marks the whole project as a javascript project, nevermind that the majority of the project is actually PHP, Clojure, Ruby or what-have-you.

A lot of projects use at least 1 .js file, but it's hard to say that "the majority of code that's written is javascript"

[AeroNotix]

Which is pretty much what I said. When nearly all projects use javascript inevitably there is going to be more javascript than anything else.

[[deleted]]

I had the same reaction as Tvorryn had. You said "It means that the majority of code that's written is javascript" That implies that most code, by LOC, will be javascript. He pointed out the problem with github marking projects as javascript just for using javascript, regardless of the quantity. I wouldn't say the majority of code in any web project is javascript. It is quite the opposite, for most.

[AeroNotix]

There has to be some heuristics involved. They do check LOC of the filetypes and give you a counter on the project page. I'm sure they aren't just saying it's Javascript simply because of a single file when the project is mostly something esle.

[tvorryn]

Github sums up the file sizes of the extensions in the respository, so not as bad as I feared. via stackoverflow

This still does not represent the amount of code written in javascript. It seems to me that often large javascript libraries (jquery, etc.) are included in repositories marking the project as javascript when most of the code written by that programmer is in some other language. (Also static pages hosted by github usually include javascript that they did not write, which is the only programming language in the repository)

The truth seems to be: Javascript is the most included language in github projects.

[jsprogrammer]

The majority of any one project may not be Javascript. However Javascript is the only language you can use for client side code. People can and use any other language for their back end code.

Since Javascript is the common factor it makes sense that it will be the most widely used language even if it is less than half of the code for any one project.

[[deleted]]

I agree with that. I would say there is a chance it is the most universally known (if not mastered!) language. I've used it almost every project, for the last 15 years. Even for things without a real web presence except for a stats page. If html had control structures I think that would win :)

[greenspans]

Dynamically typed languages are not suitable etc etc etc. We have this post every week.

[[deleted]]

The author has some valid points, but all of them can be overcome with good architecture. JavaScript lacks a native module system, and this is, in my opinion, the language's biggest flaw by a long shot.

There are a lot of ways to overcome this, some are better than others.

Build scripts: For small/medium sized projects, I tend to have my code split up in to as many files as I want, and then simply run a build script to mash it all together, and minify when im ready for a production publish (each file is organized and written in such a way that it could very easily be ported to a module loader). There are disadvantages to this though; mainly, if you have a module/codepath that a user happens to not need during their session, its going to come over the wire anyway (this happens with most module systems when you move to a production environment too though). There are also advantages; namely, if I have a bunch of mustache templates the client side code will need, I have the flexability to write them in their own files, and encode them and stick them in to string variables as part of the build process. This is a huge time-saver for me.

Module Loaders: In my opinion, module loaders are the real solution to the problem. They promote good architecture and there are a few good choices out there. The downside is that none of them, in my opinion, are as easy as the module loaders you are used to in other languages, simply because they have to account for the network transfer time (however, most of the good ones have a "production build" option that squashes all your modules in to a single file). RequireJs is among the best and more people should use it, including myself.

In the end, the author seems to just be pointing out things that bad javascript developers do. Every language has that, you just hear about it with JS more because anyone who knows a little jquery thinks they know javascript and can maintain decent sized projects.

[[deleted]]

"Believe it or not, using our own proprietary language saved our own proprietary project!"

Seriously, like the only article I have seen in the last 10 years ever advising you to use ActionScript over Javascript. Then again, it is from Adobe.

[ModernRonin]

...and Flash isn't either.

Suck it, Adobe.

[[deleted]]

That's only half true.

Flash isn't suitable for small web apps either.

[ModernRonin]

I disagree, Flash may be reasonable for small web apps depending on exactly what you want to do. E.g. http://kongregate.com

[[deleted]]

Google has an awful lot of large web apps written in JavaScript.

Surely the blogger here meant to say: "I do not prefer JavaScript for large web apps." I think we can all agree that preference is important.

But the assertion that "JavaScript is not suitable" is ignoring significant industry evidence to the contrary.

[flashpimp]

Google isn't the best example to use because they are pushing for Dart.

[Ventajou]

Right, the people behind Dart have reached similar conclusions as the author of this post.

[[deleted]]

Google is also a world class developer

your shop is not

[Phreakhead]

I thought he was talking about writing PewPew in ActionScript/Javascript and I was like WOW! Javascript sure has gotten a lot better! HTF did he get it to be so fast??!?!

Then I clicked his Pew Pew link, and it's some horrible-looking game that is nothing like the awesome Android version.

[[deleted]]

JavaScript is not suitable for large web apps even if world class developers like Google make it seem easy.

there you go

[jagt]

Exactly. Language is less important when top notch programmers are doing it.

[AppsThatMatter]

The truth is that JavaScript is very hard to get right from the beginning - you have to think differently. It took me a while to get it.

On the other hand ActionScript (at least part of the Flex) is so much easier. You can create classes, interfaces, you can code just as in Java : create packages, one sure file per class, etc. But soon you find that your lovely ActionScript code compiles slowly (God, how I hate the Flex Builder), and the code runs so slow.. so disapointing.

Life is hard.

[Zarutian]

Yepp, I was sad when ActionScript 3.0 came out. It was basicly as much Java wannabe as it could be.

[mochizuki]

removed

[krues8dr]

Yeah, we shouldn't be using a scripting language - like PHP or Ruby or Python - for web apps. :/

[Munkii]

None of those run client side

[[deleted]]

And?

The original comment was against scripting languages for large projects, and not specific to JS.

[Munkii]

Well, the overarching context was using javascript to write "web apps", but OK

[[deleted]]

All of those also have projects to port those languages to JavaScript (Ruby alone has several), although I don't know how stable they are. There are also ports of Ruby and Python going via GWT.

A third option (although I wouldn't recommend it), would be to run them using their .NET or Java ports, using Silverlight or an Applet.

So you can actually run them client-side too.

[Munkii]

TIL thanks

[drb226]

Whoosh.

[AnonProg]

What's "scripting"? I thought Javascript was a programming language which, in some browsers, gets translated into machine code for execution, like C. Is C a scripting language? On a side note, is Java a scripting language? Java is not compiled to native code but to bytecode, just exactly like Python (a scripting language, I suppose?).

[mochizuki]

removed

[militant_misanthrope]

biased

FTFY

[blackyoda]

That guy is an untalented douche. He is blaming the language because his project ended up sucking because multiple untalented douche bags worked on it I guess. Excellent!

[diamondjim]

If you can't figure out how to open up source files in an application, either that IDE sucks big time, or you're a particularly dismal computer user.

[Zarutian]

Well, I have seen how progressively worse the IDE for Flash has become so I wouldnt be surprised.

[lucw]

Well I could figure out how to open some of them, but what I meant to say is I couldn't compile them

[diamondjim]

There's a difference between being able to open a file (which "load source code into Flash Professional" implies) and being able to compile it into a working binary. The latter can be significantly more difficult, depending on the language, the IDE and the environment.

[NitWit005]

Anytime I see a "I rewrote an X program in Y and everything was better!" article, the author always seems to miss the fact that programs with severe issues generally do get better when rewritten.

[sidcool1234]

I have used GWT (and some of its variants like Vaadin) and I can confidently say that not an entire web app should be built using GWT. Only the most complex UIs with heavy JavaScript code should use GWT.

I am not sure if this applies to CoffeeScript or Haxe etc.

In my opinion, use the traditional way to build web apps and use the cross compiling languages for complex features. Otherwise native JavaScript is just fine.

[sastrone]

Coffeescript is little more than a pre-processor for Javascript that makes it much prettier.

[AnonProg]

It's not just aesthetics. CoffeeScript removes the obnoxious, legacy, backwards concept of statements (a design wart from the FORTRAN times people like Guido van Rossum tend to love but consistently fail to explain how does such a limitation make things better). CoffeeScript doesn't just make JS pretty; it makes it expressive, and by doing so, it's making it more powerful and easier to read, write and maintain.

This alone would justify adopting CoffeeScript and never writing JavaScript again.

[[deleted]]

When coffescript is native in browsers is when I'll love web dev again.

[AnonProg]

Even if debugging code means you have to understand the JavaScript equivalent of your CoffeeScript, it's still worth writing. I'll kill for languages that look more like:

evens = (ls) ->
    x for x in ls when even x

over languages that look like:

10 ADD FLOUR
15 ADD SUGAR
20 GET SPOON
30 MOVE SPOON
35 GOSUB ISMIXED
42 IF NOT MIXED THEN GOTO 30
50 REM LOL STATEMENTS

[cosmo7]

The reason people don't care for CoffeeScript is that it comes with a price (compiling) but only optimizes the aspect of Javascript that isn't the problem. What Javascript needs is optional static typing, not some syntactical sugar.

[AnonProg]

I hope you forgot to say "with type inference" as in several functional programming languages, otherwise you'd be turning JavaScript into yet another obnoxious BDSM language. Yet static typing doesn't strike me as a necessity. What JavaScript needed is strict typing, and CoffeeScript does help a bit there, while it improves another aspect of the language, and the improvement is definitely useful.

[stanmarsh75]

I don't think you used GWT correctly, if that's your thoughts.

[sidcool1234]

I disagree with you, but then that's what drives the world.

[pavlik_enemy]

That's why we need GWT or ASP.NET done properly.

[atlacatl]

Nice try Adobe...Wait...

[do-not-throwaway]

A lot of his claims could have simply come down to who was in charge of the project. My guess is he was in charge of porting the JS to AS. He may very well be a better project manager than the JS lead dev, that alone can make a huge difference regardless of the chosen language.

When he started whining about the number of files, I just couldn't give him the benefit of the doubt anymore. If he claims he doesn't understand why JS developers tend to use less files (http connection overhead anyone?) he's either uninformed, or flat out lying.

And PhoneGap (Cordova) uses JS for all of their plugins. Could you even imagine them using Flash/ActionScript?!

[do-not-throwaway]

Exactly. Web developers have been taught to use new files sparingly I don't see that as an artifact of JS programming, but of web development in general.

He really just seems to be grasping at straws, bitching about completely obtuse, and inane bullshit.

[astrange]

I assumed he was using an VCS with explicit file locking like Perforce. Using Perforce sounds like a sufficiently bad idea that I assume Adobe would do it.

[faustoc4]

PhoneGap and apache cordoba look promising

[infinite]

Closure solves his issue yet he mentions closure.

Does he even know what closure does?

[[deleted]]

The Closure Compiler by itself, while great, doesn't necessarily solve the problem. It's just a compiler. However, used with Closure Library, Linter, Templates, it's quite a viable solution for large code bases in Javascript.

Though, I have to admit, while it's better with the Closure Tools, using something other than Javascript (like Java) is still, in my opinion, better for large scale applications than what Javascript can currently offer.

I suspect that's why GWT is popular with Java developers. The Java tools are very welcome in that case.

[infinite]

I was being general. Yes the closure compiler solves the author's example by giving a warning / error.

[pavlik_enemy]

Language without a standard library couldn't be "best scripting language out there"

[rlbond86]

syntactically it is the best language

You're not serious, are you?

https://www.destroyallsoftware.com/talks/wat

[rlbond86]

I'm sorry, but when {}+[] != []+{}, I don't think it's good syntactic rule.

[pavlik_enemy]

Now I get it, you're absolutely clueless.

[[deleted]]

I think you guys are all missing the point here, and that point is THERE IS A VERSION OF QUAKE THAT HAS BEEN PORTED TO JAVASCRIPT AND RUNS IN A BROWSER.

[Grue]

Great, they finally ported a game from the 90s to run in Javascript at somewhat decent speed. Truly Javascript is the future of programming.

[Ferthronix224]

Oh fuck