Bleeding Edge Front-End Development.

Christian Sakai | Harris Robin Kalash

The Front End

  • The Front-End environment is constantly changing.
  • A lot of options to choose from with best practices, patterns and frameworks constantly evolving.
  • Overwhelming and steep learning curve.
  • More work that once belonged to the server is being moved to the client. As a result, design patterns, testing and modular code is increasingly important.

The Contenders

Google trends comparison between ember, angular, backbone and react.

React's rise in popularity is partly due to the fact that it breaks some of the most fundamental conventions we have on the front-end. By breaking those conventions, React unleashed a shock wave on the  web development community. Re-opened basic questions that were closed forever. E.G: Who would have ever imagined that CSS-tricks would post an article debating the need of CSS on the web?

AngularJS

  • AngularJS is hard to test.
  • Not SEO friendly.
  • Hard to keep track of application state.
  • Harder to integrate with other libraries.
  • Performance.
  • Steep learning curve.
  • About to be deprecated.

Where we come from.

Gulp/Grunt

  • They work fine, but they are just are just build tools and nothing else.

Bower

  • Limited to the browser.
  • Introduces global everywhere.

SASS

  • Easy to pollute namespaces.
  • Slower to complile.
  • CSS specificity is tricky, especially when you don't follow methodologies like BEM or OOCSS
  • C++ under the hood.

  • JS Frameworks (Meteor, Angular, Ember, Backbone)

    • Pros

      • Easy to start

      • Faster development

    • Cons

      • JS world is constantly changing

      • The framework (author/s) decides the implementation 

      • Does not compose well

      • Time investment in complex learning curve

      • Overkill features

JS Frameworks

Patterns and Libraries

  • Patterns (MVC, Flux, Redux) & Libraries (React, Express, Mongoose)

    • Pros

      • You decide the implementation

      • Easy to test, maintain, integrate & manage dependencies with other libraries

      • Small learning curve

      • Pick what features are needed

    • Cons

      • Require more setup to start

AngularJS

  • Pros

    • Easy to start

  • Cons

    • Steep learning curve due to big API (controllers, directives, services, factories)

    • Hard to test, maintain & integrate with other libraries

    • Overkill 

    • About to be deprecated in favor of 2.0

    • Slow performance due to design choice 

    • Debugging is hard

    • No server side rendering 

ReactJS

  • Pros

    • Easy learning curve due to small API

    • Easy to test

    • Better performance than most client side frameworks out of the box 

    • Even better performance with unidirectional data flow (Flux/Redux) 

    • Support server side rendering + client side mounting

  • Cons

    • Can’t be used by itself 

Redux

  • Pros

    • Lesser boilerplate code than Flux

    • Easier learning curve

    • Easy to test (just pure functions)

    • Easy to manage application state (one source of truth called “store”)

      • Possible to implement middleware

      • Time travel functionality

    • Easy async

Webpack

  • Module Bundler.
  • Handles everything (images, CSS, html, JS). 
  • Allows for local CSS. (good for keeping track of dependencies as well).
  • Allows you to focus on everything concerning the component you are working on in one place.
require('./styles.css');
require('./template.jade');
require('./image.png);
:local(.foo) { … }

COMPILES TO

._1rJwx92-gmbvaLiDdzgXiJ { … }

How does it compare to other build tools?

RequireJS

  • Build time

Slow.

  • Loads files on demand

Yes.

  • Supports ES6 modules

No.

Browserify

  • Build time

Better.

  • Loads files on demand

No.

Webpack

  • Build time
  • Supports ES6 modules

Yes.

Very fast.

  • Supports ES6 modules

Yes, using a loader.

  • No , but can be separated to chunks.
Source: http://delivery.acm.org/10.1145/2750000/2742814/supp/Static_Assets_Pipeline_With_Webpack.pdf?ip=71.183.68.229&id=2742814&acc=OPEN&key=4D4702B0C3E38B35%2E4D4702B0C3E38B35%2E4D4702B0C3E38B35%2E6D218144511F3437&CFID=556252793&CFTOKEN=22415494&__acm__=1446061364_7da43fab60a5919ff13275cbcdff4a73

postCSS & nextCSS.

postCSS is completely modular and doesn't do much. All functionality comes from plugins.

Examples of plugins.

https://github.com/postcss/postcss

cssnext

A bunch of postCSS plugins based on proposed CSS4 features. (The Babel of CSS).

Why would I use postCSS?

  • The idea of postCSS is not to hook you into another CSS-like language, but rather to give you the tools to write your own pre-processors, choose your own syntax or opt-in to use future CSS (CSS4).
  • SASS mixins changed the game, however you still need to think about it and include sass libraries to use those mixins. With postCSS, we can take it for granted and not even think about it as a simple npm-install will make sure all our CSS is post-processed (auto-prefixer and cssgrace for example).
  • Much faster! (great for development workflow where you have to recompile all your CSS. libsass takes a few seconds on large projects.).

Theory in action.

 

Subtitle

Made with Slides.com