Build a web app fast: Python, HTML & JavaScript resources

Wanna build a web app fast? Know a little bit about programming but want to build a modern web app using well-supported, well-documented, and universally accessible languages? You’ll love these Python, HTML/CSS, and JavaScript resources.

I’ve been sharing these documents with friends who ask me, “I want to start programming and build a web app, where do I start?”. These resources have also been useful to existing programmers who know C, C++ or Java, but who want to embrace dynamic and web-based programming.

Python Resources

Python is the core backend and web programming language used at Parse.ly. It also happens to be a quickly-growing language with wide adoption in the open source community, and it is a very popular choice for web startups. (Update from the future in 2021: Python rose to the #1 spot in a popular programming language index; it’s safe to say it is now one of the most widely-used languages across all use cases.)

I’ve written a blog post with some original materials for learning Python, import this — learning the Zen of Python with code and slides.

This is a good starting point, but you may also find these resources very helpful:

  • For absolute beginners, “Learn Python the Hard Way”. This teaches Python using a series of programming examples, but it really assumes you have no programming background whatsoever. After going through the examples in LPTHW, it may be a good idea to supplement your understanding with Think Python.
  • For existing programmers, “Dive into Python 3”. This teaches Python from the starting point that you have already programmed in a mainstream language like C or Java, and want to know what makes Python really cool. Similar audience to my “Zen of Python” slides. At this point, you may be curious about whether to learn Python 2.7 or Python 3; the quick answer is that Python 3 is preferred. See Python2orPython3 on Python wiki to see the differences.
  • For advanced programmers, “Python Essential Reference, 4th Edition”. Unfortunately, this book costs money, but it’s basically the best book on Python on the market, and it’s very comprehensive for Python 2.7. But it’s very dense and weighs in at 717 pages, so this is only for those who want to go deep on Python. (Update from the future in 2021: The author of “Python Essential Reference” has released an updated rewrite of his book, that shrinks its size and focuses on Python 3, which is called Python Distilled. Give that one a try if you want to skip over Python 2.7!)
  • For cheap advanced programmers, “Official Python Tutorial”. Though the Python tutorial doesn’t have the best narrative style nor the best real-world examples, for advanced programmers, it will teach the reality of the language in a comprehensible way. And it is kept up-to-date with new Python releases. And, it’s free.

HTML/CSS Resources

In order to build up web applications, you’ll need to write your front-ends in HTML and CSS. These technologies have evolved over the years, but the basic principles remain from when they emerged nearly a decade ago. HTML is the markup language of the web, and you’ll see a lot of tutorials refer to HTML4, which is basically the markup standard all web browsers and websites work off. Don’t be confused by the HTML5 moniker, which often refers to much more than simply the markup — usually, it’s referring to a set of JavaScript APIs that are becoming standard in browsers, along with enhanced audio/video support and a few new “semantic markup” tags that have been added.

Since HTML is basically useless without CSS, you can get by with a short tutorial on HTML and then more advanced tutorials on CSS styling. Here’s what I recommend.

Learn the basics of HTML from MDC’s Introduction to HTML and Wikipedia’s page on HTML. This is a rare case where using Wikipedia is actually a perfect way to get the right background because half the battle with understanding HTML is understanding its history.

An excellent new guide to HTML & CSS together has been published by Shay Howe in 2013.

These look like a great first stop.

You can also use these dedicated resources for CSS specifically:

  • For absolute beginners: Use W3C’s official tutorial on Starting with HTML + CSS. This was written all the way back in 2004, but provides the basics with screenshots and real code examples, so is a great way to get started.
  • For existing programmers: Mozilla has done a great job putting together a quick and readable tutorial that gives you the basics at a glance.
  • For advanced programmers: You’ll want to buy the best book on the subject, CSS Mastery. It has the best explanation of the box model and browser rendering engine’s that I’ve seen, and covers all the edge cases nicely.
  • For cheap advanced programmers: You’ll need to look over the MDC (Mozilla) CSS Reference. Pay particularly close attention to articles on the Box Model and the Visual Formatting Model.

JavaScript Resources

Aside from Python, every Parse.ly engineer also knows JavaScript, even if it is only begrudgingly. For better or for worse, JavaScript has become the world’s most popular programming language.

JavaScript is definitely the language of the web. It is also a language that has, over the last few years, developed a nice bit of great documentation for learning the language. Here are some resources you can use to get up to speed:

  • For absolute beginners: “Eloquent JavaScript” introduces you to both modern programming techniques and JavaScript at the same time. It is thus a great book for beginners. There is also a print version available.
  • For existing programmers: The Mozilla Developer Network (MDN) contains the web’s best and most official documentation of HTML, CSS, and JavaScript. This guide, “A Re-Introduction to JavaScript”, presents the language to an audience that already knows how to program, and focuses specifically on the “gotcha” parts of the language.
  • For advanced programmers: A must-read is the short (but costly) “JavaScript: The Good Parts”. Douglas Crockford basically reintroduced the world to JavaScript as a modern programming language. He is a bit of a curmudgeon when it comes to programming style, but this makes sense since he is also the author of JSLint, an important tool used in JS development for static code checking.
  • For cheap advanced programmers: Douglas Crockford, author of the above “Good Parts” book, has also given a series of public video lectures on JavaScript at Yahoo! headquarters. These are freely available online and actually present much of the same content in “Good Parts”, just in a condensed form. Warning for the cheap: though the videos are very good, the book goes into more depth and spends less time on the history of the language. Also, Matt Might’s JavaScript, Warts and workarounds is an excellent summary to some of the most important “bad parts” of JavaScript.

JavaScript “frameworks”

Though knowing JS is important to do anything web-facing, you can also leverage some frameworks to help you out. The ones I recommend are the venerable jQuery JavaScript library and the Twitter Bootstrap HTML/CSS/JavaScript components. See:

jQuery adds common utilities for DOM manipulation, HTTP/JSON server requests, basic animations, and dynamic CSS.

Bootstrap builds on jQuery and adds a common, simple UI component library using pure HTML, CSS and JavaScript. This provides a grid system for layout; nicely-designed stylesheets for typography, tables, lists, and buttons, plus JavaScript components that add dynamic behavior such as tabs, dropdowns, modal dialogs, navigation bars, and more. (Update from the future in 2021: As of Bootstrap 5, it’s no longer required to use jQuery with Bootstrap, but it’s still perfectly well-supported, so feel free to do so!)

2018 note on JavaScript frameworks

This post was originally written in 2012 and updated over the years. I have made a strong effort over the years to ensure the suggestions in this post are timeless and work well regardless of when you are beginning your journey of learning web development.

2017-2018 was an inflection point for JavaScript frameworks in the open source community. You will read a lot in modern tutorials saying that, instead of jQuery and Bootstrap, you should use something like React or Vue.js. If you are an HTML, CSS, and JavaScript beginner, I strongly recommend against this.

These frameworks are complex, even for advanced programmers like me. They are primarily built to support a style of web development known as Single-Page Applications. This is an important frontend development practice and will be increasingly important as more and more web applications are built, but it won’t replace web sites. SPAs are overkill for building simple web sites and web applications. And, they are hard to learn for beginners.

If you move on from making websites to making full-fledged web applications, there will be a straightforward level-up path, and you won’t have wasted time learning about how HTML, CSS, and JavaScript work. Especially for making basic websites with dynamic behavior, it’s still extremely common to use “simple” JavaScript with jQuery and Bootstrap, and those sites are easier to reason about, to test, and to deploy. Don’t be confused by the modern tutorials that send you down the SPA rabbit hole.

One other 2017-2018 concern related to this regards which version of JavaScript to use on modern websites, to ensure good browser compatibility. The 2018 browser compatibility picture is much better than the 2012 one. However, the 2018 recommendation is to use a version of JavaScript known as “ECMAScript 5” (ES5), whose browser compatibility is summarized here. Essentially, ES5 is supported in Microsoft Internet Explorer 11 and later, as well as every other major browser platform (Chrome, Safari, Firefox, etc.) Thanks to a patch that Microsoft released in 2016 that urged IE8, IE9, and IE10 users to upgrade to IE11, that is the only “old browser” you likely need to worry about. Meanwhile, Microsoft is also pushing its users in the direction of its more modern browser engine, Microsoft Edge, which is the default browser of Windows 10 and Windows 11. (Update from 2021: IE11 will likely be a thing of the past in mid-to-late 2022, since Microsoft has announced that “the Internet Explorer 11 desktop application will be retired and go out of support on June 15, 2022”.)

Versions of JavaScript that were released in the 2010s — which go by the monikers like “ES6”, “ES2016”, and “ES2017” — should only be used if you use a Babel build toolchain, which is beyond the scope of this article. (Update from the future: If you are interested in a tangent on this topic, you can check out my other post, “JavaScript: The Modern Parts.”) This is because JavaScript, as a language, is now evolving with annual releases, without any consideration for backwards compatibility to older browsers, except insofar that those browsers can be targeted via a code translation technique known as transpilation. However, if you use the new features without this toolchain in place, you will write code that will break on a large percentage of your users. So, you can safely stick with ES5 while you’re still in learning mode.

Continue reading Build a web app fast: Python, HTML & JavaScript resources

Clojure as a mind expander

I made one of my New Year’s resolutions for this year to teach myself Clojure in my spare time. There were a few reasons for this. First, I realized this year that I have been dabbling and/or programming for nearly a decade, with Python as my preferred language throughout that time period.

Python is an unbelievable language. What astounds me even more is that it is still improving. Python 2.x/3 and the entire open source community of library implementors that surround it are bringing more and more useful utilities into the fold of the language. It has stood the test of time in a serious way. It has proven that simpler languages can be better. Personally, it has served as my salvation from the tar pit that is the Java ecosystem.

Continue reading Clojure as a mind expander

Fully Distributed Teams: are they viable?

It has become increasingly common for technology companies to run as Fully Distributed teams. That is, teams that collaborate primarily over the web rather than using informal, face-to-face communication as the main means of collaborating.

This has only become viable recently due to a mix of factors, including:

  • the rise of “cloud” collaboration services (aka “web 2.0” software) as exemplified by Google Apps, Dropbox, and SalesForce
  • the wide availability of high-speed broadband in homes that rivals office Internet connections (e.g. home cable and fiber)
  • real-time text, audio and video communication platforms such as IRC, Google Talk, and Skype

Thanks to these factors, we can now run Fully Distributed teams without a loss in general productivity for many (though not all) roles.

In my mind, there are three models for scaling number of employees in a growing company in the wild today. These are:

Continue reading Fully Distributed Teams: are they viable?

Speed and lightness

Last week, I decided to give myself the present of a Plextor M3 512GB SSD drive, which was available at a nearly 25% discount on NewEgg for a limited time.

The price-per-gigabyte for SSDs has finally fallen to nearly $1/GB, and the rewrite cycle problems that used to afflict these drives is now becoming a non-issue with the Linux kernel’s TRIM implementation and the updated firmware on these drives.

So, I took the plunge. My main development workstation was a Thinkpad T400, maxed out to 8GB of RAM, and with dual 500GB platter drives (via Thinkpad’s excellent Ultrabay extension). I was running Ubuntu 10.10 for a long time. I timed the SSD purchase with the release of Ubuntu 12.04 LTS — 10.10 no longer being supported, I figured I’d do a clean install on the new SSD and clean up my development workstation for the first time in a couple of years.

A couple of things occurred to me in this process. First of all, since 2009, I have moved more and more of my data into cloud services. I have moved the lion’s share of my “business and personal documents”, including photos, into Dropbox with my 50GB account. And I have moved my truly old files and digital keepsakes into NAS drives that I host in my little server room at home.

Continue reading Speed and lightness

On multi-form data

I read an excellent debrief on a startup’s experience with MongoDB, called “A Year with MongoDB”.

It was excellent due to its level of detail. Some of its points are important — particularly global write lock and uncompressed field names, both issues that needlessly afflict large MongoDB clusters and will likely be fixed eventually.

However, it’s also pretty clear from this post that they were not using MongoDB in the best way. For example, in a small part of their criticism of “safe off by default”, they write:

We lost a sizable amount of data at Kiip for some time before realizing what was happening and using safe saves where they made sense (user accounts, billing, etc.).

You shouldn’t be storing user accounts and billing information in MongoDB. Perhaps MongoDB’s marketing made you believe you should store everything in MongoDB, but you should know better.

In addition to that data being highly relational, it also requires the transactional semantics present in mature relational databases. When I read “user accounts, billing” here, I cringed.

Continue reading On multi-form data

Computer Science and “soft” skills

My friend Jennifer Anyaegbunam (@JenniferAdaeze) has published a new piece on HuffingtonPost about the role of humanities in medical education.

Matriculating into medical school, we were proud of our humanities roots and felt it made us uniquely poised to become great clinicians. Yet, we have often found that we have had to defend our educational choices to interviewers, advisors and even our peers– something science majors rarely, if ever, have to do. This is because the medical humanities is often regarded as a “second tier” or an extracurricular interest and not something that is fundamental to the practice of medicine.

She finds that the humanities are derided in a classroom setting, as well:

Courses on ethics and social science are few and far between. To make matters worse, students often do not take these exercises seriously, and these courses are often the ones with the poorest attendance, for example

Here, I’ll offer a parallel from a different field: computer science.

As a computer science major at NYU, I too encountered hostility and a dismissive attitude toward the humanities and other “softer” fields from my peers.

A traditional computer science curriculum consists of mathematics, algorithms, and theory. These are important areas of academic interest, and provide a good foundation for thinking about the deepest problems surrounding computation. But the vast majority of computer science majors don’t go on to research computation. They go on to practice it — by becoming software professionals (programmers), writing applications used by real people.

It turns out that to be a successful software professional, you need much more than a computer science background. Indeed, many of the world’s most successful programmers have no computer science background at all. My father was a software professional, but when he graduated from college, computer science did not even exist as a field of study!

You need software design skills, which are often not taught except in a trivial way in traditional curriculums. It is considered “vocational”. You need communication, management, and product design skills. These are too “soft” to be taken seriously.

The industry suffers from a widespread lack of these skills.

Continue reading Computer Science and “soft” skills

Getting real about design inspiration

So, here’s the deal. Some startup founders at Curebit.com decided to copy a design used by 37signals’ Highrise product for their own app. They did this in a less-than-gracious way, by simply copy/pasting the code and even leaving in some hard links to the original code. The story on VentureBeat tells the full story.

The founder of Curebit responded on HackerNews with this:

We had a different homepage, were a/b testing different pages, came across the 37signals post and were like ‘wow we should see how that converts!’ We are big fans of rails and what 37signals is doing and did not really think through the implications of what we were doing. We just kind of thought about it as a fun test to run.

Clearly it was stupid. It was not meant to offend anyone and we are adding credit where due.

As I pointed out to @dhh on Twitter, it’s unlikely this explanation is actually valid, given that their pricing page is also basically identical to Basecamp’s.

Clearly, @dhh isn’t amused with the founder “digging deep” for excuses. He wrote:

@allangrant THERE IS NO VALID WAY TO RIP-OFF PEOPLE’S DESIGNS AND HAVE IT BE OK. Not we’re small, not we’re a/b testing.

I think @dhh’s real frustration is that the founder isn’t admitting what is obvious to everyone else. He liked 37signals’ design. He thought it was good. And rather than get inspired by it and design something derived from the good concepts in the original, he and his team simply ripped off the original.

I think what this whole argument is missing is a little honesty. The truth is, no one on the web designs in a vacuum. We are all continually inspired / deriving from each other. If we were to believe that every marketing page and product homepage were designed by an obsessed designer living in an ivory tower, we would be in a total fantasy land. That’s not the web. Even designers are borrowing from, and getting inspired by, each other. Hell, that’s half the point of a site like Dribbble or Forrst.

Continue reading Getting real about design inspiration

XDDs: stay healthily skeptical and don’t drink the kool-aid

On my LinkedIn profile, I list one of my skills as “thought-driven development”. This is a little tongue-in-cheek; software engineering over the last few years has developed a lot of “XDDs,” such as test-driven development, behavior-driven development, model-driven development, etc. etc.

“Thought-driven development” doesn’t actually exist, but by it, I simply mean: perhaps we should think about what we’re doing, rather than reaching for a nearby methodology du jour.

In my last job, a colleague of mine used to also joke about “design-driven design” — perhaps the ultimate play on the XDDs since it is also a strange loop.

All this is not to say the XDDs aren’t useful — they definitely are. A lot of them have spawned entire groups of cross-platform open source projects. I am all for anything that makes the adoption of XYZ best practice easier for my team. But these techniques often require some lateral thinking to get to any real benefit.

When evaluating technologies like this, you have to take each little community with a grain of salt. Almost every programming framework / methodology / etc. that exists portends to offer some order of magnitude increase in software reliability / developer productivity / whatever else. And almost all, if not all, fail to do so, in practice.

Here is one anecdote to illustrate the point. From 2006-2008 at Morgan Stanley, the entire corporation was obsessed with Java’s Spring framework and its core “architectural pattern”, Inversion of Control. I can’t even begin to explain to you the number of man-hours that were wasted re-architecting existing, working software to meet this chimerical conception of component decoupling. I even contributed to this, urged by the zealots and their blind faithful. All of the reasons seemed great: decoupling code, using more interfaces, allowing for easier unit testing, being able to “rewire dependencies” and use fancy technologies like “aspect-oriented programming”.

Even Google got swept up in the madness and developed their own, competing framework called Guice. And in the end — after all that work — my diagnosis is that IoC is basically a non-starter, a complete waste of time.

A complicated framework that morphed into a programming methodology, developed exclusively to work around some annoying limitations of the Java language. Since it was applied without thinking, now everyone’s Java code has to suffer, and you can hardly pick up a Java web application today without being crushed by the weight of its IoC container’s XML configuration files. (Nevermind that most other communities, such as Python’s and Ruby’s, have hardly a clue what IoC is all about — a good enough indication that it is a waste of time.)

Every framework and approach should be judged on its true merits, that is the true cost/benefit analysis of applying that particular technology. Will it save us time? Will it simplify — not complicate — our code? Will it make our code more flexible / adaptable? Will it let us serve our users and customers better?

I regularly go back to old classics like the Mythical Man-Month to remember that nothing we do in software is truly new. I highly recommend you read it, and also its most famous essay, “No Silver Bullet”.

tl;dr stay healthily skeptical, don’t drink the kool-aid.

8 years ago today, I wrote this in a bug report

Me: Thanks so much for your fix to my issue. My friend, who majors in business, once told me that I should no longer major in Computer Science because “programming is like banging your head against the wall repeatedly, but with less reward.” I find that to be a rather rash dramatization, but I know in dealing with bugs as subtle as these it may feel that way. I hope at least the end-result is rewarding for you.

Programmer: Are you a Computer Science major? If so, don’t let your friend discourage you. Just ask him about “head banging” when those business majors find that their product development and marketing efforts fail to work after spending millions of dollars.

Me: Yes, I’m a CS major. And you’re right — the reward is great in software, and the cost of building an useful product is relatively minimal. That is one of the reasons I chose this path. It’s why I love helping out honest, intelligent developers such as yourself in any way I can. I have found that hardworking CS majors who are not only better programmers, but more often than not better thinkers and better managers — if you’d give them the chance. I am happy in my decision, and still have that naivete that perhaps I can change the industry a bit, shake things up, come up with an idea that changes everything, innovate in whatever way I can. Big aspirations; we’ll see what happens. For now, I’ll just keep respecting the good software I find in the world, such as yours.

Wall Street (the movie), 25 years later

I recently watched Oliver Stone’s Wall Street again. It really is amazing how relevant this movie is in 2011, ~25 years after its original release in 1987.

This speech, in particular, is a knockout, given the recent Occupy Wall Street movement:

Bud: How much is enough, Gordon? When does it all end, huh? How many yachts can you water-ski behind? How much is enough, huh?

Gekko: It’s not a question of enough, pal. It’s a Zero Sum game – somebody wins, somebody loses. Money itself isn’t lost or made, it’s simply transferred – from one perception to another. Like magic. This painting here? I bought it ten years ago for sixty thousand dollars. I could sell it today for six hundred. The illusion has become real, and the more real it becomes, the more desperately they want it. Capitalism at its finest.

Bud: How much is enough, Gordon?

Gekko: The richest one percent of this country owns half our country’s wealth, five trillion dollars. One third of that comes from hard work, two thirds comes from inheritance, interest on interest accumulating to widows and idiot sons – and what I do, stock and real estate speculation. It’s bullshit. You got ninety percent of the American public out there with little or no net worth. I create nothing. I own. We make the rules, pal. The news, war, peace, famine, upheaval, the price per paper clip. We pick that rabbit out of the hat while everybody sits out there wondering how the hell we did it. Now, you’re not naive enough to think we’re living in a democracy, are you, buddy? It’s the free market. And you’re a part of it.

Watch the full speech on YouTube here.