Out of interest, is there anything you can share about the particulars of your application? We did the same Flash vs. HTML5 analysis in the context of Facebook games, but in our experiments it looked like Flash still won handily in terms of performance.
Not just that, even the Google Chrome support for SVG is terrible, it crashes very quickly if you draw a lot of nodes. I also found very simple bugs like moving a SVG objects leaves a trail behind. A good vectorial support is needed to replace flash.
It's a constant disappointment to me that Canvas is favoured over SVG. Just drawing simple shapes and moving them is so much more complicated with Canvas.
I have absolutely no idea how I would write Hello World in Flash. What compiler do I need. Do I need a compiler. Do I need to buy it? Is that all I need? Compared to: $ vim helo.html alert("hellooooo"); And if you can't write that from scratch, ViewSource on most web pages will give you a good clue. That looks like trump for mindshare, disputed performance questions aside.
A couple of months ago I was looking at Flex. It's a complete nightmare to try and play around with. I downloaded the SDK and tried to make some kind of hello world thing but just trying to make a module with a single function and then call that function was not straightforward at all. I didn't even want a module but I have to have one. Fine. How do I make one? The docs don't even cover this sort of thing. There is b…
With no Flash experience I had no trouble building a few Flex apps, and it was the same for a team member that quickly build a performant Flex app using their table widgets (which kills something like jQuery data tables plugin even on Chrome).
I did read O'Reilly's Flex book first though. I'm not sure people code Flex for fun, so good documentation costs money.
Was this your first time writing code for a GUI toolkit? Flex has an interesting model that merges XML definition of a UI with module-based code. I don't find it particular complex compared to say, writing an MFC application or C Win32 code to write a UI. I actually prefer it to the jungle of HTML, CSS, JS and dozens of JS libraries which aren't really geared for a professional type UI and fall down when you want to display 10,000 items in your table.
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 conj…
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.
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.
Well, the problem (one problem) is that Javascript has no typing system. This makes running valid javascript code super, super slow at times. You can't promise to a javascript interpreter that you will always and only use the variable i_am_only_ever_an_integer as an 8 bit integer. This makes lots of things super slow.
Of course you can promise types to the JS engine. Ints in particular are easy. With modern type-inferring JITs like SpiderMonkey, an expression like "var x = 3;" will infer x to int, and there will be no type checks or unboxing. In more complex cases, you can add "|0". For example: function f(x) { x = x|0; ... } This has the effect of forcing an int interpretation for the argument, and there will be no type checks or…
but you have to admit this isn't very obvious or well documented
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 conj…
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.
It was a product for IBM, a platform for NATO and the UN that consisted of several JavaScript platforms.
So... Adobe is arguing that nobody will ever figure out how to put a better compiler in front of JavaScript under any circumstances, so we have to pack it in now? I realize current JIT sucks in many ways, but seriously... claiming that "we can put this compiler in front of our stuff and since the other guys can never, never figure out how to compile first, we will win forever" isn't just stupid. It seems willfully st…
Not knowing ActionScript, the point seems to boil down to no more than "statically typed languages will always be faster than dynamic ones". This is true no matter what, "open source brain" can't fix that. However, one could make the same argument for C++: Why Python is not a worthy competitor. Sounds silly? It is, just like the original post.
> However, one could make the same argument for C++: Why Python is not a worthy competitor. Sounds silly? It is, just like the original post.
Not quite. Nobody claims that python will completely eliminate the need for C++, but there are people claiming that JS will replace flash.
A strawman argument by an Adobe shill. Javascript and V8 aren't competition because they're faster, they're worthy competition because they're fast enough for most applications.
Disappointingly trivial post: 1) I don't know a single person that would seriously argue that dynamically typed languages can perform better than their statically typed cousins. 2) As we all know, programming is the art of making tradeoff. One common pair is ease of writing vs. performance... 3) I think Adobe should be more worried about making a flash player/plugin I can't use to warm my hands by playing video after…
I wouldn't be so sure about 1). JIT compilers can in principle beat AOT by taking account of runtime profiling which AOT compilers have to make guesses at. I don't know how much (if any) of this V8 does, but it's a hell of a leap to go from "static system 'a' beats dynamic system 'b'" to "all static systems of type 'A' will inevitably beat dynamic systems of type 'B'".
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 conj…
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.
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.