Looking back on the last couple of years in web development, things have dramatically changed. We have gone from an industry with a heavy dependence on Photoshop to favouring actual working prototypes and products.
As we march into 2015, I thought it would be worth taking a look what we can expect in 2015 (besides a continuation on the mammoth year that was 2014) for web development.
Goodbye Photoshop
While Photoshop is not going to die over night and still be used by many designers, 2014 saw the rise of alternative software products to Photoshop being accepted into the mainstream, the main one being Sketch by a little company called Bohemian Coding. Completely vector based and built for developing modern websites and applications.
Sketch was a natural transition for designers looking to fill the void that Fireworks left when Adobe discontinued it. In many aspects, Sketch took some missing features in Fireworks and added them into their own product (SVG support for one).
Going through posts over the last year on Designer News revealed stories of many companies who have ditched Photoshop for Sketch and been rather successful. Others have seen the value in just designing in the browser using HTML, CSS and frameworks to get the job done.
The rise of front-end frameworks
When it came to the front-end department, 2014 was a hell of a year. We saw ECMAScript 6 enter a feature freeze, Facebook’s foray into the high-performance DOM rendering/framework race with React.js and the future of Google backed AngularJS was revealed with plans for version 2.0 to be a complete rewrite.
We also saw front-end frameworks become increasingly accepted by designers for prototyping and building web applications. While AngularJS definitely saw an increase in adoption, so too, did EmberJS and Facebook’s view saviour React.js.
Even though a few of the front-end frameworks and libraries out there have been around for a few years (with exception of React), we only really saw them starting to become accepted in the mainstream and enterprise in 2014.
The unstoppable domination of Node.js
When Node.js originally hit the scene nobody knew where it would end up in a matter of a few short years, but here we are and Node.js is not slowing down in its attempt to become the defacto choice for creating Javascript powered web applications.
Almost all front-end tools in 2014 (the ones that matter) were built on Node.js, expect to see Node step it up a notch as it continues to delve deeper into the mainstream and enterprise sectors. The recent fork of Node.js will do very little to dent its progress.
Look no further than companies like LinkedIn and Walmart who have adopted Node.js with arms wide open, as Node continues to grow in popularity, 2014 actually saw the once number #1 choice for startups Ruby and Ruby on Rails drop in popularity in favour of Node.
Package managers everywhere
We saw package managers being used more and more in 2014. Just amongst my developer colleagues and friends I noticed many go from the attitude of we don’t need package managers to not being able to start a new project without using something like Bower or Component..
As 2015 rolls around, we are already seeing the two major players in the game. Bower for front-end dependencies and NPM (Node Package Manager) for workflows that use Browserify or Webpack as well as isomorphic web applications.
Slowly but surely the industry is finally starting to standardise on certain front-end tools like package managers (which is a good thing) and task runners. Front-end SPA frameworks seem to be up in the air for the moment, as choice and frequency of new kids on the block frameworks seems to show no signs of stopping.
Isomorphic web applications
Largely thanks to Node.js, we have seen Isomorphic web applications become a viable solution for many in 2014. Although not an entirely new premise, thanks to Node.js and a few packages supporting isomorphic web applications (a single unified codebase running Javascript) we have seen and heard stories of companies architecting their web applications using a single codebase.
The benefits of limiting the amount of context switching within a project not only means developers will be more efficient, but reducing the number of points of failure in a web application will make everyone happy.
Expect to see and hear a lot more about isomorphic web applications, mostly using React.js, AngularJS and of course, Node.js behind the scenes pulling all of the strings.
RWD (Responsive Web Development): Round 2
Lets keep in mind we have had the ability to developer cross-browser/devices web applications and websites for at least 4 going on 5 years now and it was only in 2014 that we saw many starting to adopt responsive web development, more specifically mobile-first responsive web development.
As front-end frameworks like Angular start to focus on handheld/mobile devices, we are seeing people finally see the light and build their websites/applications with smaller screens in mind first, not last.
People are eschewing conventional means of reaching mobile users, once upon a time you would build an app, but as Google starts to factor in small screen support into its web ranking algorithm, expect to see SMB (Small to medium businesses) start to see the benefits in a responsive site/application.
It pained me to see just how many websites are still not responsive, even from fairly large companies. In 2015 we are going to see a major push towards RWD as Apple and other companies enter the smart-watch race and once again, screens get smaller.
Angular might fall
AngularJS has a lot of community support, a lot of companies are using it as their SPA framework of choice, but the recently announced v2.0 changes which are dramatically different to the current 1.x version of Angular rattled a few feathers. There was hope for a while as Rob Eisenberg was at the helm of the 2.0 rewrite, but after leaving the project to work on Durandal again, things were thrown into disarray.
In 2014 we witnessed the rise of React.js. Facebook’s view based component like library which yielded unparalleled performance thanks to a in-memory DOM diffing feature which produced some impressive benchmark results. Towards the end of 2014 there was an almost tidal shift in the way applications were built. People started eschewing conventional front-end frameworks in favour for the more simplistic React.js + Flux. A combination that worked incredibly well on the front-end as well as in an isomorphic workflow.
While things are definitely changing, we can’t count Angular out just yet. It can still retain the crown, but the team are going to have to work really hard to match the ease of development and performance metrics of libraries like React.js if they want to remain a choice within the front-end ecosystem.
In 2015 we are going to see a continuing trend of front-end developers opting to use React.js in favour of frameworks like AngularJS which have browser quirks like “dirty-checking” which can cause performance issues when using and abusing features like two-way data binding (an issue that React.js does not have).
Full steam ahead HTML5
At the end of October, 2014 we saw something amazing, HTML5 was released as a W3C Recommendation meaning the specification process is complete. In 2015 we are going to see a major uptake of HTML5 usage as support for things like the video and audio is already fairly decent. other lesser supported parts of the spec will become more viable. Meaning less polyfills and less reliance on outdated tech like Adobe Flash.
We saw Google forgo support for NPAPI plugins in Chrome version 35 meaning that most people will have to go HTML5 or go home basically. Companies such as Netflix have already embraced HTML5 video, so expect others to follow suit sooner rather than later.
It’s native or nothing
Even as the likes of HTML5 and CSS3 become more widely supported, mobile browser performance for native-like applications just is not there yet and probably won’t be for a long time. Companies like Facebook, The Washington Post and LinkedIn have tried HTML5 application strategies that ultimately failed to yield the kind of performance that they would have hoped and opted for native solutions.
The truth of the situation is due to “security concerns” mobile browsers might not ever reach the kind of performance standards that native iOS and Android applications can. Our friends at kensingtonlinkbuilding.com says, Native will still be the route of choice for companies looking to create performant applications.
The (slow) death of CSS frameworks
Once considered the flavour of the week, CSS frameworks like Bootstrap and Foundation were used everywhere. Their ability to allow developers and non-developers alike to build/prototype simple web applications increased their popularity.
While we won’t see people all of a sudden just stop using CSS frameworks, more and more people are starting to see how limited they can be. Bootstrap is too opinionated and Foundation is too little opinionated to be the #1 choice for lazy developers and non-developers.
I have already experienced first-hand in a couple of development teams with a negative attitude towards the likes of Bootstrap and Foundation. Traditionally the only favoured part for developers was the grid system, but there are alternatives out there for grids that don’t come with the added baggage of CSS styles and classes for things you might not even need.
I think CSS frameworks will always be around, but experienced developers are starting to turn their backs to them. Expect the non-experienced developers to keep using them though and those who want to quickly prototype an application without a care for how it looks initially.
Conclusion
The reality of the modern web is we don’t know what can or will happen. These are merely guesses and observations based on what I have seen and heard, who knows if any of this stuff will come to fruition.
Regardless, we can’t argue the web isn’t in a massive and exciting transition phase as version 2.0 of the world wide web starts to become real.
There’s certainly a lot to learn about this issue.
I like all of the points you’ve made.