The basic building blocks of the run-of-the-mill web application come down to:
- Something to store data
- Something to manipulate that data into meaningful pieces
- Something to show those pieces to something else
A simple example of how that could play out in terms of an end product could be:
- A regular old text file with the temperature recorded every hour
- A program that reads the file and finds the daily average temperature
- A graph of the daily average temperature for the last month
Unfortunately (or fortunately?), to satisfy those 3 simple tasks, there are a ridiculously intimidating number of technologies that can all kind of work together and but mostly generally not. Well, ultimately everything *can* work together, often it’s far more trouble than it’s worth. For a long time, The Answer was the LAMP stack. I think it’s safe to say that LAMP is relegated to maintenance work, with new projects being rare – mostly the product of people who don’t want to learn new technologies.
“Do I go the modular route and try React, or start erecting the Angular monolith? Is Sass better than LESS? Is HTML good enough by itself or should I use Mustache or Jade or Handlebars or… and what if I screw up?!”
The real kicker with these types of investigations is the overlap. It doesn’t really work to ask “Angular or React” in the same way you can ask “MySQL or PostgreSQL” – they do different things and satisfy different requirements, they just both happen to be popular. This can quickly overwhelm someone (e.g. me) trying to compare and contrast and end up with a defensible choice. Largely, I don’t think it really matters too much what you go with on the front end, as that landscape is shifting preposterously fast and virtually all choices are better than writing HTML and jQuery, which has done a surprisingly good job so far. Soon enough, my guess is the client side will mature a bit and we’ll see the same layering we’re familiar with on the server side – mobile apps seem to already be there. Persistent client-side storage, native computation power and responsiveness, while still serving highly dynamic content are all simply too compelling. The convergence of mobile applications and web is well on its way, as browsers are either the new OS, or OSs are the future of browsers or something.
So how do you start?
I think the best option here is to already have started. By that, I mean isolate the technologies that you’re most familiar with, so you can focus on building something you can actually think of as “done” at some point. If you try and learn everything about everything all in one shot, chances are (if you’re anything like me) that you’ll find yourself frustrated and give up. Do you know MongoDB intimately? Awesome, use it. Have you done extensive work with CSS and somehow managed to not have come across Sass? Don’t bother with it now. I’m a strong advocate for surging blindly forward when stakes are low and the threat of spinning your wheels investigating everything and producing nothing is high. Get *something* working end to end, then fan out and refine. This can also guide to to a particular set of technologies as well. Often frameworks are drawn to each other as people refine their development processes, so pick one that goes well with what you know. Perhaps even let whatever general purpose language guide you:
- Know Java or Scala? Check out Play Framework (side note, TERRIBLE choice of name, Googling for it is *so* much harder than it needs to be)
- Know Ruby? Check out Ruby on Rails
- Know Python? Check out Django
- Know Go? You’re cooler than me, why don’t you just go build your own