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. :)
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.
I know I'm coming at this the wrong way. You're supposed to learn Javascript first, then start looking at Coffeescript when you get tired of braces and variable declarations. Me however, I'm a somewhat experienced Ruby and Python programmer but with zero Javascript fluency who looks to get into web scripting (mainly through Rails).
I'm convinced that Coffeescript is the way to go for me, but I'm hard pressed to find a tutorial that does not assume significant Javascript familiarity. Most of the tutorials I have seen explain Coffeescript's peculiarities in detail only to gloss over such minor topics as how to actually write web applications.
So, do you know of any Coffeescript tutorials for people who don't know JS to begin with?
You probably don't want to hear this, but I'm going to say it anyway: you should still learn JavaScript first.
JavaScript is a little unique from other languages, in that it has a monopoly over browser scripting. There is currently no other language that can be used in a browser (unless it uses a plugin, or the interpreter is in JavaScript!). As such, for any project that needs to do any amount of client-side scripting, JavaScript knowledge is a must.
You're probably thinking "Hey, I know Python and Ruby, and I never had to learn C or assembly!", which is of course true. But, those language never had a monopoly over their domain. Python can be used for the same things as C, in many cases. The platform doesn't care what language you use, as long as it supports it.
And the browser platform only support JavaScript.
CoffeScript is an abstraction of JavaScript. Although CoffeeScript is compiled into JavaScript, when you're trying to figure out that obscure JavaScript error, or debug a generated function, or are wondering why there are two levels of unnamed function nesting, you're going to want to know what's really going on.
Now, I'm not saying that you have to become a JavaScript Ninja (although I'd recommend it), but what I am saying is that you should come to grips with the actual web language first.
Learn JavaScript, learn its concepts (it's a very fascinating language, in my opinion, once you get past some of the deficiencies), and then use CoffeeScript to abstract away the technicalities.
Since you did ask for a tutorial, though, here's some: First, the Mozilla guide to JavaScript is quite nice. If you want some more advanced topics, there's also an interactive tutorial made by John Resig. And finally, here's a bunch of CoffeeScript tutorials that you probably already know about.
I suggest the free online Smooth Coffeescript book (based on Eloquent Javascript).
No previous programming knowledge is required. CoffeeScript lets you
write web oriented applications simply and elegantly. It is closely
related to JavaScript but without its quirky corners.
Smooth CoffeeScript is a book about CoffeeScript and programming.
Start with programming fundamentals, learn about functional
programming with Underscore and problem solving, study object
orientation and modularity. It covers client/server web apps with
Canvas and WebSockets.
I had a background in Python, ActionScript and Java. I started directly learning CoffeeScript with no intention of learning JavaScript. I learned a bunch of JavaScript along the way but I think it's perfectly OK to set out to learn CoffeeScript directly.
I was first attracted to Smooth CoffeeScript because it claimed to be targeted at folks trying to learn CoffeeScript directly. However, the style of writing was not to my liking. YMMV.
Besides, with my Python background, I found that I didn't need much help with the syntax. I got all of the syntax help I needed directly from he CoffeeScript web page. I mostly needed help with the platform (cake, development environments, testing, etc.) which is covered quite well on the CoffeeScript web page, and what else I needed I got from a couple of other books. My favorite teaching book is The Little Book on CoffeeScript (read in an hour) and my favorite reference is Trevor Burnham's Pragmatic Bookshelf book on CoffeeScript which taught me jQuery from the CoffeeScript perspective.
Another thing that helped me ramp up quickly was to fork/upgrade a few of my own tools in CoffeeScript. I forked the CoffeeDoc repository on github to create my own version and I eventually re-wrote it to create CoffeeDocTest which is like Python's DocTest except for CoffeeScript. My upgrades to the Coda syntax mode for CoffeeScript were accepted back into the master branch via github's pull-request mechanism... after a code review and some cleanup. Looking at someone else's code really helps you learn the idioms. Getting a code review from someone in the know helps even more.
Your question doesn't make a lot of sense to me because CoffeeScript is JavaScript. To know one is to know the other. It may sound counter-intuitive for me to suggest that the best way to learn CoffeeScript is by cracking open a JavaScript book but the languages are one and the same.
I know they look different, but the differences end at the syntactical layer[1]. Add some semicolons, curly braces and parens to CoffeeScript and you're more or less there. So go and learn JavaScript, and you'll find you're learning CoffeeScript too.
You could also learn CoffeeScript and incidentally pick up JavaScript. This may be a little bit more difficult though, since until source mapping is implemented, debugging can only be done in JavaScript (and you'll be debugging a lot, I assure you ;-)).
[1]: Apart from maybe class definitions which are slightly more complicated.
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.
Are there any real-world prototype-based programming languages with a whole development cycle?
"A whole development cycle" like Ruby and Python: web frameworks, scripting/interacting with the system, tools for debugging, profiling, etc.
Thank you
A brief note on PBPLs: (let's call these languages PBPL : prototype-based programming language)
There are some PBPLs out there. Some are being widely used like JavaScript (which Node.js may bring it into the field - or may not!). One other language is ActionScript which is also a PBPL but tightly bound to Flash VM (is it correct to say so?).
From less known ones I can speak of Lua which has a strong reputation in game development (mostly spread by WOW) but never took off as a full language. Lua has a table concept which can provide you some sort of prototype based programming facility.
There is also JScript (Windows scripting tool) which is already pointless by the newcomer PowerShell (I have used JScript to manipulate IIS but I never understood what is JScript!).
Others can be named like io (indeed very very neat, you will fall in love with it; absolutely impossible to use) and REBOL (What is this all about? A proprietary scripting tool? You must be kidding!) and newLISP (Which is actually a full language, but no one ever heard about it).
For sure there are much more to list here but either I do not remember or I did not understood them as a real world thing, like Self).
I would argue that JavaScript is a real world language. The main difference is that it tends to be embedded into lots of different environments rather than being a stand alone development environment.
Aside from the obvious use in a browser, JavaScript can be used on the server side using CouchDB (which is becoming very popular as a database both for websites and the desktop) or Node.js - there are lots of others as well. It can also be used to create desktop applications via seed or gjs.
As for debugging tools, these are included in most web browsers and there are extensions such as firebug.
The approach is different in JavaScript - instead of having a core language and using libraries to access different programming environments, it is embedded directly into these environments.
It doesn't look like it. Checking out the Wikipedia list, I can't say any of them are particularly popular for systems-type or standalone programming. And I have a few theories why:
Inertia - people are more familiar with procedural/procedure-class based languages. In the same way procedural languages are more popular than functional, I think we find it easier to mentally keep track of the objects we've specified beforehand
Less error-prone - When I use a class, I can't use things not specified in that class. It's a bit less flexible, but when working on a large project I'm very, very grateful to be able to look at the spec for an object (even if I've written that object) and know how the object will behave. That is, I know the compiler will probably throw an error if I try to do something stupid like use the wrong variable name.
You mention "scripting/interacting with the system". As far as that goes, classes aren't even particularly popular. One-off scripts may use a few functions, or even just straight procedural code. I know if I write a simple little Python script, I'll have a few simple functions and I'll use builtin objects. It's OO, but I'm not writing anything.
No/not many suitable languages. This is I think the biggest one. Lua's great for embedded scripting, but I don't think it can replace Python/Perl scripts in my toolkit.
Prejudice - the sordid past of Javascript has not been good for prototype-based languages, I don't think. Javascript's actually a pretty nice language, once you see code written by somebody that understands it, but there's still a lot of derision - it's seen like a kiddie language. If you say "I'm a Javascript programmer", it's hard to be taken seriously.
EDIT It's either a sign or a symptom, but most PT languages are embedded or application-specific scripting languages (Lua in games or for UIs, Javascript in webpages or for the UI like in Firefox, etc). I'm not sure why this is, but they are either more suited to application customizing or otherwise-embeddedness, or that's what the common implementations are designed for. Python can be easily embedded into a program, and it sometimes is, but it's more common standalone.
This may be more philosophical than you're looking for, and I'm by no means a prototype-based expert, but I've done a fair bit of Javascript and fiddled with Lua. I stand by my answer, though, based on at least personal experience. YMMV.
I see no reason why a PT language as useful as Python couldn't be written, but it doesn't seem like anyone's done it.
I did not found one and the only candidate (JavaScript) is still spending very first steps (like Node.js).
Still one other valid candidate would be JavaScript! There is a .NET based implementation named IronJS which is implemented in F# and is going pretty well. This way one can have whole .NET development cycle at his toolbox. It is based on DLR and can be used in both .NET and Mono!
I code CSS/XHTML like it should be my mother language, and I do write valid, semantic code following guidelines of accessibility and such.
But I want to learn Unobtrusive JavaScripting, but with a total non-programmer brain I need some motivation / tips / etc., like what's the best way to learn it, and how long does it take/did it take you before you could feel the power of knowledge? :)
PS: I do have an understanding on how JavaScript works and changes the DOM etc.. I think it's more about learning the syntax by head instead of having to look it up.
See also:
Suggestions for someone starting javascript programming.
Just use it. Really, the more time you spend reading and writing the language, the more natural it becomes. Use Firebug or an equivalent console to test short ideas; take an existing web page and wire up events interactively from the command line, get used to the idea of writing behavioral code as a separate process from writing markup.
If you want a good book, i can recommend the excellent jQuery in Action - yes, it's targeted at jQuery users, but the concepts apply regardless of your choice in libraries.
Motivation, sorry can't help there.
Syntax is learned by rote. The rules are simple, and reasonably consistent, so in truth syntax isn't that hard.
What you conflate with syntax are likely the other aspects like what properties are available on what objects, what functions to call, what does your framework provide. That, again, is basically rote memorization.
Many frameworks add a little bit of syntax through clever use of the JavaScript syntax, and you'll need to learn those as well.
But when it all comes down to it, the only way to learn this stuff is to use it.
You can't read about it, you have to do it.
Find an issue that you want to work on, a feature for your site or whatever, and attack that.
If you find a tutorial or whatever on line that does what you want, TYPE IN THE CODE, don't cut and paste it. As you type it in, question every symbol or character, try to understand why you're typing what you are typing.
Make an effort to change things, even if it's just variable names, because then you get a better idea of what things are being used for, and how they're referenced. It also lets you focus on a small part of the larger program.
If you're changing the "window1" variable to "myWindow", then at least you can look at the code as "blah blah blah window1 blah blah window1" without having to understand all of it.
Start small, don't worry about "doing it right", etc. so much as just being successful. If the way it's done doesn't bother you, then you're good. If you look at it and go "That's not quite right" because you learned something later after you started, then go back and clean it up.
At this stage, function is greater than form. Much of the form simply comes from experience.
Depends on what you want to do. Are you a successful web designer who's considering getting into the development side? Forge ahead, but tread cautiously. JavaScript can be easy to start with, but it can get ugly very quickly. And it's very different from any server-side language (including Java). Some of your JavaScript skills will translate to other languages, (conditional and control-flow operators, for example). But some things are unique to JavaScript and will require some relearning if you move to another language.
Also, some things in JavaScript won't completely make sense unless you've done object-oriented development; even though JavaScript is "prototype-based" rather than strictly object-oriented, without the OO concepts to relate to, the prototyping system may be difficult to understand. The typing system also may not make much sense if you don't have a lot of experience with different typing systems (static vs. dynamic, explicit vs. implicit).
Use a good framework like jQuery or YUI, but be sure to understand what's going on behind the scenes. Shog9's suggestion to use FireBug is a good one, too. It will show you what's going on (without having to do a lot of alert() statements in your code).
Your HTML DOM and CSS experience will help some, but only in the sense of understanding what the JavaScript is trying to do. Having written HTML and CSS by hand won't help you learn to write JavaScript; HTML and CSS are document markup languages, not imperative programming languages.
So go for it, but don't expect it to be easy. You may make a lot of quick progress, only to find that you're not as far along as you think, and that things don't work the way the appear to. But with enough effort and research you'll probably get there.
I think learning Javascript is a great idea if you are all ready doing HTML and CSS. Javascript is a cool, but quirky language. Most people that use don't really know how to write good JS code. I highly recommend watching Douglas Crockford video, see http://video.yahoo.com/watch/111593
They will give the real scoop on Javascript.
I've recommended JavaScript: The Good Parts before (and can't recommend it highly enough), but if you're new to programming I suggest starting with Head First JavaScript.
(source: oreilly.com)
I think you've got an abundance of great answers and resources already, but I'd like to chime in, too, since I've seen a couple of jQuery recommendations:
I love jQuery, too, and use it nearly daily. That said, for a beginner, I would recommend that you be comfortable with javascript proper first before diving into jQuery. Being comfortable with the syntax, variables, scope, and at least some DOM concepts will greatly improve your understanding of how to do what you want with jQuery. If you try to speed too quickly past the fundamentals, you'll definitely get stuck on some common misunderstanding that jQuery won't be able to help you with.
http://codeavengers.com level 1 JavaScript is great for the complete beginner. I created the courses and have had lots of great feedback from beginners who have found my course a fun and effective way to learn JavaScript.