Earlier quoted context omitted.
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.
If you look at the HN thread where that paper was discussed, people on both sides were shooting holes in it. That's partly why I'm asking, is there anything solid on this out there at all? People are just repeating the same beliefs over and over. We've all heard them a zillion times and we all divide them into two categories: "shit I agree with" and "bullshit". What experiments could be done to test these beliefs?
JavaScript is not suitable for large web apps
191–200 of 218 posts
Re: JavaScript is not suitable for large web apps
#192Re: JavaScript is not suitable for large web apps
#193Klout.com -- same as above
More examples if you are interested:
https://github.com/joyent/node/wiki/Projects,-Applications,-...
Re: JavaScript is not suitable for large web apps
#194Earlier quoted context omitted.
Fair point -- it's unfair to stereotype Java developers. In my mind, I meant "most developers" and I happened to be talking about Java. But that distinction wasn't clear. It's obvious that (in the OP's case) using JavaScript didn't help the problem either -- but that was my point. Bad design is bad design. I am not making a strong claim that JS is better.
I like how you apologize for stereotyping Java developers by clarifying that you really wanted to stereotype ALL kinds of developers.
So the comment is less about the developer than it is about the mindset and the 'easiest path' that emerges from the language design.
Re: JavaScript is not suitable for large web apps
#195Earlier quoted context omitted.
And it's an Adobe blog. Their employees are quite likely to be biased in favour of their statically-typed variant, ActionScript 3 (well, it has a lot of changes, but it's essentially a JS variant at heart)
I find it very difficult to swallow anything written by the OP from the obstructed view at Adobe. After spending nearly every billable hour for more than three years buried in AS3's woeful inconsistencies, undocumented (or un-addressed) compiler issues, seemingly infinite application-crippling bugs, schizophrenic deprecation- any dev who had the misfortune of being relegated to work primarily in AS3 (and god help you…
Re: JavaScript is not suitable for large web apps
#196For a certain definition of "large" and for certain domains ( especially finance ) his argument is very, very valid. 200 average developers working with GWT->JS are anyday going to be more productive than coding native JS to get the same functionality. This isn't anti-JS...end of the day if you are on the web your code is JS. Thing is, how do you get there - do you hire 20 pricey smart JQuery guys, or 200 average Jav…
I would contest, GWT is used by some people who sort of already grokked some of the points made by this article, some years back. For example, coding in JS giving a feel of coding in assembly, particularly without the help of any good editors.
Another example to break the Enterprise only narrative: 'Google Flights' is done in GWT. And you and me can guess, there won't be 200 avg developers coding that product.
I came from an Enterprise background before our Internet Startup. Few of us coded up our app, in 3 months flat out using mainly Java and GWT.
One of the reasons we chose GWT was that, when we started out IE 6 still had a considerable share, and GWT generated JS which ran on it very well (although slowly).
Re: JavaScript is not suitable for large web apps
#197Earlier quoted context omitted.
>And I want a magic pony; This magic pony exists. That's what the author is trying to say. You can write magic pony code, and it can be run as JavaScript. Magic Pony -> JS Conversion! Also, the OP doesn't have an issue dynamic languages as much as weak typed languages. It just happens that JS is weak and dynamic, while AS is strong and static. Having switched between Java, ActionScript and JavaScript for the last fou…
> but it's not uncommon for a coworker to check in changes to a JavaScript class that completely breaks a part of the application that the dev wasn't thinking about You don't need to write unit tests to check the type of each value, you just need to have a decent set of integration tests to make sure you aren't breaking other parts of the app. If errors in the browser after a refresh don't help you catch it, failing…
Re: JavaScript is not suitable for large web apps
#198For a certain definition of "large" and for certain domains ( especially finance ) his argument is very, very valid. 200 average developers working with GWT->JS are anyday going to be more productive than coding native JS to get the same functionality. This isn't anti-JS...end of the day if you are on the web your code is JS. Thing is, how do you get there - do you hire 20 pricey smart JQuery guys, or 200 average Jav…
Why exactly would one run financial pricing functions inside the browser? Doesn't this stuff belong in the backend and far out of the users reach? Isn't that insecure or gives up secret stuff?
Re: JavaScript is not suitable for large web apps
#199Re: JavaScript is not suitable for large web apps
#200Earlier quoted context omitted.
Don't write programs in assembly. Use a high level language that translates down to assembly. Yknow, most every language ever. If you had read the article, you'd see that the author made this comparison.
Except Javascript isn't assembly, no matter how much the author would like to think so. It's a reasonably well featured, multi-paradigm high-level language.