I am trying to convert some pre-existing html/JavaScript files to Flex. I tried making some research to see if there was any compiler that compiles code from javascript to actionscript. As far as I can see, there are many ways to transform actionscript to javascript, but I couldn't find any for the other way around. Does anyone know if there is a way to do that, or should I just write my own tool?
I think you will find this will not work well, as AS3 is a strict-typed language, and Javascript is not. Even if such a compiler exists, your ActionScript will likely have problems from the fact that it would create a bunch of generic object.
In short: ActionScript to Javascript works, because Javascript is more permissive, but a lot of structure is lost. Inheritance, Type, etc.
But to go the other way, there is no way to add back in the structure required by ActionScript.
As one of the commenters mentioned, you may need to do this conversion by hand.
One other idea: the Flash player can talk to Javascript. There may be no need to convert the Javascript to ActionScript, instead just create a few functions to talk to the Flash SWF file through its ExternalInterface class. Just keep the Javascript in Javascript.
I highly suggest a complete rewrite, it won't take much time since both of them (JS & AS) are ECMA standard languages (correct me if I'm wrong)
But if you really need an automated way, Try:
Converting your JS to haxe
Compiling output Haxe to AS
It's the easiest solution on top of my mind.
You're better off writing your own tool. There are so many different ways to write javascript, and including the fact that it's untyped, it would be difficult to write a be-all end-all solution that converts everything. If it's a library, it might make more sense to convert opcodes rather than code-to-code, but so much of it depends on how the javascript was written.
It's going to be a pain, that's for sure.
js is untyped, actionscript is "typed". I guess everything could be an object and it would work well
js function scoping is handled differently.
anonymous function calling in actionscript is generally frowned upon, and is a detriment to performance
stuff like setTimeOut in actionscript is also frowned upon, enter_frame and timer are probably more useful
garbage collection in actionscript is handled a bit differently -- as is event dispatching
Related
I am on a new project and our job is to rewrite an e-commerce website that is having performance problems on mobile devices.
We are re-writing the javascript based on a more object-oriented/modular architecture which I think is great! However my team lead said that we should remove all the jQuery calls and replace with javascript like so domElem.querySelectorAll(query) , which has better performance. I understand jQuery does some kind of caching in the background which can create memory issues.
I am a little sceptical of this, firstly because it seems like a case of 'premature optimization', that is, we should find the bottle-necks first before we re-write anything. And secondly I haven't found anything on the internet that says that jQuery has significant performance problems.
The current website does have a lot of overlapping dom branch queries which I think creates a lot of redundancy. That is there is too much querying happening, and on our new architectual approach we are restricting our object/module to fewer dom queries and more targeted dom queries which is great. This does need to be re-written.
But whether or not we use domElem.querySelector(query) or $(domElem).find(query), I can't see there as being much of a difference. Is my thinking right?
Some tests are done here (check other revisions as well). Good detailed discussion is done here over pros and cons of using jquery over javascript.
Also want to point out that jquery doesn't do any caching of selectors.
The thing we often forget because of using Javascript frameworks all the time is that jQuery is not a framework.
Obviously, if you do the exact same one-operator action using the jQuery '$' object and using a direct DOM method like getElementById, the latter will be noticeably faster as jQuery itself is written in Javascript and does a lot of background stuff.
However, nothing (except code readability) prevents you, as a developer, from combining jQuery with plain Javascript: using plain Javascript wherever possible and only using jQuery functions that provide complex functionality and take some time to write and optimize from scratch. There are a lot of those in jQuery: providing browser-independent css, serializing object and doing lots of other cool stuff.
It depends on the application but usually performance troubles are related to badly-designed algorithms, not the use of jQuery.
In any case, if your application does a lot of DOM-manipulation, it may be worthwhile to re-write it using plain Javascript and test. Keep the library, just don't use it for simple operations you can easily write without it.
If your application is heavily-reliant on jQuery functions with complex functionality, removing it is out of the question.
I myself use this combined approach: everything simple written in Javascript with jQuery functions for stuff that is difficult to implement.
Also, a good place to dig around if the app has troubles with performance is the DOM-manipulation. Those operations are very heavy compared to almost everything else in Javascript. You may be able to cut down on time by rolling several operations into one, building finished objects with one constructor, instead of creating empty ones and assigning properties one-by-one, etc.
Sorry, if the answer is a bit vague but it's difficult to be precise in this case without seeing the code and running tests.
Let me quote Uncle Bob about this discussion "Architecture is about intent, we have made it about frameworks and details"
Premature optimizations needs to be considered carefully.
They often result architectural decisions that are not easily revertible.
They introduce code optimizations that are usually specific to the problems they solve, which makes the code less abstract thus hard to
maintain, and more complicated thus prone to more bugs.
They tend to be prejudice and not objective, sometimes without any real comparison to other alternatives.
The problems they are trying to solve tends to be overestimated, to the degree of non-existent.
I'm not a big expert on Web development but if possible, you should always push this kind of decisions to the end by separation of concerns, and good abstraction.
For example over the parts that generate the java-script code you can have an abstraction of JavaScriptWriter, and use different frameworks. This way you can use JQuery at the beginning, test the system and only then replace parts you know to be inefficient.
So basically I have a number of concerns holding me back from coffeescript:
I'm not really an expert in js yet, even though I'm using it for around 3 years now I still feel like I'm missing something important about it. Since it's mostly a supportive technology for me I never find time to go in depths of js ( which, I admit, might be a wrong attitude ).
My js knowledge will get even worse if I'll start Using coffeescript
I'm not sure if I can actually trust coffescript, meaning the js code it compiles to
At times I don't understand the js code coffeescript compiles to and even worse - why it compiles like that.
I'd like to know your thoughts on the above points. The crucial one is:
How using coffeescript affected your knowledge of js? And how important you think it is to fully understand js before switching to coffeescript?
You should understand what problems Coffeescript is supposed to solve.
And for that, you should have a basic knowledge of javascripts' "bad parts".
I suggest reading Douglas Crawford about that (there's a book, but also a lot of resorces on internet. Just google "javascript bad parts").
Basically, the idea is that "Underneath all those awkward braces and semicolons, JavaScript has always had a gorgeous object model at its heart. CoffeeScript is an attempt to expose the good parts of JavaScript in a simple way." (taken from coffeescript's site).
There's a tool to assist programmers to avoid javascript pitfalls called jslint.
This tool analizes your code and gives warnings about common mistakes, such as global variables, semicolon insertions, namespace pollution, etc...
Coffeescript translates to javascript. But the javascript it generates is a cannocical subset, highly compliant with jslint.
What's more, it generates javascript code valid on all browsers.
So it is not just a nice syntactic sugar layer, it really helps generate solid code.
I'd like to address your concerns.
1) If you've been using JS for three years, you probably have a pretty solid understanding of JS. If you haven't gained a solid understanding yet, it may be time to supplement your knowledge with one of the good JS books.
2) Coffee-script probably wont make your knowledge of JS worse. The way you design Coffee-script applications is the same way that you would design a JS application (for the most part), so the design skills you gain will transfer over. Program design, in my opinion, is the most important aspect of programming.
3) Why don't you trust the JS? Why do you trust any of the other compilers/interpreters/other tools you use? I doubt Coffee-script is bug free, but many people use it for many purposes. This means that a large set of behavior has been tested, often in production, so your use case has probably already been tried and tested.
4) Of course the JS generated by Coffee-script will look foreign to you, since the rules for generating it don't have human readability as a priority. Reading it, however, will increase your knowledge of JS as you see how peculiarly written programs run. This brings us back to point 1.
I think that the crucial thing to remember here is that Coffeescript IS javascript. Every Coffeescript statement or magic operator has a distinct concrete representation in Javascript. For instance (x) -> x * x in Coffeescript will translate directly to function (x) { return x * x; }.
You can't really write Coffeescript without being aware of the Javascript it will generate. For one thing, the generated Javascript is what you will have to debug. If anything, I believe that writing Coffeescript could possibly improve your understanding of Javascript, because it forces you to make decisions that are unique to Javascript. For instance, when in Coffeescript, you decide to use => instead of -> in reality you are making a decision about whether or not you want to bind this - a very real Javascript problem.
When (or if) to start using Coffeescript? I think the answer to this is more or less up to you. Try it out, and if you feel that it is easier to get your tasks done using Coffeescript, then stick to it. If you find it difficult to write the code in a different language from the one that runs (and thus the one you have to debug), then go back to Javascript.
So here's what I think about the topic:
JS is not a supportive technology (support for what?). It is a language mostly used on front-end and there is a new trend of using it on back-end. Since browser do not support CoffeeScript natively than unless you use it as a back-end then I don't think there is a point in using CoffeeScript. Although learning new language is always a good idea.
Not at all. Actually using CoffeeScript is like using different language. Learning one cannot make you dumber in the other. Unless you stop learning the other one.
There is no evidence that CoffeeScript compiles to buggy or slow code. Actually I am using CoffeeScript for some time and I didn't observe any performance hit.
Actually you don't need to understand why it compiles like this. If you are using CoffeeScript on back-end then you don't even have to look at the code it compiles into (you only need the source code). As for using it to make browser scripts then yes - it may be a bit difficult to work with it (debug). That's why I always advice to write normal JavaScript for browsers and use CoffeeScript on back-end.
Now as for the last question: I don't think that CoffeeScript affected my JS knowledge at all. I treat them as separate languages. Also you don't need to know JS in order to switch to CoffeeScript (although you should) unless you want to use CoffeeScript on front-end.
Also mastering JavaScript is always a good idea, no matter what. :)
Is it just me or any JavaScript DOM manipulation or WEB UI Framework code is really hard to grasp because of long files, lack of proper indentation and scarcity of comments?
I have read couple good book on JavaScript and like the language, but when trying to understand the inner workings of all the popular frameworks I am having hard time to force myself to go beyond first hundred lines of a huge file.
This is a real question, not a statement. I am just trying to understand if I just suck or somebody else sharing my impressions.
Oh boy. First, stop trying to reverse-engineer minified and obfuscated javaScript. Second, it's open-source and documented.
Who said he is reading minified code?
This question might be closed, but yes, jQuery has some rather unreadable source and bad organization. Organization in that John Resig thought it was a good idea to throw everything onto a single constructor and its prototype.
I guess if you want a DOM library that is well commented, try looking at Prototype. It's actually very overcommented in my opinion, but if you want it as a reference for various DOM quirks and mechanics, it might be a good source.
The minified version is indeed not human-friendly, but it's smaller and faster. You're looking for the development version.
Whilst I can understand your frustration, jQuery (and other APIs, C++'s STL springs to mind) are not meant to be read by the average engineer. They are optimised for their purpose and excel at doing so, and that's why everybody uses them. Tried and tested.
Genarally jQuery uses a lot of closures and the notation of the framework as well as the plugins define a lot of anonymus functions on the go.
So it's not easy "following" the way of the data through the code. At least that is my limited understanding. So if You just suck, You're definetely not the only one.
as a skilled AS3 developer I wonder if there is something like AS3 to JS migration guide. After all both languages have a lot in common.
I have in mind something like the old AS2 to AS3 migration guide - a list where I could simply look up the AS3 functionality and the JS counterpart, or vice versa.
I am not saying you can easily convert all your code like that but it would tell me where to start.
PS: I think it is a great idea and if such guide doesn't exist someone should write one :).
I've read that with Haxe you can compile somewhat transparently to JS code. This requires Haxe code, I think, which is not ActionScript 3.0 but is close and should be easy to pick up if you're already comfortable with AS.
I haven't tried this myself but it's probably worth to check out. Here's a blog post that might give you some ideas: http://gamehaxe.com/2010/05/25/javascript-ready-or-not/
You're going to have a difficult time of this considering a lot of the flash.* packages don't have any native JavaScript counterparts. Maybe a robust JavaScript library can ease the transition, but there will be a lot not migrate-able.
However, many of the Top-level datatypes do have a JavaScript counterpart (i.e; Date, Array, String, Object, null, Number/Integer)
It's often claimed that learning a lower-level language is a good foundation for any new developer. What about an experienced developer (say a C++ or Java guy) learning Javascript? in the same way should he learn using the raw language so he understands what's going on, and learn JQuery later, or use JQuery from the start as 'part of' Javascript?
I think it's worth spending a bit of time working on JavaScript without jQuery so you can appreciate just what jQuery brings you. But most of what you'll be learning in JavaScript (getElementById etc.) will be replaced by better jQuery functions, so don't spend too long in pure JavaScript.
I guess the important thing to realise is that a lot of what you do in JavaScript is actually just working with the DOM API. The JavaScript language is great, but the DOM API is RUBBISH. jQuery doesn't really abstract the language, just the API. So the distinction isn't between using JavaScript or using jQuery, it's more about using the DOM API vs using jQuery.
It's always good to understand the basics of 'raw' JavaScript. I would recommend learning basic JacvaScript first, then jQuery. It'll make jQuery easier once you know the basics of the language, and there are still quite a few scenarios where it's preferable to do parts of a code in regular JavaScript than the jQuery way.
You could still try to learn about both in parallel, but either way it is still important to understand JavaScript to really understand appreciate jQuery.
I am pretty new to JavaScript myself, and I had a few months to learn raw JavaScript before finding out about jQuery. I agree with GSto that learning raw is good, but don't spend to much time in it before looking at a framework.
Apart from that, I strongly recommend anyone building in Javascript to pick up a copy of Douglas Crockford's JavaScript: The Good Parts. Read it back to back and then keep it close to your computer!
JavaScript differs from C-like languages quite dramatically at some points...
EDIT: Crockford held a great talk at Øredev 2009. They have the whole talk in video on their site.
Learn Javascript first and about DOM, object literals, closures and currying. When you master these things you are ready to use a library.
If you want to be a good web-developer who knows javascript, then do not touch jquery for at least year. It will corrupt you. Seriously, I've seen too many people who claim that they know javascript but are unable to iterate through an array without using jquery.
I think you should learn raw language before jquery or another framework. If you do, cou can learn jQuery basis wery quickly.
I learned JavaScript before I did anything with jQuery and I would recommend the same to any one thinking to learn JavaScript, as this would allow you to move to another library or use raw JavaScript if you found that jQuery wasn't really suited to what you need or if you simply didn't like jQuery.
There may be some cases in which using raw JavaScript is better suited to what you want to do.
It's very important to learn the language itself, and somewhat important to become familiar with the issues faced by things like jQuery in making the programming environment more uniform across different browsers. However, except as exercises for people who have the time, attempting to re-implement the facilities that modern frameworks provide is a pretty bad idea.
A benefit of learning a modern framework is that they generally encourage the exploitation of the native power of Javascript, and avoid trying to make the language look and act like something it isn't. You have to develop a good feeling for what anonymous functions are and how they work, for example, in order to really use Prototype or jQuery or just about any other framework effectively.
Finally, reading the source code of a good modern framework is wonderfully enlightening.
Think of JQuery as being an abstraction that just happens to be built using Javascript.
Most things that you need to do can be done elegantly with JQuery.
To use JQuery effectively it is more important to understand the DOM, Events and CSS.
It helps me to think of JQuery and Javascript as being different paradigms even though we all know that JQuery is written in JS.
I came to Javascript from a C/C++ background and it took me a while to really get to grips with the object model first-class functions, inner functions and closures and prototypes.
JQuery is much clearer, easier to follow, and more powerful once you understand what it is that you are manipulation (i.e. DOM, Events, CSS).
So I'd learn JQuery first and fill in the Javascript gaps as they appear.
Don't forget that document.getElementById is still the fastest way of getting elements. So if you do simple stuff and that's sufficient so why use a library?
Read what Joel Spolsky says about abstractions. What happens when your abstraction layer leaks? Do you know why the problem happened, or what you can do to fix it?
I would start learning the javascript syntax and usage first, but don't focus too much on the different functions, as a lot of them will have better jQuery alternatives.
The answer - both.
If you are working on something professionally and have a deadline... JQuery. Then go home and learn the internals. JQuery is very powerful and there is no need to reinvent the wheel. Sometimes the best code you write... is no code at all.
Now that being said, its always a good idea to understand your code and the "black majic" that happens under the hood. This helps to decide which JQuery method or selector to use for the best job... measure the pros vs cons.
You should do both at the same time. Learn javascript loops, types, prototypes and just forget the DOM methods because jQuery is more elegant for that.
You should learn basic js first, variables, loops, functions, closures, inheritance, and js design patterns. If you're already a programmer, you can skip a lot of stuff. jQuery is not a language. Once you know that, then jquery is a tool, that mostly helps you abstract differences between browsers (and provides another dialect of js). I don't use jquery, I use ext-js (another tool, another dialect), so I would caution strongly against learning jquery as if it were a language.
If you're going to work with the DOM (as admittedly most do, since most Javascript is used for client-side web development), then JQuery will be helpful.
However, don't confuse it with the language Javascript - JQuery is just another library for DOM access, albeit a very ubiquitous and imho great one.
I'd say it's somewhat analogous to asking if it's wrong to use Win32 or some other platform API while learning C++.
jQuery is just one of several libraries out there. What are you going to do if you don't use jQuery or the company you work for doesn't? Using this library does carry some weight, too. Are you going to always use it even if you only needed one minor feature?