Rethinking frontend development
•Download as PPTX, PDF•
0 likes•52 views
Concept of react and now reason have changed the way frontend of applications are thought about and developed. Increasing demand of complex user experience has made client side development more complex then ever. React has been a boon, it simplifies the way data flows are designed in applications and it shields users from limitations of underlying platform by virtual DOM model. React native has greatly simplified cross platform mobile development in way not possible ever before.
Recommended
Recommended
More Related Content
What's hot
Similar to Rethinking frontend development
Similar to Rethinking frontend development (20)
Recently uploaded
Recently uploaded (20)
Rethinking frontend development
- 1. Rethinking Frontend Development React Reason Jyoti Puri
- 2. About me Jyoti Puri Ex xebian Freelance remote developer Current roles: - Product development at atlassian - Product development at blockport Upcoming dutch crypto- currency exchange Open source contributions: - React Draft wysiwyg https://github.com/jpuri/react- draft-wysiwyg - Belle https://github.com/nikgraf/belle - Reason node https://github.com/kennetpostig o/lwt-node - Angular ui grid http://ui-grid.info/
- 3. Client side development, a un-solved puzzle
- 9. REACT computations RECONCILER RENDERER REACT NATIVE REACT HARDWARE REACT BLESSED REACT PDF REACT DOM REACT A- FRAME REACT ART REACT BLESSED
- 10. React fiber
- 13. SIMPLE IS NOT EASY - Ritch Hicky UNIDIRECTIONAL DATA FLOW
- 14. Unidirectional data flow - flux architecture Data flow in Mvc architecture Growth in code complexity
- 15. Unidirectional data flow - flux architecture - Concept of unidirectional data flow was introduced by flux - Redux added nice concept of reducers to it.
- 16. Rethinking the best practices RESTFUL API vs GRAPHQL
- 17. Graphql- A query language for api Describe your data type project { name: String tagline: String contributors: [User] } Ask for what you want { project(name: “devfest”) { tagline } } Get predictable results { “project”: { “Tagline”: “A great
- 18. JS and toolchain & libs Npm / yarn flow babel prettie rlinter Immutab lejs router - weak typing - Weird equality - This usage - Lack of modules (pre ES 2015) - Verbose functional syntax Data flow lib
- 19. Scope of language Conferences Meetups Books Online forums Blog posts Videos Tutorials Examples Documentation Version control Editor assistance Comments Tests Code <- actual language
- 21. Reasonml features Reason is syntax and toolchain for ocaml - Functional language - Javascript like syntax and ocaml like semantics - Types without hassle (types fully inferred) - Easy javascript interoperability - Algebraic data types - Pattern matching - Immutability as default feature
- 22. Reasonml - code example type schoolPerson = Teacher | Director | Student(string); let greeting = stranger => switch (stranger) { | Teacher => "Hey professor!" | Director => "Hello director." | Student("Richard") => "Still here Ricky?" | Student(anyOtherName) => "Hey, " ++ anyOtherName ++ "." };
- 23. bucklescript
- 24. Reason react
Editor's Notes
- World wide web (WWW) as it was invented in 1989 by Tim Berners Lee while working at CERN lab as web of interconnected documents. Technology used was hypertext markup language. Slowly it extended to web application with server programs serving HTML pages dynamically. Also, CSS and JS were invented. Things were pretty cool till state was at server side. Slowly complexity of state shifted to client side - web and mobile client. The technology stack of clients was quite not ready for this. Lot of libs and frameworks came into picture to ease this. Trouble is that our tools are not build for the work they are doing.
- FB was facing similar challenges in writing and maintaining bug free client side applications. Jordan walke at facebook wrote react.
- 2 selling points of React were: Virtual DOM Functional approach Virtual DOM was foundation of endless possibilities in React. React simplified overall architecture of client-side code. It brought functional coding mainstream. As developer you code to virtual DOM and then the library takes care of underlying Platform. That underlying platform could be actual DOM, or a lower level api exposed by browser like WebGl or even other native platforms. This opens possibilities like Minimal DOM diffing and async rendering.
- An architecture that forces you to code in right way. Very easy to unit test - as its functional. For same input at any time output will be same. Same code can be run on client and server. React components brought functional programming mainstream.
- Thus it shield you away from troubles of real dom. Complete re-render on every change. DOM operations really slow, but virtual DOM is fast. Less side effects.
- Learn once write anywhere. Cross-platform code sharing.
- Reconciliation algorithm.
- Stack reconciler
- Internals of react have been re-written mainly from point of view of improving the performance. Perceived responsive applications. Cooperative scheduling
- Simple is not easy.
- Changing data is root of all evil. Web applications now have lot of state which is passed around. Complex data flow become big problem.
- Simplified data flow is predictable. Growth in complexity is linear. Chances of inconsistencies are very low. React forces you to code in write way - which is very imp when working in bigger teams.
- These are proven technologies - realtime apps like FB.
- GraphQL provides a complete and understandable description of the data in your API gives clients the power to ask for exactly what they need and nothing more makes it easier to evolve APIs over tim enables powerful developer tools Get many resources in a single request GraphQL APIs are organized in terms of types and fields, not endpoints. Access the full capabilities of your data from a single endpoint. GraphQL makes it easy to build powerful tools like GraphiQL by leveraging your API’s type system. Can be us
- Learning a language is about learning reasoning about problem. Less learning barrier for bigger teams to ease adoption. Keeps JS toolchain. Preetier was based on refmt. Linting, boilerplate, ranspiling not needed. JS interop. Powerful and typed language. Adoption vs maintenance Type system, immutability by default Reason is multi-platform, type sharing between client and server. Why shayari was possible in urdu. UI programming is unsolved dependency. Writing few lines of code is not enough anymore. Why are so many libs needed. Example reson does not need proptypes.
- Academic focused Reduced test coverage need.
- Inbuilt data strictures in reason are highly optimized and this JS complied is even faster then JS we can write