I’ve never enjoyed writing web apps. For a variety of reasons, the experience of web development (and even the end-user experience) has always felt frustrating and wrong. Thankfully, the world of web development hasn’t been standing still. Web standards continuously improve and gain adoption, while truly great frameworks have come into existence. What I’ve been realizing lately is that I no longer loathe working on a web application – I’m actually rather excited to.
Let’s take a look at why.
Transition to the Client Side
The most viable way to develop web applications has been to use a framework like Ruby on Rails. I absolutely can’t knock Rails, as it’s really well-engineered and well-suited to the workflow it was designed for. It has a great community (with a focus on clean, tested code) that has built a lot of useful infrastructure that will allow you to productively develop quality software.
Nevertheless, I do have a problem with the fundamental model that Rails is built on: achieving each interaction through the application by requesting the server template and generate a new page.
This design is slow and inherently harms the user experience. You can ameliorate the pain by sprinkling in some jQuery and asynchronous requests to the server, but then you have a new problem: you need to duplicate logic and potentially even your templates across both the server level and the client browser. And, often, the tools you’re using on the client side aren’t up to par with the ones you’re using on the server.
Over time, I’ve seen a clear trend of pushing more and more over to the client, with frameworks like Backbone.js, but now we’ve reached the logical conclusion — frameworks like Ember.js that allow you to build and manage the state of the user interface entirely on the client side.
This is wonderful. Not only does it save you from duplicating logic and DOM structure in your code, it allows for better tools for managing and updating the state of your interface, such as the way Ember handles data bindings and automatically re-renders your templates.
Standards Improvements / CSS Frameworks
CSS has a lot of warts. Some easy examples:
- Why can’t you nest style declarations?
- Why does adding padding expand the size of the box element?
- Why are multi-column layouts so hard?
Recently, however, we’ve begun to see two things happen. First, awesome tools like Bootstrap and Foundation have come into existence, giving you a nice framework with which you can easily accomplish complicated layouts that would have taken more time to do by hand. And then there are other tools like Sass to allow you to design more maintainable CSS.
Second, older browsers are dying off! We’re now finally hitting the point where we can take advantage of lots of improvements that were made to standards long ago. Want to use REMs? Why not. Sick of the default behavior of padding? The box-sizing property can help you, and it’s been supported in browsers for quite a while now.
When you add it all up, styling the UI for a web app isn’t so hard anymore. In fact, it’s starting to feel pretty easy and perhaps even fun.
New Server-side Languages & Frameworks
I like Ruby, and one thing I’ve long appreciated about Rails is the power of Ruby and how well it lends itself to programming in a functional style. However, now that the client is responsible for rendering its own view of data and managing user interactions, you have more flexibility in what tools you choose for the back end of your application.
Since you’re no longer tied to choosing a language or platform that’s well-suited to generating HTML/CSS, you can instead prioritize those that are more well-suited to other areas of your application domain. If it can output JSON data over HTTP, and is well-suited to your problem, why not use it?
Suddenly it becomes much more reasonable to write your backend in a hip functional language like Clojure, and that makes me happy.
Conclusion
With the combination of client side frameworks like Ember.js, improvements to and frameworks for CSS, and more freedom to choose tools on your backend server, I see a direct improvement in not only my happiness during development, but also in my ability to provide a high-quality experience to the end users of a project. Even better, it’s possible without compromising my productivity.
In the past, I’ve had a serious preference for doing native development because, for the most part, you’ve had better tools, better languages, and better APIs available to you. And the look and feel of the end product has been better.
What I see now is that the web is finally catching up, and it brings with it two really valuable qualities: wide “portability,” and the inability to be directly controlled or constrained by one organization.
I didn’t expect this to ever happen, but I’m starting to really enjoy creating web applications.