Live data from Hacker News

JavaScript is not suitable for large web apps

blogs.adobe.com

121–130 of 218 posts

Re: JavaScript is not suitable for large web apps

#121
post #82

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.

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 a…

No, simply no. GWT is everything we should be running screaming from, and yes because its Java and yes because it lets programmers be lazy and not go out of their comfort zone and fucking learning JavaScript

Re: JavaScript is not suitable for large web apps

#122

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

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

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.

Re: JavaScript is not suitable for large web apps

#123

Earlier quoted context omitted.

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

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?

Apologies.

I'm not happy that somebody who very evidently doesn't have a clue what they're talking about is the top comment.

When people stop upvoting complete and utter tripe (which is nutritious btw), my response stops being necessary.

I'd react the same way to any sort of ignorant pontification on clearly foreign (to them) material.

Raise a fool on a litter and I'll tackle the people carrying the litter.

I'm quite open to being proven wrong, but I don't expect to be.

Re: JavaScript is not suitable for large web apps

#124
post #114
post #84

Earlier quoted context omitted.

...yeah, what was to be a beautiful language. So unfortunate that that proposal was squashed.

No, thank Thor that mutant was aborted. ECMAScript 4 got everything wrong, just like AS3 did.

An optionally dynamic, yet also statically typed language? Umm... no. It's hard to even imagine arguing about this.

Re: JavaScript is not suitable for large web apps

#125

Earlier quoted context omitted.

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?

Apologies. I'm not happy that somebody who very evidently doesn't have a clue what they're talking about is the top comment. When people stop upvoting complete and utter tripe (which is nutritious btw), my response stops being necessary. I'd react the same way to any sort of ignorant pontification on clearly foreign (to them) material. Raise a fool on a litter and I'll tackle the people carrying the litter. I'm quite…

Ah. The "commenting to point out insanity upvotes by default" paradox. Quite ironic. Quite.

Re: JavaScript is not suitable for large web apps

#126

"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…

> Also, you can't ignore that this is hosted by Adobe... This may be true, but it's an ad hominem attack.

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

Re: JavaScript is not suitable for large web apps

#127
post #86

Earlier quoted context omitted.

I hear this a lot, but seriously, have you ever had any real problems with debugging CS? The output is clear enough for anyone to know exactly where to go for the error.

It's a pain, still. I don't generate js files. When something like that happens, I have to go back to command-line, type 'coffee ...coffee', open generated js file and see where the problem was.

That's your problem right there ;) When you're using CoffeeScript, you're absolutely supposed to generate all of your JS files. -- For the same reason why you don't run all of your JavaScript via eval() while you're developing.

Try using `coffee --watch` instead.

Re: JavaScript is not suitable for large web apps

#128
post #82

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.

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 a…

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.

Re: JavaScript is not suitable for large web apps

#129
post #119
post #42

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

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.

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.

Re: JavaScript is not suitable for large web apps

#130

Earlier quoted context omitted.

You have to be willing to fire them if it turns out they're they suck.

Average != suck. Anyone who thinks they are going to do nothing but hire above-average programmers at any scale is downright naive. Design your system around an "average" employee, and you'll be far happier.

You can do a hell of a lot with a 10-15 person team. Unless you're consulting your company can grow much faster than your team.
Post reply on HN