We are currently porting a large web app from Actionscript to Javascript. The only library that we found that met our needs was Google Closure. It caters for modules of compressed code to be downloaded as required, much like the runtime shared libraries in Actionscript. Given the quirks of Javascript implementation, I don't see how we could have written our web application in any other language and successfully managed the exceptions.
JavaScript is not suitable for large web apps
91–100 of 218 posts
Re: JavaScript is not suitable for large web apps
#92Earlier 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.
So so true. If you are hiring "pricey smart [sic] jQuery guys" then you're probably doing it wrong. You need to be looking for solid software engineers that know javascript well. If the developers you are hiring think (jQuery === javascript) and can't explain the difference between classical and prototypal inheritance , then you're screwed before you even begin.
Good to know somebody understood what I was talking about.
This is why I don't ask for a "jQuery" guy, I ask for a frontend engineer who's a solid programmer and likes working on interesting products.
Re: JavaScript is not suitable for large web apps
#93For 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…
200 developers of any kind simultaneously working on the same code base sounds like a nightmare to me. I sincerely hope they have many separate projects that communicate via APIs or something.
Re: JavaScript is not suitable for large web apps
#94Earlier quoted context omitted.
3. (biggest problem IMO): debugging in CS sucks right now. It would be a no-problem with SourceMap though, so we have to endure it just a few more months.
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.
Re: JavaScript is not suitable for large web apps
#95This whole thing smells like link-bait to me. I mean, I'm guessing this is the first time a post from Adobe has been high up on Hacker News in what…. forever?
Re: JavaScript is not suitable for large web apps
#96Earlier quoted context omitted.
put a comment at the top of your function that says what to expect about the return value. Great, so now the documentation for the function will promise to return a motorcycle, but instead return either a bunny or a toaster. There are lies, damn lies, and boilerplate code comments.
>Great, so now the documentation for the function will promise to return a motorcycle, but instead return either a bunny or a toaster. Not if you follow the second part of my above advice. >There are lies, damn lies, and boilerplate code comments. Since when is a comment that explains what a function does "boilerplate"? I think you are confused.
I've often had to work with code where the comments indicated an entirely different intention than the implementation. As a result, I'm a little paranoid and skeptical, that's all.
I also don't like the idea of having to comment each and every single function. If you have to write a comment to explain what it does, maybe you haven't named it properly?
Re: JavaScript is not suitable for large web apps
#97The bunny or toaster example seems to me like someone still thinking in a statically-typed paradigm in a dynamically-typed language.
If you stop relying on instanceof and start using duck typing it would probably work out better.
Or maybe you should just never write a function called doThisOrDoThat. Seems like a code smell.
Re: JavaScript is not suitable for large web apps
#98This is utter tripe. It goes from saying don't use javascript to use a high level language that translates down to javascript. His main example of why javascript isn't suitable is an anecdote about a badly developed code base written in javascript. Seriously?
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.
Re: JavaScript is not suitable for large web apps
#99My answers is always, "More namespaces!"
Re: JavaScript is not suitable for large web apps
#100Is there any credible data on static vs. dynamic typing?
I'm not a specialist on this topic (i.e. I'm only a programmer, not a computer scientist), but I don't seem to remember any links posted to relevant such studies in any of the "static vs. dynamic typing" flame wars.
Also, a little bit OT, I've been a professional programmer for 7 years now (i.e. getting paid to write code) and to this day I'm not sure 100% what's the difference between "0", "NULL", "None" or an empty string. What type does "None" belong to? Can I compare it to the integer 0?