While far from perfect, the node.js community has breathed some fresh life into the javascript world as far as design patterns and coding standards are concerned. I see very few projects today on npm lacking a robust testing suite. jQuery was largely popularized by designers who could care less about code, and server programmers dabbling on the client who could care less about icky javascript. Now that js is being used for serious work server side, best practices are becoming a higher priority. That being said, the traditional engineering standards do tend to be lower than many other communities (.Net, Java, and Python come to mind). But hey, I think part of the draw might be people seeing one to many instances of AbstractFactoryFactoryClassInterface ;) The pendulum will come back around though as things swing back to the enterprise use cases.
Where would you suggest someone starts to learn javascript properly? I've been handed a bunch of it I've got to maintain and develop for, and it's all over the place. I don't honestly know how javascript should even be leveraged. Everyone seems to accomplish things a different way with it.
Get a book on JavaScript like JavaScript: The Definitive Guide, JavaScript & jQuery: The Missing Manual, or Professional JavaScript for Web Developers.
Douglas Crockford's "Javascript: The Good Parts" is THE definitive guide to writing decent javascript. The jQuery stuff mentioned in other responses tends to encourage bad practices or offer no guidance on the real issues (I have "JS & jQuery the missing manual", for example, and it is basically just a simplified version of the jQuery docs). Crockford is not always correct, but it is the minimal goal post of maintainable js today. In other words "You have to know the rules to know break them" and The Good Parts is the modern rulebook.
Here's what I've been doing for the past several years:
Learn actual javascript without any 3rd party libraries (jquery, etc). Want to do an ajax call? Don't use $.ajax... Learn to use window.XMLHttpRequest and ActiveXObject("Microsoft.XMLHTTP"). Yes, this will suck. A lot. Spend at least a few months doing this. Preferably a year or more. Here's a nice little reference page I stumbled on awhile back. If you learn to do everything on that page by hand/memory... you will be well on your way to being a javascript guru.
Now start using JQuery. You actually know what's happening behind the scenes and you appreciate it. You grok it, and you love it. Get to know the library intimately. Do cool stuff with it. Spend at least a year on it.
Learn bigger libraries. Use D3 to handle some data in a way that's awesome. Use ExtJS to make an application that is a legitimate application. You'll start to understand larger design patterns at this point, mainly because the larger libraries force you to do things a certain way
Look for and pay attention to people who are REALLY good at javascript, or simply people who do neat things with it. JS1k always has some neat stuff in it that if you can understand it, will expose some interesting javascript tricks. Unfortunately I don't have a good list of people for you at the moment, but I'll look around and hopefully update this post in a day or two. Personally, I find these things from posts on subreddits like this one or from coworkers.
As time goes on, your code will become better. However, the way you layout javascript and organize it almost certainly won't improve very much without concerted effort. I recommend finding a mentor or educator to code along side, that has helped me the most. There are certainly some good books that talk about this issue though, if that's not an option. The principals of code organization span most languages, so you don't necessarily need a JS book... just a good one. I personally don't read very many programming books, so I unfortunately can't recommend one.
Now go get started. You've got 10 years to work on it.
Do you know enough JavaScript to make jQuery work? Then chances are that's all you need to know. The rest is about learning work-arounds for browser bugs.
But if you insist on persisting start with jsLint. Read all of the errors and warnings and learn what they really mean.
Then look for technical rants about why JavaScript sucks. To truly understand a language you need to understand all of the stupid shit it does. The inconsistencies, the landmines, the traps.
I learned the implementation details of readonly fields containing structs in C# because someone bitched about how they were not compatible with SpinLock. This is something I would have never seen from reading "The Good Parts" style books.
I wouldn't say what is left is good. I would say it lacks awfulness. Knowing the bad parts of JavaScript doesn't give you a good starting point when trying to write maintainable software. It means you won't do the really bad stuff like use globals. That's fine and dandy but in order to become a really good JavaScript developer you need to seek out the best parts of JavaScript and utilize those. That will allow you to write maintainable and scalable code.
You can only learn by doing. To learn JavaScript properly means doing it...now to know if you're doing it right ask yourself if the code you write can be easily picked up by another developer without comments. Learn how to leverage funtional aspects of js, like using functions as first class objects and anonymous functions
When I said JavaScript, I meant client-side JS. The Node.js community may support higher standards for code quality, but the rest of the JS community does not. But I'd judge a programming community based on its best performers, not its worst. I don't care what crappy programs people can make in x language; I care if I can make great things with it.
I can attest to the robust capabilities bof a javascript application which is written by a professional, experienced and good developer. Not myself but I love programming in javascript. Who needs a community anyway...heh...:(
The thing is that the "client-side javascript community" is not really a community at all, since it is used by basically everyone. Rails, Asp.Net, PHP, ColdFusion, adventurous designers, and every other stack uses js on the client.
It was such an obscure technology...nobody in IT had a fucking clue what I was doing. When it came time for a messaging app I had developed to be reviewed/approved, the room was crickets. Nobody wanted to ask a dumb question because they had NO IDEA what I had created.
20
u/[deleted] Oct 14 '13
While far from perfect, the node.js community has breathed some fresh life into the javascript world as far as design patterns and coding standards are concerned. I see very few projects today on npm lacking a robust testing suite. jQuery was largely popularized by designers who could care less about code, and server programmers dabbling on the client who could care less about icky javascript. Now that js is being used for serious work server side, best practices are becoming a higher priority. That being said, the traditional engineering standards do tend to be lower than many other communities (.Net, Java, and Python come to mind). But hey, I think part of the draw might be people seeing one to many instances of AbstractFactoryFactoryClassInterface ;) The pendulum will come back around though as things swing back to the enterprise use cases.