Let's assume that I am the stupidest person that ever lived. Explain to me what JavaScript is, what it does, and how a moron would go about learning it...
September 7, 2011 4:33 PM Subscribe
Let's assume that I am the stupidest person that ever lived. Explain to me what JavaScript is, what it does, and how a moron would go about learning it...
annnnnnnnnd GO!
annnnnnnnnd GO!
Javascript is a programming language. Programming languages are a mean to give instructions to a computer to "do stuff". Web browsers, such as Firefox, Opera, Chrome, Safari, Internet Explorer, etc., "understand" Javascript.
With Javascript you can, among other things, add interactivity to a web page. For example, when you click on a "button" on a web page, often an action is performed by your browsers, usually the result of some hidden javascript code on that page.
I already knew about other programming languages before I learned about javascript ... so I did not need beginner's resources as such. However, I have heard that Eloquent Javascript was a good way for beginners to learn about javascript.
Best of luck!
posted by aroberge at 4:45 PM on September 7, 2011 [7 favorites]
With Javascript you can, among other things, add interactivity to a web page. For example, when you click on a "button" on a web page, often an action is performed by your browsers, usually the result of some hidden javascript code on that page.
I already knew about other programming languages before I learned about javascript ... so I did not need beginner's resources as such. However, I have heard that Eloquent Javascript was a good way for beginners to learn about javascript.
Best of luck!
posted by aroberge at 4:45 PM on September 7, 2011 [7 favorites]
"...how a moron would go about learning it..."
Check out Code Academy.
posted by fix at 4:46 PM on September 7, 2011
Check out Code Academy.
posted by fix at 4:46 PM on September 7, 2011
It's a computer programming language. It was specifically designed to let developers add/alter the behavior and appearance of bits of web pages displayed inside a web browser. And though it's grown into a few contexts beyond that, that's's still what it's mostly used for.
Like most computer programming languages, one fairly straightforward way to learn it is to study given examples of web pages and the behavior/appearance added to them with JavaScript from books or from the internet. Then reproduce them yourself (don't copy and paste, type them yourself). Then try reproducing them more or less from memory, or try changing them slightly to see what happens. After you've done this a few dozen times, start to consider making up your own exercises you'd like to do. Try them out.
This takes a long time for a lot of people, by the way. Patience is key.
posted by weston at 4:50 PM on September 7, 2011 [2 favorites]
Like most computer programming languages, one fairly straightforward way to learn it is to study given examples of web pages and the behavior/appearance added to them with JavaScript from books or from the internet. Then reproduce them yourself (don't copy and paste, type them yourself). Then try reproducing them more or less from memory, or try changing them slightly to see what happens. After you've done this a few dozen times, start to consider making up your own exercises you'd like to do. Try them out.
This takes a long time for a lot of people, by the way. Patience is key.
posted by weston at 4:50 PM on September 7, 2011 [2 favorites]
Response by poster: Oooooooh @ CodeAcademy.
I am teh dumb and this seems right up my alley. Thanks!
posted by Senor Cardgage at 5:01 PM on September 7, 2011
I am teh dumb and this seems right up my alley. Thanks!
posted by Senor Cardgage at 5:01 PM on September 7, 2011
It was specifically designed to let developers add/alter the behavior and appearance of bits of web pages displayed inside a web browser.
And in case this is helpful, you can look at a few examples and see how it solves problems for websites. Things Javascript stuff does that are cool include
- validating data before it goes all the way back to the server [so you could tell if a username is already taken or a phone number was in the wrong format]
- loading other images and content as a page is loading [so you have all the maps around the google map you are looking at, so your gmail messages are already loading while you're just looking at your inbox allowing you to pop open a message without waiting for it to load]
- allowing you to send messages back and forth to the server not in real time [so you can favorite or flag a thing here without reloading the entire page]
So I think of Javascript as a litte thing you can build into a web page that lets a website DO some things on its own without always phoning home to a server that may be thousands of miles away. This makes web pages more responsive and speedier to use in some ways and makes the whole browsing experience less like point-click-wait.
posted by jessamyn at 6:06 PM on September 7, 2011 [3 favorites]
And in case this is helpful, you can look at a few examples and see how it solves problems for websites. Things Javascript stuff does that are cool include
- validating data before it goes all the way back to the server [so you could tell if a username is already taken or a phone number was in the wrong format]
- loading other images and content as a page is loading [so you have all the maps around the google map you are looking at, so your gmail messages are already loading while you're just looking at your inbox allowing you to pop open a message without waiting for it to load]
- allowing you to send messages back and forth to the server not in real time [so you can favorite or flag a thing here without reloading the entire page]
So I think of Javascript as a litte thing you can build into a web page that lets a website DO some things on its own without always phoning home to a server that may be thousands of miles away. This makes web pages more responsive and speedier to use in some ways and makes the whole browsing experience less like point-click-wait.
posted by jessamyn at 6:06 PM on September 7, 2011 [3 favorites]
Response by poster: How in depth should a web designer (not necessarily developer)'s level of knowledge of Javascript be?
posted by Senor Cardgage at 6:16 PM on September 7, 2011
posted by Senor Cardgage at 6:16 PM on September 7, 2011
How in depth should a web designer (not necessarily developer)'s level of knowledge of Javascript be?
Assuming the web designer is part of a team that includes Javascript programmer, (s)he should know at least enough to be aware that there are limitations, primarily due to time constraints, to what Javascript can do. (In theory, one could do arbitrarily complex stuff given enough time...) Having an idea of the type of things that can be done "easily" would probably be useful to know. Knowing enough to communicate effectively should be the goal.
If the web designer sometimes work on their own, then (s)he should be able to adapt some existing code (written by others) to make *simple* changes when needed. Beyond that would be asking too much of a single individual in general.
posted by aroberge at 6:27 PM on September 7, 2011
Assuming the web designer is part of a team that includes Javascript programmer, (s)he should know at least enough to be aware that there are limitations, primarily due to time constraints, to what Javascript can do. (In theory, one could do arbitrarily complex stuff given enough time...) Having an idea of the type of things that can be done "easily" would probably be useful to know. Knowing enough to communicate effectively should be the goal.
If the web designer sometimes work on their own, then (s)he should be able to adapt some existing code (written by others) to make *simple* changes when needed. Beyond that would be asking too much of a single individual in general.
posted by aroberge at 6:27 PM on September 7, 2011
FWIW, I have always found the Head First books to be a good introduction to a subject. They do not strive to be reference books or overly technical, but to give you an understanding of the why and to some extent the how. I have not read their Javascript offering but you might want to browse through it if you can find it in a book store, and buy it if it really impresses you.
posted by forthright at 6:31 PM on September 7, 2011 [1 favorite]
posted by forthright at 6:31 PM on September 7, 2011 [1 favorite]
Here is something else you should know about Javascript that seems like it was almost designed to be confusing as possible:
- There is a programming language called Javascript.
- There is a programming language called Java.
- There is an interpreter ('thing that makes it go') for the programming language Javascript built into most web browsers
- There is an interpreter for the programming language Java that is sort of built in to most web browsers, or was.
- THESE TWO PROGRAMMING LANGUAGES HAVE ALMOST NOTHING TO DO WITH EACH OTHER
Back in the olden days, there was a company called Sun that had invented a programming language they decided to call Java. It was very trendy and exciting. There was a company called Netscape that made the trendiest and excitingest web browser. Sun wanted Netscape to include the magical crap that would make Java work with their browser, because everyone was gonna get Netscape, so everyone would also automatically have the stuff that makes Java programs work. On the other hand, Netscape was saying, "but lets also make our own tiny programming language that runs right in the browser so instead of having to make up new html tags like 'blink', web authors can make annoying shit we haven't even thought of yet!" So they said, "Sun, we'll ship your 'Java', but we want to be allowed to call our other programming language, which has absolutely no relationship to yours and is intended to do completely different things, JavaSCRIPT." And Sun said, "OK, swell. go nuts. That won't matter to us. ONCE JAVA TAKES OVER THE WORLD!"
So Netscape said to a guy named Brendan, who worked at Netscape, "Please make us a programming language. Also, you have to call it Javascript. Also, if you can make some of it kind-of sort-of look a bit like Java, that would be even better. Also, you have only 10 days to do this so get cracking!"
Fortunately, it turned out that Brendan was a cool genius and he secretly designed a cool programming language and dressed it up in some vaguely Java-looking disguises, kind of like how children will sometimes wear a huge cloak and stand on top of one another in order to get into R-rated films.
But Brendan's disguise worked too well! People were like "wtf is with this crap version of Java? IT SUCKS!" Also, even a cool genius like Brendan has some some limits, so he did make a few mistakes when he was making his programming language in only 10 days. Also, because Netscape had basically thrown down the gauntlet and said, "You think the blink tag is annoying? Marquee makes you want to rip your eyeballs out? YOU HAVEN'T SEEN NOTHING!" people did manage to find insanely annoying things to do with Javascript. All the cool people installed special software on their web browser JUST TO MAKE JAVASCRIPT NOT WORK. So it took many years before people started to figure out that Brendan's language was wrapped in an elaborate disguise and that it was actually cool.
Weirdly, some of the main people who did this were people at Microsoft, who had tried to confuse this whole mess out of existence by coming out with programming languages named stuff like J++ and JScript. Netscape, at the time, was threatening to rip Microsoft apart, like a crab rips up a cuttlefish with his claws. So Microsoft, adopting the strategy of the cuttlefish, made a million confusing "J" programming languages, hoping to escape intact. A prophet by the name of Douglas started saying, "guess what nerds, it turns out Javascript is actually sort of awesome." He managed to attract a fair number of acolytes, who fiddled with Brendan's invention and realized that it was rather elegant and could certainly be made to do all sorts of useful, non-annoying things on webpages, if only people would stop blocking it.
And so the era now known as Web 2.0 began. There are a lot of things people associate with Web 2.0, but for people who make the internet, one of the biggest things was seeing sites like Flickr or Oddpost do cool stuff with Javascript and other technologies that had been previously considered lame.
And then, in a sort of poetic irony that makes this story almost seem like it was pre-scripted to Teach us a Lesson, JAVASCRIPT succeeded in doing what JAVA had intended to do. Microsoft, Java, Sun, Netscape, all were brought low by their hubris. But humble Javascript, the throwaway, 'you get 10 days to make this', blink-tag-replacing runt of a language was able to sneak onto every computer in the world thanks to its clever disguise. Servers are written in Javascript. Databases are built to talk Javascript. The people who build browsers and operating systems move heaven and earth to make Javascript just a tiny bit faster. Java's still out there, of course. In various forms. It probably makes sure your account is updated when you pay your water bill. It's making the underpinnings of your android phone work. It's figured out a way to play host to a zillion new trendier programming languages. But Javascript won the original prize.
Anyway, I'm just pointing this out because I remember the time when I didn't know the difference between Java and Javascript and I'd find a tutorial for one or an article about the other and I was like "wtf, how do these go together." The answer is, "they don't. Marketing people just tried to name them as confusingly as possible."
posted by jeb at 7:05 PM on September 7, 2011 [491 favorites]
- There is a programming language called Javascript.
- There is a programming language called Java.
- There is an interpreter ('thing that makes it go') for the programming language Javascript built into most web browsers
- There is an interpreter for the programming language Java that is sort of built in to most web browsers, or was.
- THESE TWO PROGRAMMING LANGUAGES HAVE ALMOST NOTHING TO DO WITH EACH OTHER
Back in the olden days, there was a company called Sun that had invented a programming language they decided to call Java. It was very trendy and exciting. There was a company called Netscape that made the trendiest and excitingest web browser. Sun wanted Netscape to include the magical crap that would make Java work with their browser, because everyone was gonna get Netscape, so everyone would also automatically have the stuff that makes Java programs work. On the other hand, Netscape was saying, "but lets also make our own tiny programming language that runs right in the browser so instead of having to make up new html tags like 'blink', web authors can make annoying shit we haven't even thought of yet!" So they said, "Sun, we'll ship your 'Java', but we want to be allowed to call our other programming language, which has absolutely no relationship to yours and is intended to do completely different things, JavaSCRIPT." And Sun said, "OK, swell. go nuts. That won't matter to us. ONCE JAVA TAKES OVER THE WORLD!"
So Netscape said to a guy named Brendan, who worked at Netscape, "Please make us a programming language. Also, you have to call it Javascript. Also, if you can make some of it kind-of sort-of look a bit like Java, that would be even better. Also, you have only 10 days to do this so get cracking!"
Fortunately, it turned out that Brendan was a cool genius and he secretly designed a cool programming language and dressed it up in some vaguely Java-looking disguises, kind of like how children will sometimes wear a huge cloak and stand on top of one another in order to get into R-rated films.
But Brendan's disguise worked too well! People were like "wtf is with this crap version of Java? IT SUCKS!" Also, even a cool genius like Brendan has some some limits, so he did make a few mistakes when he was making his programming language in only 10 days. Also, because Netscape had basically thrown down the gauntlet and said, "You think the blink tag is annoying? Marquee makes you want to rip your eyeballs out? YOU HAVEN'T SEEN NOTHING!" people did manage to find insanely annoying things to do with Javascript. All the cool people installed special software on their web browser JUST TO MAKE JAVASCRIPT NOT WORK. So it took many years before people started to figure out that Brendan's language was wrapped in an elaborate disguise and that it was actually cool.
Weirdly, some of the main people who did this were people at Microsoft, who had tried to confuse this whole mess out of existence by coming out with programming languages named stuff like J++ and JScript. Netscape, at the time, was threatening to rip Microsoft apart, like a crab rips up a cuttlefish with his claws. So Microsoft, adopting the strategy of the cuttlefish, made a million confusing "J" programming languages, hoping to escape intact. A prophet by the name of Douglas started saying, "guess what nerds, it turns out Javascript is actually sort of awesome." He managed to attract a fair number of acolytes, who fiddled with Brendan's invention and realized that it was rather elegant and could certainly be made to do all sorts of useful, non-annoying things on webpages, if only people would stop blocking it.
And so the era now known as Web 2.0 began. There are a lot of things people associate with Web 2.0, but for people who make the internet, one of the biggest things was seeing sites like Flickr or Oddpost do cool stuff with Javascript and other technologies that had been previously considered lame.
And then, in a sort of poetic irony that makes this story almost seem like it was pre-scripted to Teach us a Lesson, JAVASCRIPT succeeded in doing what JAVA had intended to do. Microsoft, Java, Sun, Netscape, all were brought low by their hubris. But humble Javascript, the throwaway, 'you get 10 days to make this', blink-tag-replacing runt of a language was able to sneak onto every computer in the world thanks to its clever disguise. Servers are written in Javascript. Databases are built to talk Javascript. The people who build browsers and operating systems move heaven and earth to make Javascript just a tiny bit faster. Java's still out there, of course. In various forms. It probably makes sure your account is updated when you pay your water bill. It's making the underpinnings of your android phone work. It's figured out a way to play host to a zillion new trendier programming languages. But Javascript won the original prize.
Anyway, I'm just pointing this out because I remember the time when I didn't know the difference between Java and Javascript and I'd find a tutorial for one or an article about the other and I was like "wtf, how do these go together." The answer is, "they don't. Marketing people just tried to name them as confusingly as possible."
posted by jeb at 7:05 PM on September 7, 2011 [491 favorites]
Might I recommend Thau's JavaScript Tutorial? It's how I got started with JavaScript 13 years ago, and should give you a good, basic introduction from an "I know HTML but how the heck does this fit in?" perspective. People have figured out how to do some crazy stuff with JavaScript since that tutorial was first written, but it's always good to start with the fundamentals.
posted by usonian at 9:20 PM on September 7, 2011 [4 favorites]
posted by usonian at 9:20 PM on September 7, 2011 [4 favorites]
"Java is to Javascript as car is to carpet"
posted by iotic at 11:07 PM on September 7, 2011 [49 favorites]
posted by iotic at 11:07 PM on September 7, 2011 [49 favorites]
Netscape had been working on Javascript for a while. It was originally going to be called LiveScript. They decided to change the name when they started working with Sun to ship java.
posted by delmoi at 10:55 AM on September 8, 2011
posted by delmoi at 10:55 AM on September 8, 2011
> How in depth should a web designer (not necessarily developer)'s level of knowledge of Javascript be?
I used to be a designer. Became an HTML/CSS guy. Then started doing PHP because there wasn't anybody else available to take care of the backend stuff. Learned Javascript some time after that. For me, learning PHP was easier than learning Javascript, and so I was never really capable of doing front-end scripting (Javascript) at a professional level until I was already writing database-backed websites (PHP/MySQL/etc.).
The simple answer is that you should know enough about everybody else's jobs to know what they can do, but not necessarily enough to do their jobs. It's good to have a team whose members, likewise, also share a generalist's interest in how the rest of the process of making a website works.
When I work with designers and UI people (I might have been a designer, but I'm a better developer than I was a designer; I don't really design for the web any more), I like them to know what they can get away with. Designers who get the web -- that ineffable getting-it-ness, you know -- don't need a lot of prompting. They don't know the mechanics of how things work, but they keep an ear to the ground, see patterns in how other sites work, and enjoy discovering new things. Designers who don't, well, they're more likely to be churning out brochureware-grade sites. Printed paper for the web. The website is expected to look exactly as much like their Photoshop comp as possible. In some horrifying cases, even down to the black field surrounding the art area. Meh.
In the ideal situation, a designer can even point me (the developer) at an example of something they want to do that does something I hadn't realized could be done within the project's constraints. They're amenable to negotiation and modifications of the design as I point out things their design could be doing, or subtle compromises with beneficial tradeoffs ("Let's get rid of that lacy pattern behind the menu bar and we can speed up the load time immensely"), and likewise push back when the execution isn't in line with their vision of the project. ("The lacy pattern is part of the client's identity system.")
Ultimately it isn't a matter of knowing how Javascript works, although at the same time it is. Having at least a passing appreciation of how it works and its mechanics can cut back on impractical or unreasonable expectations. It means you don't start tuning out the tech people when they want to discuss project scope, and that you can engage intelligently with them when you ask them why something doesn't work. It means the site might not look as good as your comps, but in the best situations it makes the site better, overall, and that's what matters.
posted by ardgedee at 11:32 AM on September 8, 2011 [4 favorites]
I used to be a designer. Became an HTML/CSS guy. Then started doing PHP because there wasn't anybody else available to take care of the backend stuff. Learned Javascript some time after that. For me, learning PHP was easier than learning Javascript, and so I was never really capable of doing front-end scripting (Javascript) at a professional level until I was already writing database-backed websites (PHP/MySQL/etc.).
The simple answer is that you should know enough about everybody else's jobs to know what they can do, but not necessarily enough to do their jobs. It's good to have a team whose members, likewise, also share a generalist's interest in how the rest of the process of making a website works.
When I work with designers and UI people (I might have been a designer, but I'm a better developer than I was a designer; I don't really design for the web any more), I like them to know what they can get away with. Designers who get the web -- that ineffable getting-it-ness, you know -- don't need a lot of prompting. They don't know the mechanics of how things work, but they keep an ear to the ground, see patterns in how other sites work, and enjoy discovering new things. Designers who don't, well, they're more likely to be churning out brochureware-grade sites. Printed paper for the web. The website is expected to look exactly as much like their Photoshop comp as possible. In some horrifying cases, even down to the black field surrounding the art area. Meh.
In the ideal situation, a designer can even point me (the developer) at an example of something they want to do that does something I hadn't realized could be done within the project's constraints. They're amenable to negotiation and modifications of the design as I point out things their design could be doing, or subtle compromises with beneficial tradeoffs ("Let's get rid of that lacy pattern behind the menu bar and we can speed up the load time immensely"), and likewise push back when the execution isn't in line with their vision of the project. ("The lacy pattern is part of the client's identity system.")
Ultimately it isn't a matter of knowing how Javascript works, although at the same time it is. Having at least a passing appreciation of how it works and its mechanics can cut back on impractical or unreasonable expectations. It means you don't start tuning out the tech people when they want to discuss project scope, and that you can engage intelligently with them when you ask them why something doesn't work. It means the site might not look as good as your comps, but in the best situations it makes the site better, overall, and that's what matters.
posted by ardgedee at 11:32 AM on September 8, 2011 [4 favorites]
If you're interested in Java's potential for web design, look into jQuery- It's JavaScript's handy little toolbox. Way easier to use and way more focused on "design" implementation as opposed to stuff like programming a server or a DB app.
posted by GilloD at 11:44 AM on September 8, 2011 [4 favorites]
posted by GilloD at 11:44 AM on September 8, 2011 [4 favorites]
Also, even a cool genius like Brendan has some some limits, so he did make a few mistakes when he was making his programming language in only 10 days.
Brendan once admitted to me over lunch that he had "a bit of perl envy" when designing JavaScript. We're all still atoning for those sins a little bit now.
For those interested in why JavaScript wound up as an awesome language wrapped in an "elaborate disguise," Douglas Crockford's old "JavaScript: The World's Most Misunderstood Programming Language" is a good read.
For me, a central reason for all this has been that JavaScript is entirely too easy for lots of people to use really terribly. Anyone can go to someone else's web page, pop open View Source, and copy/paste code into their site to their heart's content. After all, that's how we learned a lot of HTML tricks back in the day. That's not a bad thing by any means: it's basically the most accessible programming language in the world. Everyone has an interpreter (heck, even my alarm clock runs JavaScript), all you need is a text editor, and bits of source code are spread wide and far across the web. A heck of a lot of tasks can be accomplished in a couple lines of copy/pasted js. Other languages–Professional Enterprise Programming Languages(tm)–require fancy compilers and IDEs and debuggers and make you learn all about their APIs and fancy language constructs just to understand hello world.
What all this means is that a lot of JavaScript programmers don't really know JavaScript. Honestly, I fall into this category myself at times. The language is so easy to get into that you can be a pretty competent practitioner without truly knowing all that much about it. But truly understanding and taking advantage of some of the more functional aspects of JavaScript is pretty important to producing maintainable large programs.
That's what makes the language so great, yet so misunderstood.
posted by zachlipton at 12:27 PM on September 8, 2011 [6 favorites]
Brendan once admitted to me over lunch that he had "a bit of perl envy" when designing JavaScript. We're all still atoning for those sins a little bit now.
For those interested in why JavaScript wound up as an awesome language wrapped in an "elaborate disguise," Douglas Crockford's old "JavaScript: The World's Most Misunderstood Programming Language" is a good read.
For me, a central reason for all this has been that JavaScript is entirely too easy for lots of people to use really terribly. Anyone can go to someone else's web page, pop open View Source, and copy/paste code into their site to their heart's content. After all, that's how we learned a lot of HTML tricks back in the day. That's not a bad thing by any means: it's basically the most accessible programming language in the world. Everyone has an interpreter (heck, even my alarm clock runs JavaScript), all you need is a text editor, and bits of source code are spread wide and far across the web. A heck of a lot of tasks can be accomplished in a couple lines of copy/pasted js. Other languages–Professional Enterprise Programming Languages(tm)–require fancy compilers and IDEs and debuggers and make you learn all about their APIs and fancy language constructs just to understand hello world.
What all this means is that a lot of JavaScript programmers don't really know JavaScript. Honestly, I fall into this category myself at times. The language is so easy to get into that you can be a pretty competent practitioner without truly knowing all that much about it. But truly understanding and taking advantage of some of the more functional aspects of JavaScript is pretty important to producing maintainable large programs.
That's what makes the language so great, yet so misunderstood.
posted by zachlipton at 12:27 PM on September 8, 2011 [6 favorites]
A web designer should understand the basic types of behavior supported by HTML and Javascript. For me, this comes down to understanding the types of behavior the code supports. HTML doesn't generally support any kind of dynamic behavior. You make a click somewhere and are being brought to a new page (even if it looks mostly the same). The live preview I'm looking at below is definitely javascript. The post answer or preview buttons are html. Mostly, you just need to have a good feel of what's possible and isn't, which you can get by trying to be aware of your interactions as you browse websites.
HTML = static interactions. Javascript = dynamic interactions.
posted by xammerboy at 2:44 PM on September 8, 2011
HTML = static interactions. Javascript = dynamic interactions.
posted by xammerboy at 2:44 PM on September 8, 2011
One of the best, and free, resources on JavaScript comes from Mozilla, where Brendan Eich, creator of JavaScript, is the CTO. Mozilla's Developer Network has in depth information on much of the standards that power the web.
https://developer.mozilla.org/en/JavaScript
posted by gen at 12:06 AM on September 9, 2011 [1 favorite]
https://developer.mozilla.org/en/JavaScript
posted by gen at 12:06 AM on September 9, 2011 [1 favorite]
For those of you who are more advanced with JS, and want to keep up on the state of affairs wrt ECMA and the future of JS, I recommend the A Minute With Brendan podcast.
posted by gen at 12:09 AM on September 9, 2011 [1 favorite]
posted by gen at 12:09 AM on September 9, 2011 [1 favorite]
Full disclosure: I work for Mozilla but not on any of the JS areas.
posted by gen at 12:09 AM on September 9, 2011
posted by gen at 12:09 AM on September 9, 2011
I'm primarily a designer who likes to do the HTML and CSS for my pages. But I never learned JavaScript. It was always a bit too hard, and easier to get someone else to do it to my specifications.
This is still largely the case, but what has made a huge difference to me is adopting jQuery, a framework that makes it easier to write JavaScript. You add the jQuery library via a element, and then you can write jQuery, which is like a language built on top of (and with) JavaScript. It's far easier to learn and to make sense of than raw JavaScript, especially if you already know CSS, which it borrows heavily from.
I now use jQuery to to add all sorts of simple interactivity to pages, mostly making things appear or disappear or change when I click or mouse over things. Anything more complex I still get someone else to do, but I am steadily learning more, using jQuery in Action
posted by snarfois at 1:58 AM on September 9, 2011 [1 favorite]
This is still largely the case, but what has made a huge difference to me is adopting jQuery, a framework that makes it easier to write JavaScript. You add the jQuery library via a element, and then you can write jQuery, which is like a language built on top of (and with) JavaScript. It's far easier to learn and to make sense of than raw JavaScript, especially if you already know CSS, which it borrows heavily from.
I now use jQuery to to add all sorts of simple interactivity to pages, mostly making things appear or disappear or change when I click or mouse over things. Anything more complex I still get someone else to do, but I am steadily learning more, using jQuery in Action
posted by snarfois at 1:58 AM on September 9, 2011 [1 favorite]
I meant to say, "You add the jQuery library via a "script" element" above -- the angle brackets got zapped.
posted by snarfois at 2:01 AM on September 9, 2011
posted by snarfois at 2:01 AM on September 9, 2011
Best answer:
In the early May timeframe, Bill and Marc Andreessen were among the notable few high-level management supporters of "Mocha", with Marc and I meeting at the Peninsula Creamery to plan grandly: not just annoying blink tag analogues but img rollovers. We had a drawing of an L.L. Bean online catalog with a shirt image. You'd pick your color and client-side JS would instantly update the img src.
Even in 1995 and 1996, early trailblazers were building big client-side JS apps that used hidden frames containing forms to do background I/O, prefiguring Ajax by 10 years.
JS was never intended by Sun or most of Netscape's management to be more than the sidekick to Java, but I had to make it work even if Java wasn't there or was inside the "plugin prison", and in doing so I created the DOM level 0 and a whole bunch of stuff (e.g., the same origin policy, mixed with cross-site script loading, used for analytics and advertising and security attacks now) that helped JS overtake Java in browsers.
Sun's mismanagement of Java didn't hurt, either, but even if they'd made it the best plugin ever, it would only ever have been Flash.
/be
posted by BrendanEich at 1:32 PM on September 10, 2011 [283 favorites]
So Netscape said to a guy named Brendan, who worked at Netscape, "Please make us a programming language. Also, you have to call it Javascript.The "look like Java" mandate came early, but the name was "Mocha" from May 1995 until around September, IIRC, where it became "LiveScript" (to match Netscape's "LiveWire" server authoring CMS PHP-like offering with browser-based HTML editor). Only in early December did "Bill Joy, Founder" sign on the trademark license allowing Netscape to call it JavaScript. I heard he was a hunted man at Sun the next day.
In the early May timeframe, Bill and Marc Andreessen were among the notable few high-level management supporters of "Mocha", with Marc and I meeting at the Peninsula Creamery to plan grandly: not just annoying blink tag analogues but img rollovers. We had a drawing of an L.L. Bean online catalog with a shirt image. You'd pick your color and client-side JS would instantly update the img src.
Even in 1995 and 1996, early trailblazers were building big client-side JS apps that used hidden frames containing forms to do background I/O, prefiguring Ajax by 10 years.
JS was never intended by Sun or most of Netscape's management to be more than the sidekick to Java, but I had to make it work even if Java wasn't there or was inside the "plugin prison", and in doing so I created the DOM level 0 and a whole bunch of stuff (e.g., the same origin policy, mixed with cross-site script loading, used for analytics and advertising and security attacks now) that helped JS overtake Java in browsers.
Sun's mismanagement of Java didn't hurt, either, but even if they'd made it the best plugin ever, it would only ever have been Flash.
/be
posted by BrendanEich at 1:32 PM on September 10, 2011 [283 favorites]
Everybody else has explained it much better than I could. But W3 Schools is an amazing resource for learning JavaScript from scratch, and is a go to standard site for all web-programming related tutorials. Learned everything I know off of this site.
posted by Arlecchino at 1:49 PM on September 10, 2011 [1 favorite]
posted by Arlecchino at 1:49 PM on September 10, 2011 [1 favorite]
ZOMG MEFI'S OWN BRENDAN EICH
(seriously, love the oral history going on in this thread)
posted by mkultra at 9:27 PM on September 10, 2011
(seriously, love the oral history going on in this thread)
posted by mkultra at 9:27 PM on September 10, 2011
We had a drawing of an L.L. Bean online catalog with a shirt image. You'd pick your color and client-side JS would instantly update the img src.
And if only you guys had written a patent on that one; you could own the modern web. Even Amazon didn't get around to a feature like that until the mid-2000s. But a software patent would be evil of course...
Your point about Flash reminds me of just how dog-slow Java applets were back in the day. Between the time it take to download the applet (over dial-up, naturally), load the JVM, and begin executing the applet, I remember 30-second delays as relatively common. And then the applet would probably crash or get stuck somehow and the waiting would all be for nothing. At one point, Gosling's response to this problem was that we should "get over it."
It's not like things have gotten all that much better today. I just clicked on this random java applet from a google search on my Mac and it took over 10 seconds to load (complete with random animated Java advertisements), despite my machine being several orders of magnitude more powerful today. That applet was originally created in 1995, when a 132mhz PowerPC or similarly clocked Pentium was top of the line and few machines had more than 16mb of memory, as compared to the 2.2ghz Core i7 and 4gb of ram in my laptop (and I really should take that to 8gb).
JS, in contrast, has gone from being fast enough to make text blink, to fast enough to emulate an entire x86 PC and run Linux. As much as I like to gripe about Flash's slow load times and lack of stability, an L.L. Bean online catalog page with a color selector that takes 10 seconds to load is inconceivable. Sun might have intended JS to be the sidekick, but it was never a fair fight when they couldn't even rise to the level of Adobe's incompetence at plugin development.
Sorry for the "perl envy" crack by the way!
posted by zachlipton at 9:51 PM on September 10, 2011
And if only you guys had written a patent on that one; you could own the modern web. Even Amazon didn't get around to a feature like that until the mid-2000s. But a software patent would be evil of course...
Your point about Flash reminds me of just how dog-slow Java applets were back in the day. Between the time it take to download the applet (over dial-up, naturally), load the JVM, and begin executing the applet, I remember 30-second delays as relatively common. And then the applet would probably crash or get stuck somehow and the waiting would all be for nothing. At one point, Gosling's response to this problem was that we should "get over it."
It's not like things have gotten all that much better today. I just clicked on this random java applet from a google search on my Mac and it took over 10 seconds to load (complete with random animated Java advertisements), despite my machine being several orders of magnitude more powerful today. That applet was originally created in 1995, when a 132mhz PowerPC or similarly clocked Pentium was top of the line and few machines had more than 16mb of memory, as compared to the 2.2ghz Core i7 and 4gb of ram in my laptop (and I really should take that to 8gb).
JS, in contrast, has gone from being fast enough to make text blink, to fast enough to emulate an entire x86 PC and run Linux. As much as I like to gripe about Flash's slow load times and lack of stability, an L.L. Bean online catalog page with a color selector that takes 10 seconds to load is inconceivable. Sun might have intended JS to be the sidekick, but it was never a fair fight when they couldn't even rise to the level of Adobe's incompetence at plugin development.
Sorry for the "perl envy" crack by the way!
posted by zachlipton at 9:51 PM on September 10, 2011
For the ones who are waiting on the film to the multitude of tutorial books, there is "Crockford on JavaScript a 5 video / approx. 8 hour marathon on everything you might never really wanted to know about the language and more.
posted by KMB at 1:00 AM on September 11, 2011
posted by KMB at 1:00 AM on September 11, 2011
Thanks for dropping in, and thanks for not patenting every idea in JavaScript; the Web can't flourish if it gets patent-bound.
posted by theora55 at 7:42 AM on September 11, 2011 [3 favorites]
posted by theora55 at 7:42 AM on September 11, 2011 [3 favorites]
(@Arlecchino, W3 Schools is not a great resource, sorry. It is inaccurate and I think gets undeserved publicity from a name similar to w3.org, which has the specs and reference documentation.)
Since OP is a web designer, codecademy will provide a quick programming intro, eloquent Javascript a more complete overview, and jQuery for designers thematic tutorials to bridge the two worlds. Use MDC, W3.org, and the docs of your preferred DOM library for reference, and search stackoverflow.com|stackexchange.com|doctype.com for FAQ and further links. Javascript: the definitive guide (6th edition) is a thorough, quality book on the topic.
posted by Tobu at 2:07 PM on September 11, 2011 [9 favorites]
Since OP is a web designer, codecademy will provide a quick programming intro, eloquent Javascript a more complete overview, and jQuery for designers thematic tutorials to bridge the two worlds. Use MDC, W3.org, and the docs of your preferred DOM library for reference, and search stackoverflow.com|stackexchange.com|doctype.com for FAQ and further links. Javascript: the definitive guide (6th edition) is a thorough, quality book on the topic.
posted by Tobu at 2:07 PM on September 11, 2011 [9 favorites]
My favorite book for learning JS, as someone who had a mental block for years and years even after I learned PHP, is DOM Scripting. (I read the 1st edition, haven't seen the 2nd edition.) He definitely comes from the direction of someone who has written a lot of HTML and CSS, and I had my JS lightbulb moment while reading it. That book got me over the OMG I am so much teh dumb feeling.
The Head First JavaScript book suggested above is pretty good, although I wish it used more progressive enhancement techniques. Oblig disclaimer: I was a tech reviewer for that book. I learned a few things while reading a draft, and I also made lots of comments about said progressive enhancement; I have not read the entire finished version.
I was also a tech reviewer for JavaScript Cookbook, which is great if you get into more JS and need a how-to reference handy. I've used it quite a bit in my work.
jQuery, as mentioned by others, is pretty awesome. I actually think it follows well after getting a good understanding of the fundamentals of DOM manipulation. It's nice to not have to reinvent the wheel when you just want to do something fairly simple.
posted by epersonae at 11:40 AM on September 12, 2011 [1 favorite]
The Head First JavaScript book suggested above is pretty good, although I wish it used more progressive enhancement techniques. Oblig disclaimer: I was a tech reviewer for that book. I learned a few things while reading a draft, and I also made lots of comments about said progressive enhancement; I have not read the entire finished version.
I was also a tech reviewer for JavaScript Cookbook, which is great if you get into more JS and need a how-to reference handy. I've used it quite a bit in my work.
jQuery, as mentioned by others, is pretty awesome. I actually think it follows well after getting a good understanding of the fundamentals of DOM manipulation. It's nice to not have to reinvent the wheel when you just want to do something fairly simple.
posted by epersonae at 11:40 AM on September 12, 2011 [1 favorite]
You should also thank Sun Microsystems for not patenting every idea in Self.
posted by Crabby Appleton at 7:03 PM on September 12, 2011
posted by Crabby Appleton at 7:03 PM on September 12, 2011
HOLY SHIT!! Brendan Eich! If I had breasts I would ask you to sign them.
I know this is totally not cool for AskMe but I hope my nearly-4500 answers has at least earned me the right for one totally-not-an-answer bit of hero-worship.
posted by Civil_Disobedient at 1:00 PM on September 13, 2011 [10 favorites]
I know this is totally not cool for AskMe but I hope my nearly-4500 answers has at least earned me the right for one totally-not-an-answer bit of hero-worship.
posted by Civil_Disobedient at 1:00 PM on September 13, 2011 [10 favorites]
In related news:
Ars Technica || September 14, 2011: Critics Call Foul As Google Takes Aim At Javascript With Dart
Ars Technica || September 14, 2011: Critics Call Foul As Google Takes Aim At Javascript With Dart
"Google is preparing to unveil a new client-side programming language for the Web with the aim of eventually supplanting JavaScript. Mozilla's Brendan Eich, the creator of JavaScript, is among the critics who are concerned about how the plan will impact the open Web."posted by ericb at 1:30 PM on September 14, 2011
I want to take a few minutes to discuss javascript at a slightly higher level, and how it fits in to the modern programming world, with a little history on the evolution of languages.
In the early days of software development, everyone was breaking new ground and pioneering new ideas. There were no "patterns" or "best practices", there were just new and novel ways of telling clever transistor (or diodes, in the early, early days) configurations how to combine themselves to do some basic logic oprations: AND, OR, NOT etc... this started with sliding paper cards with holes punched in them in certain configurations so that photoresistors could pick up an "instruction" and the clever configuration of transistors/diodes could do neat things, like math. The holes would represent 1's or 0's, and by allowing light to pass through would indicate a current "on" or "off" condition, which would cascade through the clever transistors and end up with another series of 1's in 0's, that would represent an answer to a question.
Over time, the configuration of the transistors became more and more clever, and punching holes in a piece of paper to write a program was clearly not an effective means of software development (if you made a mistake, you start over with a new card). So the very smart people in the industry figured out that you could add an additional layer on top of the holes in paper, called a "programming language". This "language" would, in turn, be converted by another program (called an assembler) into a virtual series of holes. One of the cool things about representing things as a series of holes, is that we can apply some math theory on alternate numbering systems to it, and do neat tricks. We can treat the holes, or 1's and 0's as a base 2 numbering system called 'binary'. Binary is tough to work with all by itself, it looks like this: 0000 0001 0000 1000 0000 0011 1101 1000. That get's confusing fast, so as a shortcut we can easily convert binary into a base 16 numbering system called "hexadecimal". So, instead of all those 1's and 0's, we can represent the same thing as: 0108 03D8. Much easier right?
Remember though, 0108 03D8 still just represents a bunch of "virtual holes". When we send these virtual holes to the CPU (the central processing unit) the clever transistors output some sort of value. We call this an "instruction". Numbers like 0108 03D8 are hard to remember though, so (as I mentioned above) we can assign names to those numbers, and have a program translate our names back into virtual holes. One of the earliest languages, called Assembly, did just that. We can write an 'instruction' in Assembly, like "ADD AX, BX" which will add two numbers together. That instruction gets translated into the same series of virtual holes above: 0108 03D8, or 0000 0001 0000 1000 0000 0011 1101 1000 as the computer sees it.
Assembly is still in common use today (I use it frequently in various microcontrollers) but not for larger applications. Assembly is a whole lot easier than remembering a bunch of 1's and 0's, but it would be next to impossible to write something like a web page in it (unless you were very patient).
It quickly became obvious that more sophisticated languages were needed, and a bunch of incredibly smart people invented some very cool things in the 70's and 80's. Of all the languages that were invented during that time, one took hold more than any of the others, a language called "C". C was neat for a lot of reasons, you could write a program in C and run it on lots of different processor architectures (clever configurations of transistors, but put together in different and incompatible clever ways). It had a straight forward syntax, and used curly braces and semi colons to define blocks of instructions and statements. It was also pretty easy to write a "compiler" for it: a program that translates the C language into a whole bunch of virtual holes that the processor can use to execute.
C had (and still has) a huge impact on software development, and many languages since C have borrowed heavily from it's syntax, including javascript (remember javascript? this is a discussion about javascript). It was quickly found, however, that C had some limitations. Again, for very large complex programs, unless the C code was written by talented and consistent developers, the programs could become difficult or impossible to maintain. In C you wrote functions (sub routines of code that could be called from the main execution flow). This was a style known as "procedural" programming.
In the real world, we don't have teams of talented and consistent developers, we just have people who program, and they are normal people who have bad days, problems at home, get bored and lazy, and are faced with different degrees of pressures from the business and varying levels of competence from management. The result can be a total mess.
In an attempt to address some of the problems with C (and people), some very smart people came up with a new paradigm for development called "Object Oriented Programming" or OOP. OOP was a way to develop software that could be modeled and diagrammed effectively, before development ever started! There were also many claims of code reuse, but it was quickly found that this rarely, if ever, actually happened any more than old-fashioned C code. One of the biggest benefits to OOP was that once you had designed your software, and if you followed good OOP principals, even mediocre developers were constrained by what they were able to do, and they weren't able to really cause too much damage to a project (if they followed the design). Because of this, OOP quickly became the Next Big Thing(tm), and the biggest most important language of them all became the most popular language in the world: C++.
C++ was a great language that took a C style syntax, and added all of the concepts of OOP. It allowed you to encapsulate functionality, enforce certain ways of accessing code, and still gave you close to the speed of execution of C.
Unfortunately, C++ had a lot of problems too. The compilers (translating the code to virtual holes) were a nightmare to write (because of things like multiple inheritence), and tricky bits of code were still left up to the developer to deal with. Things like memory management, pointers etc... were the biggest cause of software bugs when writing in C++.
To solve these issues, some very smart people at Sun came up with the idea of running all of the code inside of a "Virtual Machine" (this wasn't a new idea) that would deal with all of the fiddly bits for you. The developed a language that was entirely structured around the concepts of OOP and released it to the world. The language was called Java.
Many other languages that were in the main stream Big Business development limelight came out around the same time, using many of the same concepts. Microsoft developed their own version of Java, but named the virtual machine ".Net" and called their language "C#". Other variants also existed.
For the huge bulk of "Enterprise Software Development" this the the current state of things. Java, C# and C++ are the "big three" languages, and considered by many to be "real" languages, while other languages are considered "toys". This is a dangerous, but common, mistake. Also, OOP has many weaknesses as well. In trying to enforce rigidity, strict typing and modelling, programs can quickly become a mass of what is kindly referred to as "spaghetti code". OOP can require you to jump though many hoops to do seemingly simple things, and it requires you tell tell the compiler a ton of information about your code (data types, interfaces, classes, structures etc...) this all means writing a lot of code. Over time, because of these limitations, tools have sprung up with help with this. Tools that automatically generate a bunch of code for you. Frameworks that try to ease the burden of repetitive development that OOP forces on you. Design patterns with esoteric names like "flyweight" and "chain of responsibility" that are needed just so programmers can explain the structure of the code. AOP, which is a mechanism to try to bypass the fundamentals of OOP by dynamically "swapping" implementations. If this all seems confusing, trust me - it is. The complexity that has built around overcoming fundamental issues with static typing and OOP can make your head spin, and more are invented every day, it seems.
Some visionaries very early on foresaw some of these problems with OOP. Around the same time that the theories of OOP were being developed, these very smart people were developing some alternate theories of how languages should work. At the end of the day, all of these languages end up as a bunch of virtual holes to a CPU, but to the people who are writing the programs, the theories of software development are very important.
One of the alternate theories used a paradigm known as "functional programming". Unlike OOP, functional programming is not strictly defined, it is more a style, or set of techniques, that do things in different ways than OOP. Many languages support these techniques, and over time some of the concepts have crept into mainstream OOP languages like Java and C# (more rapidly in C#, because Java has had some trouble evolving). Neat languages like LISP (and it's derivatives), Python, F# and many others focus on these function programming (FP) techniques. They allow you use techniques to process data that is wildy different than OOP, in many fewer lines of code. In general, they are loosely typed (meaning you don't have to tell the compiler a whole lot of information about the code itself, like "meta-code", the compiler/vm/interpreter is expected to be able to figure it out), dynamic languages that are fast to develop in, and easy to use. They are all generally Frowned Upon Strongly by the OOP folks, because the systems that are build out of them aren't as rigidly defined.
This finally brings us to Javascript. Remember Javascript? Yes, this is a discussion about javascript.
Javascript has a brilliant approach to solving all of these problems. Javascript let's you do some of the OOPy things, like inheritance, while giving you the freedom to use a more functional style, if you like.
Javascript doesn't bother you with strict data types, it expects you to be smart enough to not need a compiler to tell you "no, you can't use that variable as a string, you told me it was a number before, neener neener".
It allows you to treat subroutines as data, and pass functions around as if they were any other piece of data. It allows you to do wonderfully complex things in very little code. For example, my Auto Pollock joke took me less than an hour to write, and is only about 50 lines of "real code".
Javascript is wonderfully expressive and free, and as a result some amazing new development paradigms and techniques have been developed from it, like John Resig's jquery library.
The main "problem" with javascript, is really the same "problem" that existed with C - if not written by talented, consistent developers, it can be a total mess.
The current state of javascript is interesting. See, the OOP/static language crowd pretty much all passionately hate javascript. I hear comments from developers that call it "one of those mushy languages". The people who seem to dislike it the most, are people who really have never taken the time to learn it properly. I'm frequently confused by this, because these sorts of comments and emotions come from otherwise quite intelligent people. I'm also confused, because an experienced developer can learn the innards of javascript in less than an afternoon of study. Prototype based inheritance, closures and anonymous inlines really aren't complex subjects. Understanding how "this" works and variable scoping in js really isn't complex either, it's just different.
I'm amused that one of Google's main criticisms of javascript (used as a justification for Dart, their new language) is that it can't be easily "tooled". What this means, is that it isn't easy for the mess of code generators, frameworks, IDE's and other things that the OOP people rely on so much to work with javascript. The reason I find this amusing is because that's the whole point! when you're doing it right, you don't need any of that stuff!
Javascript is currently undergoing some revisions and enhancements that will (hopefully) make it even better. Actually, this would have already happened if it hadn't been for some political infighting between Adobe and Microsoft.
In closing, I find javascript to be the next evolution in language technology and software development theory. Sure, in the end it all ends up as virtual holes in punch cards, but the process of creating those holes can be rewarding and elegant. As we learn more about software development and languages, really what we're learning about is people. We're trying to find ways to make people more productive, both developers and users. We're trying to improve people's lives by eliminating redundancies and frustrations.
Developers (and people) will always be resistant to change and new paradigms, we don't like to see the skills we've worked so hard to develop fade and become obsolete. In the case of learning Javascript however, the change is well worth the effort.
-Clay Gulick
posted by recurse at 9:03 AM on September 16, 2011 [24 favorites]
In the early days of software development, everyone was breaking new ground and pioneering new ideas. There were no "patterns" or "best practices", there were just new and novel ways of telling clever transistor (or diodes, in the early, early days) configurations how to combine themselves to do some basic logic oprations: AND, OR, NOT etc... this started with sliding paper cards with holes punched in them in certain configurations so that photoresistors could pick up an "instruction" and the clever configuration of transistors/diodes could do neat things, like math. The holes would represent 1's or 0's, and by allowing light to pass through would indicate a current "on" or "off" condition, which would cascade through the clever transistors and end up with another series of 1's in 0's, that would represent an answer to a question.
Over time, the configuration of the transistors became more and more clever, and punching holes in a piece of paper to write a program was clearly not an effective means of software development (if you made a mistake, you start over with a new card). So the very smart people in the industry figured out that you could add an additional layer on top of the holes in paper, called a "programming language". This "language" would, in turn, be converted by another program (called an assembler) into a virtual series of holes. One of the cool things about representing things as a series of holes, is that we can apply some math theory on alternate numbering systems to it, and do neat tricks. We can treat the holes, or 1's and 0's as a base 2 numbering system called 'binary'. Binary is tough to work with all by itself, it looks like this: 0000 0001 0000 1000 0000 0011 1101 1000. That get's confusing fast, so as a shortcut we can easily convert binary into a base 16 numbering system called "hexadecimal". So, instead of all those 1's and 0's, we can represent the same thing as: 0108 03D8. Much easier right?
Remember though, 0108 03D8 still just represents a bunch of "virtual holes". When we send these virtual holes to the CPU (the central processing unit) the clever transistors output some sort of value. We call this an "instruction". Numbers like 0108 03D8 are hard to remember though, so (as I mentioned above) we can assign names to those numbers, and have a program translate our names back into virtual holes. One of the earliest languages, called Assembly, did just that. We can write an 'instruction' in Assembly, like "ADD AX, BX" which will add two numbers together. That instruction gets translated into the same series of virtual holes above: 0108 03D8, or 0000 0001 0000 1000 0000 0011 1101 1000 as the computer sees it.
Assembly is still in common use today (I use it frequently in various microcontrollers) but not for larger applications. Assembly is a whole lot easier than remembering a bunch of 1's and 0's, but it would be next to impossible to write something like a web page in it (unless you were very patient).
It quickly became obvious that more sophisticated languages were needed, and a bunch of incredibly smart people invented some very cool things in the 70's and 80's. Of all the languages that were invented during that time, one took hold more than any of the others, a language called "C". C was neat for a lot of reasons, you could write a program in C and run it on lots of different processor architectures (clever configurations of transistors, but put together in different and incompatible clever ways). It had a straight forward syntax, and used curly braces and semi colons to define blocks of instructions and statements. It was also pretty easy to write a "compiler" for it: a program that translates the C language into a whole bunch of virtual holes that the processor can use to execute.
C had (and still has) a huge impact on software development, and many languages since C have borrowed heavily from it's syntax, including javascript (remember javascript? this is a discussion about javascript). It was quickly found, however, that C had some limitations. Again, for very large complex programs, unless the C code was written by talented and consistent developers, the programs could become difficult or impossible to maintain. In C you wrote functions (sub routines of code that could be called from the main execution flow). This was a style known as "procedural" programming.
In the real world, we don't have teams of talented and consistent developers, we just have people who program, and they are normal people who have bad days, problems at home, get bored and lazy, and are faced with different degrees of pressures from the business and varying levels of competence from management. The result can be a total mess.
In an attempt to address some of the problems with C (and people), some very smart people came up with a new paradigm for development called "Object Oriented Programming" or OOP. OOP was a way to develop software that could be modeled and diagrammed effectively, before development ever started! There were also many claims of code reuse, but it was quickly found that this rarely, if ever, actually happened any more than old-fashioned C code. One of the biggest benefits to OOP was that once you had designed your software, and if you followed good OOP principals, even mediocre developers were constrained by what they were able to do, and they weren't able to really cause too much damage to a project (if they followed the design). Because of this, OOP quickly became the Next Big Thing(tm), and the biggest most important language of them all became the most popular language in the world: C++.
C++ was a great language that took a C style syntax, and added all of the concepts of OOP. It allowed you to encapsulate functionality, enforce certain ways of accessing code, and still gave you close to the speed of execution of C.
Unfortunately, C++ had a lot of problems too. The compilers (translating the code to virtual holes) were a nightmare to write (because of things like multiple inheritence), and tricky bits of code were still left up to the developer to deal with. Things like memory management, pointers etc... were the biggest cause of software bugs when writing in C++.
To solve these issues, some very smart people at Sun came up with the idea of running all of the code inside of a "Virtual Machine" (this wasn't a new idea) that would deal with all of the fiddly bits for you. The developed a language that was entirely structured around the concepts of OOP and released it to the world. The language was called Java.
Many other languages that were in the main stream Big Business development limelight came out around the same time, using many of the same concepts. Microsoft developed their own version of Java, but named the virtual machine ".Net" and called their language "C#". Other variants also existed.
For the huge bulk of "Enterprise Software Development" this the the current state of things. Java, C# and C++ are the "big three" languages, and considered by many to be "real" languages, while other languages are considered "toys". This is a dangerous, but common, mistake. Also, OOP has many weaknesses as well. In trying to enforce rigidity, strict typing and modelling, programs can quickly become a mass of what is kindly referred to as "spaghetti code". OOP can require you to jump though many hoops to do seemingly simple things, and it requires you tell tell the compiler a ton of information about your code (data types, interfaces, classes, structures etc...) this all means writing a lot of code. Over time, because of these limitations, tools have sprung up with help with this. Tools that automatically generate a bunch of code for you. Frameworks that try to ease the burden of repetitive development that OOP forces on you. Design patterns with esoteric names like "flyweight" and "chain of responsibility" that are needed just so programmers can explain the structure of the code. AOP, which is a mechanism to try to bypass the fundamentals of OOP by dynamically "swapping" implementations. If this all seems confusing, trust me - it is. The complexity that has built around overcoming fundamental issues with static typing and OOP can make your head spin, and more are invented every day, it seems.
Some visionaries very early on foresaw some of these problems with OOP. Around the same time that the theories of OOP were being developed, these very smart people were developing some alternate theories of how languages should work. At the end of the day, all of these languages end up as a bunch of virtual holes to a CPU, but to the people who are writing the programs, the theories of software development are very important.
One of the alternate theories used a paradigm known as "functional programming". Unlike OOP, functional programming is not strictly defined, it is more a style, or set of techniques, that do things in different ways than OOP. Many languages support these techniques, and over time some of the concepts have crept into mainstream OOP languages like Java and C# (more rapidly in C#, because Java has had some trouble evolving). Neat languages like LISP (and it's derivatives), Python, F# and many others focus on these function programming (FP) techniques. They allow you use techniques to process data that is wildy different than OOP, in many fewer lines of code. In general, they are loosely typed (meaning you don't have to tell the compiler a whole lot of information about the code itself, like "meta-code", the compiler/vm/interpreter is expected to be able to figure it out), dynamic languages that are fast to develop in, and easy to use. They are all generally Frowned Upon Strongly by the OOP folks, because the systems that are build out of them aren't as rigidly defined.
This finally brings us to Javascript. Remember Javascript? Yes, this is a discussion about javascript.
Javascript has a brilliant approach to solving all of these problems. Javascript let's you do some of the OOPy things, like inheritance, while giving you the freedom to use a more functional style, if you like.
Javascript doesn't bother you with strict data types, it expects you to be smart enough to not need a compiler to tell you "no, you can't use that variable as a string, you told me it was a number before, neener neener".
It allows you to treat subroutines as data, and pass functions around as if they were any other piece of data. It allows you to do wonderfully complex things in very little code. For example, my Auto Pollock joke took me less than an hour to write, and is only about 50 lines of "real code".
Javascript is wonderfully expressive and free, and as a result some amazing new development paradigms and techniques have been developed from it, like John Resig's jquery library.
The main "problem" with javascript, is really the same "problem" that existed with C - if not written by talented, consistent developers, it can be a total mess.
The current state of javascript is interesting. See, the OOP/static language crowd pretty much all passionately hate javascript. I hear comments from developers that call it "one of those mushy languages". The people who seem to dislike it the most, are people who really have never taken the time to learn it properly. I'm frequently confused by this, because these sorts of comments and emotions come from otherwise quite intelligent people. I'm also confused, because an experienced developer can learn the innards of javascript in less than an afternoon of study. Prototype based inheritance, closures and anonymous inlines really aren't complex subjects. Understanding how "this" works and variable scoping in js really isn't complex either, it's just different.
I'm amused that one of Google's main criticisms of javascript (used as a justification for Dart, their new language) is that it can't be easily "tooled". What this means, is that it isn't easy for the mess of code generators, frameworks, IDE's and other things that the OOP people rely on so much to work with javascript. The reason I find this amusing is because that's the whole point! when you're doing it right, you don't need any of that stuff!
Javascript is currently undergoing some revisions and enhancements that will (hopefully) make it even better. Actually, this would have already happened if it hadn't been for some political infighting between Adobe and Microsoft.
In closing, I find javascript to be the next evolution in language technology and software development theory. Sure, in the end it all ends up as virtual holes in punch cards, but the process of creating those holes can be rewarding and elegant. As we learn more about software development and languages, really what we're learning about is people. We're trying to find ways to make people more productive, both developers and users. We're trying to improve people's lives by eliminating redundancies and frustrations.
Developers (and people) will always be resistant to change and new paradigms, we don't like to see the skills we've worked so hard to develop fade and become obsolete. In the case of learning Javascript however, the change is well worth the effort.
-Clay Gulick
posted by recurse at 9:03 AM on September 16, 2011 [24 favorites]
This thread is closed to new comments.
posted by megatherium at 4:41 PM on September 7, 2011 [1 favorite]