Upgrade to Pro — share decks privately, control downloads, hide ads and more …

A Brief History of Frontend

A Brief History of Frontend

Why so many tools? How did we get here?

Rogério Chaves

October 18, 2017
Tweet

More Decks by Rogério Chaves

Other Decks in Technology

Transcript

  1. 4

  2. 5

  3. BREAKING NEWS: JAVASCRIPT ON THE BACK-END! 6 We can share

    some libraries with the frontend! We can run JavaScript on the server! V8 is faster than Rails!
  4. FROM JQUERY TO SINGLE PAGE APPLICATIONS •At the beginning, HTML

    pages + jQuery = interactions •Better user experience • Load only once • Faster interactions •Web apps getting more and more complex • More interactions • More customized •Share processing load with the user • Less requests to the servers • Only for API calls • #NoBackend movement 11
  5. RISE OF THE FRONTEND FRAMEWORKS •Nobody knew a definitive solution

    for organizing your frontend javascript code •Successful history of the MVC pattern on the backend (Rails) •Explosion of JavaScript MVC frameworks •Millions of TodoMVC apps 12
  6. 13

  7. 14

  8. •Using a framework wasn’t solving the issues as well as

    it should, or causing more at some level of scaling •They are all basically variations of the same architecture •The problem was: State NOBODY WAS SOLVING THE ISSUE 15
  9. •On the backend, your database is the single source of

    truth, the requests usually just read/write the database and finishes •On the frontend, one request (page), might be open for a long period of time, with many interactions and small state changing (popups open or closed, forms, buttons states) •On Backbone.js for example, it was said that the models were your single source of truth, but each model had its own state, synced via events. If you have multiple single source of truth, you have none •Models held state, Directives held state, DOM held state, the state was all over, making very hard to maintain •With two-way data binding you have to reconcile the DOM with the data on JavaScript, causing performance issues •Hidden/global events firing are very hard to follow WHY STATE IS THE PROBLEM 16
  10. WHY REACT CHANGED THE GAME 17 •The great innovation of

    React was the VirtualDOM, this improved performance a lot, but the thing actually that made the most difference was… YOU CANNOT CHANGE THE DOM DIRECTLY! •No more state on the DOM •Goodbye jQuery •Needs to explicitly declare when a component changes state, using the word state (which helps raising red flag) •It forced the creation of Redux
  11. THE RISE OF THE FLUX LIBRARIES 18 •This name is

    no longe used, Redux, with had its architecture based on Elm architecture is definitively the winner, the only real competitor is MobX RefluxJS Flummox alt MobX
  12. REACT HAS ALTERNATIVES TOO 19 •Since people solves the state

    management issue, they started working on alternatives to React too •Angular, Ember and new frameworks such as Vue started using the VirtualDOM too, also using unidirectional dataflows with Redux or RxJS
  13. NOT MUCH HAPPENED •CSS3 came along •Then SCSS and LESS

    to easy writing CSS •Rise of CSS frameworks • Twitter bootstrap • Zurb Foundation • Mdl (Material Design) •Things were pretty calm, but recently… 21
  14. 22

  15. 23