Backend is (or should be) quite mature. Even if there are still a lot of things to do, the principles and the tools are there to manage build and deployment process but also production follow-up and performance monitoring. It's just about implementing theses concepts and tools and/or applying them on your projects. We'll suppose now that your backend application is working fine or at least in a decent way.
So what about frontend side (ie what is in the browser ?) ?
A few facts about current situation :
- More than 80% of the time used to render a page is made on browser side ; so the counterpart is that 20% is made on backend side.
- Logic is more and more on client side with the rich UI we tend to have
- When you look at Amazon, a 1% increase in revenue for every 100ms of improved performance.
- You start to notice the application/web site is slow from a little less than 1 second
So don't you think it's time to invest on frontend side and stop considering that frontend code is just pushed/generated from backend side ?
It's not about focusing on performance. Performance is just a mean to deliver a good user experience and allow end users to use your service/site.
As such, Frontend developpers is not just about putting some HTML/CSS/JS alltogether and manage browser (in)compatibilities. It's even less about backend developers to generate the UI based on some auto-generated code derivated from some models and Java code. It is about to know/understand HTTP principles, how browsers render pages, what to do on backend side to improve frontend performance, etc. It's about going beyond the code to embrace the whole situation/context and deliver the expected UX.
How do we achieve this (non exhaustive list) ?
- 2013 was the rise of the "frontend tooling chain" with the coming of Bower, Grunt, Yeoman, etc.
- For years now we have performance tools like Webpage Test, YSlow, PageSpeed, etc
- Firefox and Chrome DevTools are here for years and were significantly improved over time ; not to mention Firebug,
A few more are required :
- Time to make product owner aware of this challenge and what it costs them not to do it. You don't need to be an Amazon to have benefits to implement it. As long as you have users, you need to provide them a good user exerience if you want your product to be used.
- Time to make developper aware of this so that they change their habits and embrace this new field.
To conclude with, 3 quotes from the article I really like :
Frontend dev make your apps a reality for end users :
A front-end operations engineer would own external performance. They would be critical of new HTTP requests, and they would constantly be measuring file size and page-load time. [...] . They own everything past the functionality. They are the bridge between an application’s intent and an application’s reality.
Beyond performance, error management and monitoring, it's about providing a resilient system :
It's about providing a service to the users and make it using the application on a long term basis :
A front-end operations engineer would be very friendly with the quality assurance team, and they would make sure that “performance” is a test that comes up green. They’d monitor client-side errors and get alerts when things go wrong. They’d make sure that migrations to new versions of the application go smoothly, and they’d keep all external and internal dependencies up to date, secure and stable. They are the gatekeepers of the application
Not every company or team can afford this person, but even if someone puts on the “front-end operations” hat for one day a week and prioritizes their work accordingly, users win. It doesn’t matter how many features you have or how sexy your features are if they aren’t delivered to the user quickly, with ease, and then heavily monitored. Front-end operations engineers are the enablers of long-term progress.
So I wish it would be part of my job (and yours too) for 2014...