Programming Javascript Applications - is it about applications, or the language itself?

[Michael Swierczek]

Eric Elliott,
Thanks for taking part in the promotion contest. I have two questions related to the book and then other, less important questions you can ignore if you're uninterested or pressed for time.

1. The book title implies the book is oriented towards building applications. But the table of contents - asynchronous operations, functional programming, interfaces, lambdas, etc... looks like more than half is just dedicated to the Javascript language itself. I don't see that as bad, I'm just asking whether the book is really half learn Javascript and half learn how to make non-trivial Javascript applications.

2. Does the book walk through building one particular sample application as an example, or is it broken into a few sample applications? Or does it not work that way, and all of the sections have examples isolated from each other?

3. I'm just curious, given your expertise in Javascript, what you think of Typescript (Microsoft's open source superset of Javascript that includes type parameters and a class and module system), or the languages that compile into Javascript, like Dart, Coffeescript, or Clojurescript. Are you satisfied with working in raw Javascript, or do you have a favorite path forward that you believe would work best to make the language easier to use for complex applications?

4. When I'm reading someone's work, it helps me to understand their approach if I know what other areas of study and programming languages they know and like to use. (e.g. Larry Wall, creator of Perl, is a linguist. Martin Odersky, who created Scala, worked on the Java compiler at Sun and helped design Java generics. etc...) So... if you like, please inform us of your background and other languages you like to use, if any.

5. As mobile devices get more computing resources and browsers get more resource efficient, do you think we will ever reach the point when it really does make sense to write all mobile applications except heavily computational ones (photo editing, games with cutting edge graphics) in HTML5 + Javascript instead of native applications? Or in other words, do you think the concepts Mozilla is trying to promote with Firefox OS will ever take off, even if Firefox OS itself is dead in the water?

[Eric Elliott]

Michael Swierczek wrote:
1. The book title implies the book is oriented towards building applications. But the table of contents - asynchronous operations, functional programming, interfaces, lambdas, etc... looks like more than half is just dedicated to the Javascript language itself. I don't see that as bad, I'm just asking whether the book is really half learn Javascript and half learn how to make non-trivial Javascript applications.

The first half is about modern JavaScript programming techniques. The second half is about organizing modern JavaScript applications, and walks the user through the process of building an application with Node / Express on the back end, and Backbone / jQuery on the front end.

2. Does the book walk through building one particular sample application as an example, or is it broken into a few sample applications? Or does it not work that way, and all of the sections have examples isolated from each other?

There are lots of tiny samples to explore building-block concepts, interspersed with a sample application build that brings it all together.

3. I'm just curious, given your expertise in Javascript, what you think of Typescript (Microsoft's open source superset of Javascript that includes type parameters and a class and module system), or the languages that compile into Javascript, like Dart, Coffeescript, or Clojurescript. Are you satisfied with working in raw Javascript, or do you have a favorite path forward that you believe would work best to make the language easier to use for complex applications?

The primary goal of Typescript as I see it is a little at odds with the spirit of JavaScript, which has a flexible type system. Sometimes it is useful to set the type of a thing, and always be sure that it is what you want it to be. For that, a pre-defined type does make sense. I'm not convinced that TypeScript's approach is the answer, but I'm very glad that Microsoft is experimenting, and if that experiment gains momentum, maybe we'll see some of the ideas come into the language itself.

I do have a gripe about TypeScript - Microsoft presents it as something that people should be using instead of JavaScript, rather than as an experiment that gives people access to exploratory concepts of what JavaScript could become. I'd prefer it if it was framed more to help the language evolve, rather than as a compile-to replacement for JavaScript, proper.

The premise of the language is that JavaScript is not capable of rich tooling without something like TypeScript. I think that Tern has officially proven that thesis wrong. Always bet on JS.

4. When I'm reading someone's work, it helps me to understand their approach if I know what other areas of study and programming languages they know and like to use. (e.g. Larry Wall, creator of Perl, is a linguist. Martin Odersky, who created Scala, worked on the Java compiler at Sun and helped design Java generics. etc...) So... if you like, please inform us of your background and other languages you like to use, if any.

I started with BASIC when I was five years old, and progressed through machine language (programming directly in hex), assembly language, pascal, C, C++, delphi, Java, perl, and finally JavaScript. I learned a little Lisp for computer aided drafting / scripting 3d models, and experimented with Haskel. In the course of my work, I've had to dip my toes in PHP and Ruby, but I wouldn't say that I know either of those, or that they have influenced the way that I think about programming.

