Thread by @mayurdhurpate

With #FlutterInteract coming to a conclusion, it's time we reflect back to a series of moonshots (3) involving several visionaries which concluded with @FlutterDev becoming an Ambient Computing Platform including:
1. Lars Bak+team
2. Jordan Walke+team
3. Eric Seidel+team
(1/38)

PART 1. Fixing the Web
It all started with the 2 Browser Wars happening over a decade with several players pushing the limit of the web. (2/38)

Around 1996, Netscape, cofounded by @pmarca owned 85% of the browser market, which was challenged by @Microsoft in a fierce competition, which ended in 2002 with 90% market captured by #internetexplorer. An interesting language got developed out of this churning... (3/38)

The web required a 'Glue' language to interact with the markup and provide better web experiences. @brendaneich was tasked with making JavaScript with tight deadlines(10 days?)
P.S. IE launched a similar one called JScript leading to sites often only supporting IE/Netflix. (4/38)

How can Google miss the party? Lars Bak, the virtual machine master and his colleague Kasper Lund were tasked with something groundbreaking, building the fastest JS engine...launched as @v8js. This brings us to an important landmark.... (5/38)
P.S. We'll get to Flutter soon.

Now you know why @sundarpichai probably is leading @Google! Launch of @googlechrome and @v8js in 2008 by the legends. (Lars is sitting in a red shirt). At the time of launch, Chrome was 56x faster than the recent IE thanks to v8! We all know what happened next... (6/38)

The browser war 2 started around 2004 with @firefox gaining significant traction but ended with Chrome taking ~70% market followed by @apple safari at ~15% in 2017. I know it's 2017 as in May 2017, @andreasgal CTO @mozilla concluded in a blog post: (7/38) andreasgal.com/2017/05/25/chr…

In an allegedly leaked internal email (2010), the foundation of a new language Dash was laid to eventually replace Javascript to help support the modern complexity of web applications. Of course, Lars Bak was tasked with building Dash. (8/38)

As planned, @dart_lang was launched in 2011 for developing 'fast' apps on any platform with dart2native compiler and many more features. (9/38)

Dart outperformed Javascript compiled on v8 on several metrics and it seemed like we might eventually have a future web 'glue' language in the making. Over the next years, Dart slowly gained traction among several early adopters with dart2js compilers. (10/38)

But in 2015, in a blogpost by Lars Bak and Kasper Lund, Dart cofounders, comes '...we will focus our web efforts on compiling Dart to JavaScript. We have decided not to integrate the Dart VM into Chrome.'
(11/38)
news.dartlang.org/2015/03/dart-f…

But, a new ray of hope emerged out of 'Sky' with a new project in 2015 Dart Developer Summit. The project was showcased by @_eseidel who worked on making the web and Chrome performant for many years.
We'll come to Sky again in later tweets. (12/38)

PART 2. Rethinking best practices
As @fb_engineering was building one of the most complex web apps to date, they faced a lot of challenges in structuring it and keeping it performant. @jordwalke built a new Javascript UI framework, FaxJS to solve these issues. (13/38)

When @floydophone and team used the same library (now @reactjs) for the Instagram web, setting a foundation for open-sourcing it.
In @jsconf 2013, Pee Hunt introduces this incredible new programming paradigm to all: (14/38)

Breaking away from the traditional division of Markup, Styling and UI Logic, @reactjs redefines separation of concerns with (highly scrutinized) React Components and JSX. (15/38)

This was a clear break from traditional templating libraries which tend to look like a bit of hacking to at UI logic with libraries like backbonejs, handlebarsjs scraping the HTML for {{}} and replacing them. The React components took full use of Javascript using JSX. (16/38)

As if this was not enough, @reactjs, inspired by Dijkastra's letter 'A case against GOTO' cs.utexas.edu/users/EWD/ewd0… , shifts from imperative to 'React-style' programming, from explicit UI change to implicit state management. (17/38)

This introduced the concept of UI=f(state) and let the library smartly handle DOM tree changes. This concept got introduced across domains with Jetpack Compose, @SwiftLang and @vuejs using it! (18/38)

The secret sause: Here, even though it feels like the whole UI is 'Blown up and Rerendered', the library smartly traverses the DOM tree and only updates the changes UI parts automatically. (19/38)

This was possible in 2011 thanks to fast JS engines (*read v8) which made UI rerendering fast and smooth. And the results were great! React found it's Product-Market Fit!
(20/38)

Both React and later Vuejs libraries surged in growth due to much-improved quality of codebase and developer experience. This concludes the PART 2: Rethinking Best Practices.

P.S. Let's get back to Sky project by Eric Seidel in PART 3! (21/38)

Eric started experimenting with Chrome perf by stripping it of all excess, boilerplate and legacy layers, to the point it could no longer render the web, but on benchmarks saw many times improved perf. This was starting point for Sky, running code directly on the metal. (22/38)

It started with vision of developing the 'best' way to develop native apps on mobile! (23/38)

The Problem: Mobile App Development is Hard!
(24/38)

The Solution: Fast, custom and coded once!
(25/38)

But how can you run on so varied platforms with different OSes and their own APIs and UI interfaces? Simple, by providing your own runtime system, you can run it anywhere from Windows to Raspberry Pi!
(26/38)

Another interesting aspect of the project was that compared to other frameworks like @Ionicframework @reactnative which expose only top-level APIs hiding all the inner magic,Sky aimed to provide access to all the low-level layers right up to painting pixels on the screen! (27/38)

Ionic, Cordova Style frameworks: Using webviews for UI.
(28/38)

Android (Kotlin/Java), iOS (Objective C, Swift) Apps: Specific OEM widgets to be used tailor-made for matching platform's design.
(29/38)

React Native used a unique approach converting the codebase to respective OEM widgets using a Javascript bridge in between.
(30/38)

Sky, on the other hand, took the bare canvas from the platform and directly painted the UI on the top of it!
And result...(31/38)

...pixel perfect interfaces across platforms, which were further polished with Material and Cupertino widgets providing exact animations and design themes as their native OEM counterparts! (32/38)

Later, "finally", Sky was renamed and launched as #Flutter, bringing it all together:
1. Dart
2. React Style Programming
3. Going to the metal with Sky
To summarise (33/38)
cc. @_eseidel

I: A strong foundation, being fast and performant, with @dart_lang
(34/38)

II: Breakthrough battle-tested philosophy of @reactjs with declarative UI and separating concerns.

P.S. Read this wonderful article flutter.dev/docs/get-start… for more details.
(35/38)

III: The vision of Sky by @_eseidel and team to develop the best way to develop for mobile by going to the metal, improving dev experience with a single codebase and doing fast iterations with hot reload!
(36/38)

These are old stats, but you could see Flutter most definitely reaching its Product-Market fit with this huge surge in @StackOverflow questions around 2018! Now we even have @github Octoverse, @LinkedIn insights, and many more showing @FlutterDev surging ahead! (37/38)
(37/38)

I believe that @FlutterDev will surely redefine the way we approach development across devices with @Google's vision of 'Ambient Computing'. With this thread, I would like to express my gratitude to all those who helped it reach so far with their moonshots! Thank you! (38/38)