In the last three years, frontend development has evolved very quickly. With all this stuff out there (react, angular.js, aurelia, redux, flux, Angular2, Rx.js, falcor…), it became really hard for developers and companies to make choices about the stack to use for their applications.
As a developper, I keep asking myself, which technology I’m gonna learn next ? and as a lead developper I often ask myself which technology I’m gonna use for this project : stability and quality VS technical debt ? This may seem really frustrating at first but I think all these choices are a good thing. Let me explain.
The PHP experience
Let’s make a small retrospective of what happened in backend development and transpose that to frontend.
1- Some years ago, we all started (At least me :P) by developing applications from scratch with really ugly code that looked like this.
<html>
<body>
<?php $sql = mysql_query('SELECT * FROM table');
while($row = mysql_fetch_array($sql)) { ?>
<strong><?php echo $row['column']; ?></strong>
<?php } ?>
</body>
</html>
2- We then used some abstraction libraries (say PDO) but still really ugly.
<html>
<body>
<?php $query = 'SELECT * FROM table';
$sth = $db->query($query);
$result = $sth->fetchAll();
foreach($result as $row) { ?>
<strong><?php echo $row['column']; ?></strong>
<?php } ?>
</body>
</html>
3- Then we found ourselves repeating the same code over and over again with little changes. So came the FRAMEWORKS (symfony, Zend Framework, Cake PHP …. I’m talking about you) and our code looked a lot better (MVC etc…)
<?php
// actions.php
class myActions extends sfAction {
public function executeQuery() {
$this->result = TablePeer::doSelectAll();
}
}
<?php // querySuccess.php ?>
<html>
<body>
<?php foreach($result as $row) : ?php>
<stong><?php echo $row['column']; ?></strong>
<?php endforeach; ?>
</body>
</html>
4- And to avoid reinventing the wheel, again and again we started having a lot of libraries. We kept our framework and used Propel or Doctrine as an ORM, twig as a template engine, etc… so came dependency management (welcome composer) and frameworks V2 based on libraries and components (Symfony2, Zend Framework 2, Laravel…)
5- Now, you may think : this is good, let’s stick with it. Well, that’s not what happened !!! We had other problems, our applications became bigger and bigger, and hard to maintain and we were stuck with our frameworks so we thought
There’s is this new trend, they call microservices, Why don’t we try it ?
So we broke our applications into smaller parts and started using micro-frameworks (Silex, Slim…). We also dropped the UI to these hipsters we call frontend developpers.
What about the frontend guys ?
1- Well, the story started pretty much in the same way for them. They wrote really bad code, the only difference was that they hadn’t much work to do, all they did was adding some animations and styling to the backend’s work. It looked like that.
var myLink = document.getElementById('link');
var input = document.getElementById('input');
myLink.onClick = function() {
if (input.value) {
input.style.background = “red”;
return false;
}
}
2- Then they used some abstraction layers. They also discovered that they can help backend guys thanks to XHR. So they used jQuery and their code became :
$('#link').click(function(event) {
if ($('#input').val()) {
event.preventDefault();
$('#input').css('background', 'red');
}
$.ajax('/backend', {
success: function(data) {
$('#result').html(data);
}
});
}
3- This kind of code last a long time but some revolutionary guys which were bored doing nothing decided it was time to work a little bit and handle all the UI thing, so came the FRAMEWORKS (Ember.JS, Angular.JS).
// controller.js
function MyController($http) {
$http.get('/backend/api').success(function(data) {
this.result = data;
});
}
<!-- index.html -->
<div ng-for-each="row in ctrl.result">
<strong>{{ row.column }}</strong>
</div>
4- Then started the world frontend war (or maybe a little before 3), everyone wanted their framework, or library. And thanks to dependency management (hi Bower, Npm… !!), they started using libraries for a lot of things (underscore, moment, bootstrap, RX, React etc…) and like the backend frameworks came the V2 of the frontend ones based on libraries and “module components approach” (Angular2, Ember2)
5- Now, you may think this is good and they will stick with it. Well, that’s not what happened (and will happen) !!! They had other problems, their applications became bigger and bigger, and hard to maintain and they were stuck with our frameworks so they thought.
There’s is this new trend, they call reactive programming, Why don’t we try it ?
So they broke their applications into smaller parts : Something for handling data (redux, RX, falcor), and something for rendering data (react, riot, deku, vue.js, cycle.js, web components ….) and may be another library for routing (router5, pathjs, riot/router …).
Conclusion
That’s what makes me say, having all these small libraries is a good thing. Like backend services, we can have multiple frontends using smaller libraries doing one thing and doing it well.
What about these questions we were asking ourselves, about which library or framework to choose ? Well, it’s not so important, start with designing your application and then choose a library for each part of your design. And If you want to change a library, you could just drop it and take another one.
What is still missing for frontend applications is something light that eases linking this different layers together, don’t you think ?