5. As mobile devices get more computing resources and browsers get more resource efficient, do you think we will ever reach the point when it really does make sense to write all mobile applications except heavily computational ones (photo editing, games with cutting edge graphics) in HTML5 + Javascript instead of native applications? Or in other words, do you think the concepts Mozilla is trying to promote with Firefox OS will ever take off, even if Firefox OS itself is dead in the water?

I think eventually, even heavily computational ones will be done in thick/thin client fashion, where cloud storage, collaboration, and computing resources are available when you're online, but the apps are still functional when you're offline. I know it's sometimes hard to imagine high-powered mobile devices, but look how far they've come just in the last few years. In five more years, the smart phones we're carrying now will look like dinosaurs. Today's low-end smart phones will be the primary internet and communication access mechanism for much of the third world. The average middle-class American family will be carrying around phones every bit as capable as the laptops we are using today -- maybe more capable. Moore's law is alive and well.

With today's deeply integrated auto-update features in the browsers, a cell phone in five years will be mostly a browser device, and most of the native functionality of the phone will be exposed to JavaScript in the browser. We're already trending there, and there's no reason to think that trend is going to change. Just have a look at the different mobile browser version results on RingMark. In terms of graphics capabilities, FireFox is really doing some groundbreaking stuff, and I'm sure a lot of that work is going to spread quickly to their mobile browser and OS, so even rich, immersive HTML5 / WebGL based gaming is going to be possible on mobile devices.

The future for mobile technology in the browser is bright.

[Michael Swierczek]

Thanks for the detailed response. Cool.

At my day job I work primarily with Java, and I've been at that long enough that I'm strongly in "the grass is greener on the other side of the fence" mode. With that disclaimer out of the way, I think maybe the type system in Clojure or Perl6 might be good: you can specify the type parameters if you want, but the code usually runs fine without them (unless you've made a type-related error). It's an optional help.

That programming background is impressive. I know very little about writing software before college, and I didn't move past "learning just what I need to know for my software developer job" until I was almost 30. Now I'm trying to be highly skilled and having a lot of fun learning - but it's a little discouraging when I meet people who could probably code circles around me at my current mid-30s best before they were finished puberty. My oldest kid is nine, and I'm trying to make writing software interesting for him but I can't get him much past "Hello World" before his mind wanders. It's a credit to you and probably to whoever raised you that were you playing with Basic by age 5.

With respect to mobile browsers and the future of mobile applications, I agree with you. I realize simple benchmarks leave a lot of details missing, but if you look at "The Great Computer Language Shootout" benchmarks, the V8 Javascript engine is within 2x of C++ times in some benchmarks, 2x of C++ memory use in some, and no worse than 20x of C++ by either metric in any of the eight mini benchmarks. That's astonishing - especially when you consider how much more rapidly you can write an application in Javascript versus C++.

[Eric Elliott]

Michael Swierczek wrote:
At my day job I work primarily with Java, and I've been at that long enough that I'm strongly in "the grass is greener on the other side of the fence" mode. With that disclaimer out of the way, I think maybe the type system in Clojure or Perl6 might be good: you can specify the type parameters if you want, but the code usually runs fine without them (unless you've made a type-related error). It's an optional help.

I'm with you.

My oldest kid is nine, and I'm trying to make writing software interesting for him but I can't get him much past "Hello World" before his mind wanders. It's a credit to you and probably to whoever raised you that were you playing with Basic by age 5.

I got interested because of video games. I was obsessed with them, and I wanted to make my own, even at a very young age. I got a thrill out of making text adventure games. I was learning to read and write, and making games that resembled Adventure (Colossal Caves), only with a lot more animals (cats and dogs at first, because they were easy to spell).

These days, kids seem to be getting excited about games like MineCraft, or even hardware programming with Lego Mindstorms.

Games like Light Bot may engage them for a while, too (warning, annoying ads).

TeachKidsToProgram.com may have some interesting things.

They're never too young to get them started on web technologies.

One thing that I think made a difference for me -- when I was a kid, almost every computer available booted up into a programming environment (generally BASIC). I don't think modern web browsers are very far detached from that, but definitely show them how to get to the JavaScript console. Have node installed, and teach them how to start it. Maybe they'll fiddle with it when they're bored with other things.

- Eric

[Michael Swierczek]

I guess it's not surprising you would list the "Teach Kids to Program" site. I actually have three of the five books they display on the main page, and I'm working through the first one with my two older kids. It's slow going, because they get bored pretty quickly and I don't want to kill any interest by forcing them.

But I will put Lego Mindstorms on my holiday shopping list, and see if I can get them to play Light Bot. Thanks for the suggestions!

HTML and CSS for babies looks cute, but I have enough nerd paraphernalia at the house.