[tommorris]

The Web: You are indeed brave, Sir Knight, but the fight is mine.

Adobe: Oh, had enough, eh?

The Web: Look, you stupid bastard. You've got no arms left.

Adobe: Yes, I have.

The Web: Look!

Adobe: Just a flesh wound.

The Web: What are you going to do, bleed on me?

Adobe: Oh. Oh, I see. Running away, eh? You yellow bastards! Come back here and take what's coming to you. I'll bite your legs off!

[dmethvin]

Upvoted not for the humor, but for the aptness of the analogy. JavaScript is universal and free. If Adobe can create a sort-of-compatible environment that allows certain classes of apps like games to run better, great for them. Perhaps their marketing can be, "If JavaScript isn't fast enough, we've got you covered."

At least it's not Dart!

[kls]

It really is appropriate. I love how we keep getting told by guys that are not writing large apps in dynamic languages, that we can't write large apps in dynamic languages meanwhile guys like me are out there building some of the largest code bases in the world with JavaScript. And when it works and we release something revolutionary to the world, they tell us after the fact that it is not going to work. AMD and module dependencies have done far more for advancing building large JavaScript applications than most of these other cures.

[pnathan]

"building some of the largest code bases in the world with JavaScript" You have over 100 MLoc?

[kls]

You are focusing on the wrong part of the conjecture, the point is, large code bases are being written in JavaScript everyday. Yet, People with the position like the author continue to argue that it can't happen, despite the evidence being readily available.

I don't want to dodge your question thought, the answer is yes I have worked on some JavaScript code bases that are several MLoc. Which I would consider for conjecture sake to rank in the largest. what constitutes that bar is up for debate whether they are the top 50 or 500th or 5000th largest, but I do feel that they qualify as large code bases. Which sufficed for the point I was making.

[pnathan]

Project complexity tends to scale exponentially-ish, so I was wondering what you considered "Largest codebases"... according to Googling, Windows is 50M, Android 12M. So a couple million LoC is pretty awesome.

Static typing evangelists seem to have a blind spot: they persistently tend to assert that you can't write good and large dynamic codebases.

[kls]

Windows is 50M, Android 12M

IIRC in webOS a substantial portion of the user-land utilizes JavaScript, as a whole one could surmise that they constitute modular parts of an overall system. I do not know what the TLoc on webOS is, but I would assume that it would have to be in the ball park of large. I think it is as valid as the total line count of windows or android it is also the problem with looking at these things from just a TLoc perspective.

Static typing evangelists seem to have a blind spot: they persistently tend to assert that you can't write good and large dynamic codebases.

Thanks you probably summed up my post better than I did.

[jiggy2011]

You can , if you have good communication or a small team.

I have a PHP Project that is about ~200Kloc , ok that's not enormous (and it's about 60% boilerplate) and I can maintain it happily enough but I wouldn't want to let a large team loose on that.

[roel_v]

For your argument to be believable, you shouldn't make unsubstantiated and prima facie bogus claims. Your post would've have the same message without that claim, but by putting it in it sticks out like a sore thumb and makes the rest of your argument moot for debating purposes.

[kls]

That was my point, you don't have to believe me, there are a lot of public examples that are not associated with me. In fact I did not want to get into my personal accomplishments, for that very reason. For a post, it can be stated that there are large JavaScript code bases in the wild without justifying such conjecture for the sake of brevity. That is why I said it was conjecture it is an assumption of truth without providing proof, if people are interested they can do the research to make it fact, in their mind, because what they consider to be "large" will be a personal variable as well. I don't feel I made a bogus claim, I just wrote a post and not a dissertation on the subject. In doing so, I drew upon my own personal experiences to formulate my post. If people want to ignore it as bogus they can, or they can simply read my post for what it is and decide to look into it. I don't think I asked anyone to take my post as proof, rather stated my position on the subject at hand. If it appears to not be the case, then I apologize it was not my intention.

[WayneDB]

Which javascript project did you work on that had several million lines of code?

If you can't tell us that, at least tell us what _kind_ of project it was please.

[maratd]

I don't know what project the OP was working on, but right now I'm working on a crm/accounting/scheduling product with several hundred thousand lines of javascript code. Due to the modular nature of the code base, I don't see any reason why I can't break the million mark and keep going.

Although I probably won't. Because I don't have to.

Because unlike with a traditional code base, much of the functionality is provided by the browser (CSS, HTML, SVG, Canvas, Image Support, Geolocation, Storage, you get my point) and not by external libraries which add to the lines of code.

[kls]

It was a product for IBM, a platform for NATO and the UN that consisted of several JavaScript platforms.

[azylman]

I think I would have heard about it if you'd released something revolutionary using several million lines of JavaScript...

[kls]

Actually alot of your really large codebases are internal facing projects. Like airline management systems or hotel inventory and allotment systems. They are generally found where there are deep technical problems and usually require complex workflows to manage. Complex workflows are where you will see a lot of JavaScript utilized. In the consumer web space, generally we try to simply interfaces and reduce the complex nature of tasks. In the corporate world, generally the user will be skilled in the complexities of a UI designed for power users. It is the reason that in some organizations the console or green screen apps still exist. For certain tasks once trained, keyboard based navigation console systems are optimal and save organizations 100's of millions of dollars.

[huxley]

If we follow the analogy: after failing repeatedly to find the Holy Grail, Adobe will get arrested by police just as they are about to attack Castle Aaaaarrrrrrggghhh.