I like this idea a lot because it'll show them the value of thinking about the design and coming up with something that can be adapted and modified as new requirements come in. If you just do a series of unrelated challenges, then there won't be an incentive to come up with a good design that can last.
Pet peeve: We do lists with ordinal numbers [1], not natural ones. When you go to see what is the greatest movie of all time do you look to see which one is first or which one is "zeroth"? Anyone who picked the latter may have brain damage.
I interpreted the 0 as meaning “so trivial as to perhaps not be worth it, and therefore optional” – you can start at item 1 if you want. Or perhaps it meant “too obvious to mention, but mentioning it just in case”.
Javascript needs a lot of attention on its own since it has different best practices from other languages. At the same time, apps can be made more fun to play with if you know basic DOM manipulation. It will also be necessary to teach how to properly organize an ajax app (don't just send html or eval code, use json and separate concerns between client and server).
Quite true. If you approach javascript with the notion that it's fundamentally similar to C++ or Java then it will look like a crazy mutant language create by insane sadists. If instead you approach javascript on its own terms and understand its fundamentals and how to use it properly then you will be far less frustrated and far more satisfied with javascript as a language.
My advice is to start simple. Simpler than you'd think at first. The point is not to see if they can come up with something that looks good, but to see if they can build a reasonably-sized project to absolute completion, and leave it in a maintainable state. I would want to see something a student could leave feeling proud having built, something for which they'd want to upload the code to their github account and point to when interviewing later.
Therefore, I'd start with a blog platform. Doesn't need to be "full-featured" in any sense of the term, just as long as there's a reasonable (explainable is close enough) way for me to write posts (doesn't have to be part of the frontend), and the frontend is usable (there should be some kind of indexed archives). Comments would be nice, not necessary (no login system for commenting required, saving an email or some kind of identifier for the commenter is enough).
What's important is that the final application is robust and at least mostly secure. It's almost impressive how few "web programmers" can't put together a complete webapp without gaping holes (security, functionality, or otherwise). Lots of points would be determined by maintainability of the code, that is: was it well thought-out from the start? has the code been sufficiently refactored instead of just copied/pasted everywhere? are templates being used properly?
If someone implemented it cleanly without javascript (that is, when I click a link, even though it just fetches a new static page, it "feels" ajaxy, in the sense that large bits of UI don't change underneath). With javascript would just be sugar on top.
Beyond this, for adventurous students or those with lots of extra time on their hands, I'd ask for a simple facebook-style application. Something where I can log in (remember your security, folks!), form relationships with peers, and post some kind of content (either broadcast or directed at one user) is enough. Here I would expect some javascript as needed to make the UI feel snappier, though if the student could do without and still impress me, I'd be happy. Of course, javascript is a big part of webapps, so this "bonus project" would be a good place to demonstrate that.
Going farther, real-time chat would be my next task, but I really wouldn't expect undergraduates to be able to bring that to fruition in a semester.
If you want to build up a portfolio, I'd go with real-time collaboration a la Etherpad. Make it clean, and make the UI pretty. If you came to me with something like that I could play with for half an hour without finding any obvious bugs, I'd be extremely impressed.
For curriculum purposes, I'd go social. A FB-ish app doesn't involve huge amounts of wizardry, but it includes one of almost everything and it builds naturally. Start with static content (landing page, T&C, privacy, etc.) to demonstrate basic HTML document structure, CSS, and the value of server-side includes (DRY for HTML). Progress to signup/authentiction for a quick intro to database use and security. Build on that with user profiles, and add searching to create friends networks. There are a number of messaging contexts (to use FB terms, status, wall, and private messages) and response types (comments and message threads) and read/unread item management, all of which can be initially done with forms and server-side page refreshes. Finally, you can enhance with client-side activity (AJAX/AJAJ). Perhaps best of all, though, an app like that, poorly done, can lead to scalability problems even with a couple of dozen users on the sort of machine that is likely to be pressed into service as a server in a classroom setting (assuming, that is, that the students have a sandboxed server they can safely break now and then).
I'd make them build some sort of a web-based adventure/RPG game, for several reasons:
First, writing games is fun. Even the most boring programming task can be enjoyed if it's in the context of writing a game.
Second, RPG / adventure games are inherently stateful which makes using REST / MVC non-trivial. Still, most real world applications are stateful one way or another so it's a good way to get familiarized with these concepts (as well as related ones such as continuations) and the underlying problems.
Third, if you allow interaction between players they can gain some familiarity with social software.
Whilst I don't think this is a complete exercise, the coursework for one of my Uni modules is online and focused heavily on cross-browser JavaScript, XML/DOM manipulation and XSL.
It turned out that most of the class found this pretty challenging, and whilst it didn't include server side stuff which I thought should have been covered I also thought it wasn't a bad exercise given the time expectation associated with it (no more than 8 hours is expected for a piece of coursework like that).
When I was teaching myself web programming, I wrote a blog (in PHP), then an image gallery (in PHP), then somehow I landed a job doing PHP programming (back around 2000ish) and wrote a bunch of sites for them. Then I decided I hated PHP and went to Python, and that was where my fascination for static HTML generators developed. Now my website, blog, and photo gallery are all static HTML (apart from the ajax twitter-based comments), which I find pretty awesome, but not really that web appy any more :)
Anyway my point is, start simple but not too simple. A challenge is good. A blog system is a pretty good start, since it introduces the mainstays of web programming (databases, forms, comments, etc.). Instant gratification is good. Then let your students find something they want to build.
Assuming these students know how to build a basic web app using a javascript library like jQuery.
Project 1
html5 local storage /sqldb using javascript for the front end.
This is a standalone web app that supports touch interfaces and manages sql of the students choice in the browser storage. ie.. inventory db, profile db, tweet db something crud.
Project 2
Now build a server that supports basic user authentication and get ready to store your data from Project 1 in a sql db.
Project 3
Build Registration/authentication into Project 1 and support online/offline sql db w/ sync via web api
Consider that standard CRUD-based web apps follow a pattern: add, update, delete along with listing the data. For instance, a contact manager is a good way to work through all those pieces. I'd recommend getting that core pattern down before playing with extraneous stuff like image resizing or playing with REST/APIs.
I'm assuming that they already know how to program? Perhaps they could start with a simple user login/registration application. One of the requirements must be to use password hashing+salt for security. I think this is an essential lesson that all should learn. Too many web applications store passwords in plain text.
I'd split the semester into two parts -- one close to metal, something simple like a url shortner. Then something using an existing framework to build something more complex like a blog with an admin interface and some RSS feeds or JSON API.
super simple db app, write to the db, read it back out via query/get/request whatever
move to comments.
create a gallery, let them use a lightbox(instill in them the idea that they don't have to do everything from scratch, and that it is in fact stupid)
1. Simple link shortener (no accounts/logins, just store the links and do 301s)
2. Simple blog with HTTP basic auth on the admin
3. Update blog to have comments & true user accounts/logins for admin
4. Update blog to allow image attachments with a post and include the link shortener code (so every post has a short url)
5. Update blog to allow commenting and email the admin when a comment is posted
6. Something different–probably a simple forum or classified/ecommerce site that just uses paypal
7. Something dealing with external data/APIs