Building Web Apps
Most web-based products are made up of multiple apps. You can choose the right tool for the job.
A lot of discussions recently in the web development communities about what is the absolute best way to build web apps. And the general tone is that there exist one way for solving different classes of problems and apps on the web.
I approach this as I do any other programming problem. Break down the problem into smaller ones, repeat until satisfied, then solve each problem using the right tools for the job.
The most popular ways of building apps are:
- Traditional web app architecture. Where all HTML is rendered on the server and most actions by the user triggers a full page load. This is great for content heavy and minimal interaction apps.
- PJAX. Very similar to the traditional architecture but instead of triggering a full page reload on each action, AJAX is used to fetch the content from the server and PushState is used to update the URL. This is great for speeding up traditional web apps and adding a layer of more complex interactions.
- The SPA architecture. Where your business logic and data lives in the browser, which also renders your HTML. This is great for highly interactive apps (needing to give immediate feedback to the user).
As you can see, each web app architecture is best suited for certain types of problems. And the point I’m trying to make is you can easily mix and match tools to get the most optimal results in terms of:
- Usability
- Security
- Performance
- Programmer productivity
- Unicorns etc
Now, also not unlike other programming tools, each web app architecture has a level of expressive power.i.e. the SPA architecture can be easily used to build traditional web apps but not vice versa. So, why not build everything as SPAs?
Well, I can’t tell you what to do. But there is value in having a standard way and a consistent toolchain for building apps at your company or project team. However, there is also a level of added complexity that comes with SPAs. And the reason for that is because it’s based on relatively new technologies that are not as mature as the ones on the server side.
At Codecademy we’ve used all three architectures for different parts of the site. The highly interactive parts are naturally SPAs, for example our core learning app. Less interactive parts are either PJAX or traditional web apps, e.g. picking a track.
