by ranadeep bhuyan (@ranadeepbhuyan) on Friday, 12 August 2016
- Full talk
- Technical level
Context – Starting with the learning from past mistakes – with couple of question to audience
At times, when we start with new web application or re-architecture of an old application we all have to take a difficult decision at the beginning – that is, ‘what framework and tech stack are we going to use?’ Once the decision is taken we are stuck with the decision at least for two years or till we decide on the same decision again.
The ideal state to be in is possibly are the following attributes –
Super fast first page load from any full url within the application, quickly become responsive to the user actions, rich user experience (app-like) and reliable offline, works mostly with no/poor network. Reusability is one of the major factor as well.
Many of the current frameworks have been trying to solve for this ideal state in parts or in combination of a few for example SPA with serve side rendering. We are yet to see any magical combination of both server and client technologies coming together to solve for the wish list of the ideal state. There may be various reasons to this – like technical companies has competitions from each other, less collaborations, researchers are working in silo etc. As a result of this, almost all small or large organizations are creating large monolith stacks every now and then. Some of us are doing tech stack revamp every year and ends up creating another new monolith after two years.
What can we do to reach the ideal state?
How do we combine or develop specific tools and technologies to solve for developers and for customers as well –is this real paradigm shift for developers, browser companies and server technologies? Or is this a matter of coming together once for the community and customers to align to a single goal with single priority.
Let’s see how a Single page application built in (any) react JS frame work using HTTP2 push, service worker can achieve to the maximum for the above wish list of ideal state. We follow some of the best of the practices borrowed from the 17 UNIX philosophies (for Unix commands/programs).
We will demo a few small re-usable components using ReactJS and Google Polymers.
To Conclude - Modern browser should support couple of basic things like import, Custom elements for a better progressive web development for Speed. HTTP 2 and Polymers are currently the best combinations to work with web scalable and re-usable applications with all possible goodies like first page load, offline, re-usable etc.
- Pain points
- Solutions evolved so far
- Ideal State
- Progressive web
- Google polymers
- Server Push
- Couple of Map polymers
- Re-Usable Polymers for IOT
Setting the context - 2 mins
Couple of learning from a few historical coding issues with HTML (with demo) - 4 mins
Ideal state - wish list - 5 mins
(Fast first load ready to use, App like rich UI, usable at offline mode, accessibility)
Pain points on existing solution (code demo) - 4 mins
(Couple of Current JS frameworks, services – a comprehensive Comparison slide, Custom UI elements, 2 way data binding, first page load time etc.)
Why Google Polymers? – Trying to address ideal state along with HTTP 2 Push
(UNIX like to our basic HTML/JS/Server programming practices) - 5mins
Progressive web application demo – 4 mins
(Using Server side rendering, Server Push, pre-cache, service worker, pre-render) Accessibility - 2 mins
Re-usability - 3mins
Demo Few Re-Usable Polymers we have created
Google Maps elements – (demo 3 mins)
LED hello world demo - 2 mins
AR Parrot drone re-usable control Polymer with Node JS –(demo 3 mins)
Limitation of Polymers and temporary fix - 2 mins
Github code share – 1 min
Q&A – 4 mins
We are from Intuit and passionate about Google’s idea of Speed and trying change the way we develop web applications at Inuit to deliver for customers and developers in a boundary less manner.