81–90 of 218 posts
This 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?
I thought ActionScript was a specialization of JavaScript, which is ECMAScript. Is this not right?
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.
If you want to dismiss GWT because it's java that's ok, but there are alot of good reasons (some non-technical) to choose java instead of CS or whatever. In fact, if you look at the history of GWT, they had all these "enterprise" patterns such as EventBus or Composite Views, or any other thing that the backbone/spine/etc camps are re-writing right now.
As I read more of these arguments, it makes me think a lot about whether I should switch to CoffeeScript before my web app gets any larger. Has anyone switched to CS or another language that compiles to JS, and regretted it?
I don't know what this article is about (looks like it's not worth reading), but I've switched to CS (IcedCoffeeScript, to be precise) for my Node.js app (a behemoth of an app!), and am much much happier. Sure, it has problems too, but they are more tolerable than having to do (if typeof(x)=='function' && x!=null) over and over again IMO, and the vast majority of them will be gone when we have SourceMaps (which shoul…
Earlier 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)
Not exactly - ActionScript3 is pretty much as close as you can get to what JavaScript2 would have been - Ecmascript 4.
Earlier quoted context omitted.
I haven't used coffee script myself, but I think you'd be hard pressed to find someone that wrote something in CoffeeScript and regretted it. The biggest arguments against using CoffeeScript (or any language that compiles to JavaScript) that I seem to keep hearing are: 1. JavaScript isn't a very readable language. (I think this is untrue. I've seen some incredibly well written / structured JS) 2. Not everyone knows C…
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.
Earlier quoted context omitted.
> You don't need a static type system to make sure that your functions are sane and consistent, and you don't have to be John Resig either. Right, and you can do structured programming in assembly. But when the language or tools don't help you do that, there are examples like the one the author points out where developers don't. Don't mistake utility (what can be done) for usability (what is easy to do). Usability al…
> First of all, put a comment at the top of your function that says what to expect about the return value. I want a language that gives me a nice pleasant syntax for doing that. And I want a magic pony; but as I said, declaring the return type doesn't tell users anywhere near all they need to know in many cases. Truly self documenting code doesn't exist, and will probably never exist. And since you can't usefully dis…
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 four years, I can assure you that bugs happen all the time in weakly typed languages that wouldn't compile in strongly typed languages. Sure, it doesn't make it past refreshing the browser, 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.
For instance, I've seen return objects switch from strings to ints because of how the strings were concatenated (return "Item " + x/returns string/; -> return x/returns int/;). Somewhere else in the function it returns early with "". Now you have other functions in other classes that check someFunction().length... error... sometimes...
The point is, you now have to write unit tests to check the TYPE of each value, and in many cases, it's not easy to tell. To check if an item is an array in JS, you have to do: Object.prototype.toString.call(obj) === '[object Array]'...
Since this checking needs to be done anyways, I'd rather it be done by the compiler rather than by a dev remembering to write a test for each possibility.
For 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…
>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.
For 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…
Shitty programmers should not work on large javascript projects.