25 Feb 2015, 09:30

Around the Web - February 2015


  • The Fold manifesto : why the page fold still matters ; even if we get used to scroll, we need to be encourage to do it. Thus the fold is strategic to convince the user to make the effort to go beyond this limit ; whatever the size of the device is (RWD included).



  • OCTO was at DotJS and try to sum up what is the status of frontend frameworks (in French) mentionning Web Components, Isomorphic javascript (ie both in frontend and backend side) and some ideas around the announcement of the AngularJS 2.0 which generated a lot of noise.

CoreOS, Docker & co

  • Discover Docker; another blog from OCTO, about CoreOS. So if you don't know about CoreOS, Etcd and Fleet, the article is for you so that you have an overview of what is CoreOS.
  • Nuxeo made a summary of their use of CoreOS (including Fleet & Etcd), Docker and the tools they build for Nuxeo.io platform. Very interesting summary.
  • If you are interested in minimalist OS, this post on Docker blog mentions "of course" CoreOS but also Ubuntu Snappy Core (Ubuntu based) or Project Atomic (closed to RedHat/CentOS/Fedora system).

Responsive Webdesign

ReactJS, Flux


  • Making a complete polyfill for the HTML5 details element : if you were to bridge the gap by providing a feature a browser does not include, it is very interesting to see the how it is done from a methodological point of view.
  • Improve your lists with style ! Now that counters are "stylable", you can do a lot of things to improve the rendering of your lists (no more bullet points but some shiny icon ?, manage padding, etc). HAve a look at the demo (requires a modern browser)

15 Jan 2014, 09:30

Frontend Ops
A brilliant article was published mid June 2013 under the title Front-End Ops : by itself, there is nothing new but I really like it because it makes a smart synthesis/wrap-up on some "trends" and the requirement to improve the maturity on frontend side. Below a summary with some inline comments.

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,
  • ...
So tools are (almost) there and still need to mature for some of them.

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 :

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

It's about providing a service to the users and make it using the application on a long term basis :

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...

17 Jan 2013, 09:43

What if your next backend application would be only an API ?

Web site and application used to be built as following :

  • On the server side, you had all the data, all the logic (what to display and when) and at the end, the server push the answer
  • On the client side (ie in a browser mainly), you only have the rendering of the data and the layout (HTML/CSS/Javascript) - client side allows just to interact with the server side and get/do what you expect. If you go offline but keep your browser open, you cannot do anything with your website or app.

So we all know client/server apps.

Now, for a few years, we have a rise :

  • SaaS services (Flickr, Delicious, Salesforce, etc)
  • Web 2.0 and the mashups effect : you want to retrieve on one page your latest photos, aside your latest marks or latest custom requests, all coming from differents places

That's only feasible thanks to API, which allows interactions between some services/softwares over the net and retrieve data you will aggregate and use as you like.With an API, you can get / create / update / delete data in a system.

Going a little bit further over the years, we got mobile apps, HTML5 and Javascript :

  • Mobile apps, which are on the client side and are able to get data from somewhere over internet and display what you expect and of course manage some offline features so thar you app may work even if you have no connections.
  • HTML5 and its ability to provide especially some local storage and offline management, with a consequence that you can do more on client side, as for mobile.
  • Javascript :
    • Note : if for you Javascript means some crappy visual effects from the early 2000s, just forget this vision. Javascript evolves a lot on the last years, is far more robust than you exepct (but still hase some drawbacks as any language) and can now work both on client and server side. I will not enter into detals here but consider it as a real language as you do for Java, PHP, etc.
    • So Javascript will still provide you all the interaction you need on client side to interact with your application.
    • Have a look at AngularJS or BackboneJS which are HTML/JS framework to build web apps, on client side. See the AngularJS demo app you will build during the tutorial. Everything is done on client side, including search / sort, getting phone list and displaying phone details. For data, there are a few JSON files to provide data in a structured way.

The consequence of this shift is that you can move all or part of the logic on the client side. You only need to be able to fetch/retrieve your data over the network, then apply the logic and render the content & layout to the user on client side, whatever it is a browser, a mobile phone.

