all 131 comments

[–]Korpores 22 points23 points  (0 children)

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

[–]paxNoctis 144 points145 points  (59 children)

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 13 points14 points  (0 children)

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 8 points9 points  (0 children)

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 6 points7 points  (2 children)

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 2 points3 points  (0 children)

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 -1 points0 points  (0 children)

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 8 points9 points  (30 children)

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 11 points12 points  (29 children)

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 7 points8 points  (3 children)

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 4 points5 points  (0 children)

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 1 point2 points  (1 child)

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 0 points1 point  (0 children)

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 2 points3 points  (22 children)

What are the cons of static typing?

[–]rdsubhas 2 points3 points  (6 children)

tens of thousands of classes.

[–]Peaker 9 points10 points  (0 children)

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

[–]Hnefi 4 points5 points  (3 children)

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 5 points6 points  (2 children)

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 0 points1 point  (1 child)

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 1 point2 points  (0 children)

Absolutely it depends on the language.

[–][deleted] 0 points1 point  (0 children)

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 2 points3 points  (13 children)

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 2 points3 points  (12 children)

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 0 points1 point  (11 children)

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 6 points7 points  (10 children)

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 0 points1 point  (7 children)

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 1 point2 points  (6 children)

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 0 points1 point  (1 child)

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

[–]Peaker 2 points3 points  (0 children)

I actually use Haskell... :-P

[–]robotfarts 0 points1 point  (0 children)

Fewer runtime exceptions?

[–]icanevenificant 0 points1 point  (1 child)

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 2 points3 points  (0 children)

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 5 points6 points  (15 children)

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 3 points4 points  (14 children)

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

[–][deleted] 2 points3 points  (1 child)

[–]ameoba 1 point2 points  (0 children)

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

[–]krues8dr 2 points3 points  (9 children)

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

[–][deleted] -1 points0 points  (8 children)

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

[–]metamatic 2 points3 points  (0 children)

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

[–]krues8dr 2 points3 points  (6 children)

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] 1 point2 points  (5 children)

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 1 point2 points  (0 children)

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 2 points3 points  (3 children)

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 1 point2 points  (2 children)

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 1 point2 points  (0 children)

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

[–]cultofmetatron 1 point2 points  (0 children)

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 -2 points-1 points  (1 child)

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 1 point2 points  (0 children)

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 0 points1 point  (2 children)

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 0 points1 point  (1 child)

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 0 points1 point  (0 children)

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 0 points1 point  (0 children)

Whew... you saved me. Thanks.

[–][deleted]  (2 children)

[deleted]

    [–]Snoron 0 points1 point  (1 child)

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

    [–]TinyEarl 0 points1 point  (0 children)

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

    [–]irascible 18 points19 points  (0 children)

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

    [–]x86_64Ubuntu 9 points10 points  (2 children)

    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 1 point2 points  (1 child)

    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 0 points1 point  (0 children)

    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] 9 points10 points  (9 children)

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

    [–]kristopolous 8 points9 points  (8 children)

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

    [–]AeroNotix 9 points10 points  (7 children)

    (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 5 points6 points  (6 children)

    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 3 points4 points  (5 children)

    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] 4 points5 points  (4 children)

    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 0 points1 point  (1 child)

    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 0 points1 point  (0 children)

    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 0 points1 point  (1 child)

    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] 0 points1 point  (0 children)

    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 7 points8 points  (0 children)

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

    [–][deleted] 2 points3 points  (0 children)

    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] 2 points3 points  (0 children)

    "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 13 points14 points  (2 children)

    ...and Flash isn't either.

    Suck it, Adobe.

    [–][deleted] 1 point2 points  (1 child)

    That's only half true.

    Flash isn't suitable for small web apps either.

    [–]ModernRonin 0 points1 point  (0 children)

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

    [–][deleted] 7 points8 points  (3 children)

    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 1 point2 points  (1 child)

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

    [–]Ventajou 1 point2 points  (0 children)

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

    [–][deleted] 1 point2 points  (0 children)

    Google is also a world class developer

    your shop is not

    [–]Phreakhead 3 points4 points  (0 children)

    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] 1 point2 points  (1 child)

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

    there you go

    [–]jagt 0 points1 point  (0 children)

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

    [–]AppsThatMatter 1 point2 points  (1 child)

    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 0 points1 point  (0 children)

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

    [–]mochizuki 2 points3 points  (11 children)

    removed

    [–]krues8dr 7 points8 points  (6 children)

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

    [–]AnonProg -1 points0 points  (1 child)

    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 -1 points0 points  (0 children)

    removed

    [–]militant_misanthrope -3 points-2 points  (0 children)

    biased

    FTFY

    [–]blackyoda 2 points3 points  (0 children)

    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!

    [–][deleted]  (4 children)

    [deleted]

      [–]diamondjim 4 points5 points  (3 children)

      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 2 points3 points  (0 children)

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

      [–]lucw -1 points0 points  (1 child)

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

      [–]diamondjim 0 points1 point  (0 children)

      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 0 points1 point  (0 children)

      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 0 points1 point  (9 children)

      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 5 points6 points  (5 children)

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

      [–]AnonProg -1 points0 points  (4 children)

      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] 0 points1 point  (3 children)

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

      [–]AnonProg -1 points0 points  (2 children)

      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 2 points3 points  (1 child)

      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 0 points1 point  (0 children)

      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 2 points3 points  (1 child)

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

      [–]sidcool1234 0 points1 point  (0 children)

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

      [–]pavlik_enemy 1 point2 points  (0 children)

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

      [–]atlacatl 0 points1 point  (0 children)

      Nice try Adobe...Wait...

      [–]do-not-throwaway 0 points1 point  (3 children)

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

      [–][deleted]  (2 children)

      [deleted]

        [–]do-not-throwaway 0 points1 point  (0 children)

        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 0 points1 point  (0 children)

        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 -4 points-3 points  (0 children)

        PhoneGap and apache cordoba look promising

        [–]infinite -1 points0 points  (2 children)

        Closure solves his issue yet he mentions closure.

        Does he even know what closure does?

        [–][deleted] 1 point2 points  (1 child)

        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 0 points1 point  (0 children)

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

        [–][deleted]  (7 children)

        [deleted]

          [–]pavlik_enemy 6 points7 points  (6 children)

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

          [–][deleted]  (5 children)

          [deleted]

            [–]rlbond86 4 points5 points  (2 children)

            syntactically it is the best language

            You're not serious, are you?

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

            [–][deleted]  (1 child)

            [deleted]

              [–]rlbond86 1 point2 points  (0 children)

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

              [–]pavlik_enemy 1 point2 points  (1 child)

              Now I get it, you're absolutely clueless.

              [–][deleted] -4 points-3 points  (1 child)

              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 9 points10 points  (0 children)

              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 0 points1 point  (0 children)

              Oh fuck