Lessons learned after three years
This is a guest post by Philip Johnson, Professor of Information and Computer Sciences at the University of Hawaii.
I have taught software engineering at the University of Hawaii for over 25 years at both undergraduate and graduate levels. As is typical for a software engineering curriculum, my approach mixes conceptual knowledge (software quality assurance, configuration management, testing, project planning, etc.) with practical experiences doing team-based software development. For many years, the practical side of the course involved a community project and I allowed students to pick their own technology stack.
Around 2010, I realized that the “choose your own technology stack” approach meant that students, instead of spending the final part of the course learning about software engineering, were instead spending the final part of the course learning the basics of how to use their technology stack. And since different groups were picking different technology stacks, and since they were left to their own devices for learning, this made the final part of the course somewhat chaotic and most final projects were unsatisfying.
So, I redesigned the course to integrate the learning of a single software development technology stack along with basic software engineering concepts. I chose web-based application development as the focus, and initially chose the Stripes web application development framework since it was Java-based, and my students all had a background in Java. In a subsequent semester I switched to Apache Wicket, and after that to the Play Framework.
My experience with the Play Framework was generally positive, with a few caveats. First, while it is possible to develop the business logic in Java, the user interface templates required basic knowledge of Scala. And, of course, any dynamic UI behavior requires a third language: Javascript. Second, wiring up the framework to a backend relational database is cumbersome, and most of my students did not yet have any relational database experience. Third, the amount of boilerplate code seemed high relative to, say, Ruby on Rails, which was extremely popular at that time. I didn’t want to switch to Ruby on Rails because I didn’t want my course to degenerate into a class on learning a new programming language (Ruby) and framework (Rails) which would swamp the true purpose of the course (software engineering).
In 2015, I discovered Meteor (then at version 1.0) while attending a Hackathon, and switched to it the very next semester. At that time, Meteor seemed to me to provide several compelling advantages as a technology stack for teaching software engineering:
- Just one language. Rather than Java+Scala+Javascript, or Python+Javascript, or YourFavoriteLanguage + Javascript, Meteor was just Javascript. I would have to spend a couple of weeks introducing JS at the beginning of the semester, but that seemed like time well spent for the students.
- Mongo, not MySQL. For students who haven’t yet had a database class, Mongo is way easier to get started with than a standard RDBMS. For example, there is no object-relational impedance mismatch, which bedevils students trying to build apps in Java and MySQL.
- Built-in accounts management. Getting accounts management “for free” eliminates a significant amount of boilerplate that students recreated (badly) every semester in every project.
- Simple, free deployment. In 2015, you could deploy your app to MDG’s servers with a single command, for free. This was significantly more simple than the Heroku-based deployments students used for Play applications.
- Discover Meteor. In 2015, there was an excellent, up to date, book-length introduction to Meteor that provided significantly more detail for novices than the short To-Do app tutorials now provided by MDG.
- Pub/Sub, not Request/Response. OK, to be honest, I was not sure that Pub/Sub would be any simpler to teach than Request/Response, but I thought it was a super cool idea and could be the future of web application client-server communication.
It’s now 2018, and I’ve taught the Meteor version of my class about six times to over 200 students. Here are five lessons I’ve learned from the first three years.
(1) Modern Javascript is a great language for teaching software engineering. Who would have thought that would be true 5 or 10 years ago? I even created a somewhat tongue-in-cheek screencast called 7 reasons why Javascript is better than Java and C++ to help my students (who came from one of those two backgrounds) better understand why Javascript is now more than just a “scripting language for web pages.”
(2) Meteor’s evolution since 2015 has made it a better framework for application development, but harder for novices to learn. In 2015, things were relatively simple: you put your code into the client/, server/, or lib/ directories; you used Blaze for your UI; and you went to Atmosphere for all your third-party needs. In 2018, you should use the imports/ directory, you need to choose between Blaze, Angular, and React, and NPM is preferred over (but does not replace) Atmosphere. Note that this velocity of evolution makes it much harder for novices to use Google to solve problems they encounter with Meteor; often the “solutions” presented do not reflect current best practices, even if they are only a couple of years old, and the Meteor Guide cannot cover every single problem a novice will encounter.
(3) The demise of Discover Meteor makes it harder for novices to get up to speed. I don’t know of any resource for current novices that provides the same detail about best practices as Discover Meteor did in 2015. Making Discover Meteor free, while admirable, does not solve the problem; too much of the book is out-of-date. If it could be made a community resource that complements the Meteor Guide and that could be kept up to date with current best practices, that would be a huge win for novices.
(4) Windows is not great for teaching Meteor. And most of my students use Windows. To be fair, Meteor is not alone with respect to this issue: Ruby on Rails is also somewhat Windows-unfriendly. But I have a few students every semester who come to hate Meteor simply because it is so slow and/or error-prone on their Windows laptop.
(5) React might be easier to teach novices than Blaze. After five semesters of teaching Meteor using Blaze, I switched to React this semester. Although I assumed React would be more complicated for students to learn, I felt that the ubiquity of React made it an important skill for students to acquire and worth the extra investment of time. To my great surprise, I am finding that React is potentially easier for students to learn than Blaze! To understand why, consider that when teaching Meteor using Blaze, the sequence of modules looks like this:
Basic HTML/CSS > Semantic UI > Basic Meteor + Semantic UI + Blaze
In other words, students have to intermix the learning of Blaze with the learning of Meteor, because Blaze does not exist outside of Meteor. Furthermore, using Semantic UI with Blaze creates additional complications (mostly around the need for JQuery for certain constructs).
Here’s how I teach it this semester:
Basic HTML/CSS > Semantic UI > Semantic UI/React > Basic Meteor
For a novice, this progression is easier to learn, because it’s possible to learn both basic React as well as the excellent Semantic UI/React framework before ever touching Meteor. Just as importantly, the Semantic UI/React framework not only eliminates the complications of Semantic UI with Blaze, it actually simplifies the use of React itself in many situations!
In summary, after three years of teaching Meteor, I still believe that it offers an excellent technology stack with which to introduce students to software engineering. I am quite hopeful that the rapid and sometimes disruptive evolution in design and architecture that Meteor experienced over the past three years will abate during the next three years, enabling the documentation of best practices to catch up. This, in turn, will make it easier to “on-board” novice developers such as those in my software engineering classes.
Teaching software engineering with Meteor was originally published in Meteor Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.