So let's imagine you plan to build a new application and know that you will have several devices to support, you could change the architecture as follows :

  • On backend side, just define an API to expose your data as you will use them, with some authentication & authorisation of course
  • On client side (web / mobile / ...), build an app/web app that will connect to your API and consume the data and render it as expected.

In a article in French called "From mobile to web" where the same principe is used (API on one side to provide data and a web app on client side), it even goes one step further by imaginting a single app that will autodetect if you use a mobile or desktop browser and then render the appropriate display. I'm not convinced it's the best solution as it could make your code quite messy.

21 Nov 2012, 10:33

What about industrialising front end ?

A few weeks ago, I attended a Node.JS training and during which the "bower" tool was introduced. As stated on project's page, "Bower is a package manager for the web. Bower lets you easily install assets such as images, CSS and JavaScript, and manages dependencies for you".

At a first glance, such a tool can looks strange as frontend developers are used to download their favorite lib for each of their project. But at the end, such a task has no value at all and for backend technologies, we no longer do this for years (maybe still on Windows system ;-) ).

Small disgression : how do we do with backend technologies ?

Backend developpers almost never compile nor download their binaires for each of their project.  They use package manager (especially on a Linux system) and some tools over them to automate such deployments (Puppet, Chief, custom scripts, etc). This is true for softoware like Web servers (Apache, Nginx, etc), Databases (MySQL, Oracle, Postgres, etc), Languages (PHP, Java, Python, Shell, etc).

Even at a language level, this is possible to define the required librairies for a given project. For ex, in Python, if you use the package manager pip, you can define requirements for your projects which will be grabbed when you initiate it. You are able to specify not only the required libraries but also their version.

With such packaging, distributing and deploying your project is quite easy as everything can be automated and also you will avoid compatibility issues as you will not use the wrong version of a library for which the project has not been tested.

So why not doing it on frontend side ?

Back to bower and its implications...

So let's imagine your project needs a version of JQuery, instead of going on jquery.com, download the file and use it or copy/paste a version from an existing project, you just have to write to get the latest version :

bower install jquery

If you want a specific version of jquery, you can specify arguments ; I let you discover it on the doc to see all the features of bower to grab and download a library.

If you think on your project, you may want to define the requirements and save all the libraries you will use. Just add a "--save" flag to the command so that your selection is saved in a component.json file.

For ex :"bower install --save jquery bootstrap" will lead to this file :

  "dependencies": {
    "bootstrap": "~2.0",
    "jquery": "git://github.com/components/jquery.git#1.8.1"

Once this file exists and is saved in your version control system, you no longer need to store the librairies in your VCS.

For a new deployment or a new developper joining your team, he will just have to checkout the project, go into the directory where is stored the component.json file and run "bower install" and bower will install everything automatically. And voilà.

Beyond Bower...

Next to a discussion with a colleague, you have yeoman which aims to provide a full workflow for developping modern web apps. It includes bower but also yo and grunt

As they stated themselves :

Yeoman 1.0 is more than just a tool. It's a workflow; a collection of tools and best practices working in harmony to make developing for the web even better.

Our workflow is comprised of three tools for improving your productivity and satisfaction when building a web app: yo (the scaffolding tool), grunt (the build tool) and bower (for package management).

  • Yo scaffolds out a new application, writing your Grunt configuration and pulling in relevant Grunt tasks that you might need for your build.
  • Bower is used for dependency management, so that you no longer have to manually download and manage your scripts.
  • Grunt is used to build, preview and test your project, thanks to help from tasks curated by the Yeoman team and grunt-contrib.

All three of these tools are developed and maintained separately, but work well together as part of our prescribed workflow for keeping you effective

Seems like a maven for frontend/web development.

I don't know if such a tool exists in other languages to avoid using node.js & npm (Node Package Manager) which are required by bower/yeoman. But at least this tool raise the question : "how can we industrialise front-end ?"

Would you be interested in using such tools for frontend lib ?