A Brief History of Frontend

Why so many tools? How did we get here?

Transcript

1. A BRIEF HISTORY OF FRONTEND how did we end up in this mess?
2. JAVASCRIPT HISTORY 2
3. IN THE BEGINNING THERE WAS JQUERY… 3 $(document).ready(function(){});
6. 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!
7. NPM: LIBRARIES EVERYWHERE 7 tip: never use Bower left-pad
8. BUNDLING EVERYTHING: JAVASCRIPT DOESN’T HAVE A COMPILER 8
9. ES6+ No es totalmente soportado en todos los browsers o versiones de NodeJS Solución: 9
10. FRAMEWORKS HISTORY 10
11. 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
12. 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
15. •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
16. •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
17. 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
18. 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
19. 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
20. CSS HISTORY 20
21. 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
24. For questions or suggestions: Go to Brand Hub https://my.thoughtworks.com/groups/brand THANK YOU