Web apps the journey

How we got here

Back to the future clock

When you are asked to give a talk most of the time you don't actually think you have something interesdting to say. All the subjects are already covered in some form so the only new thing I think one can add to a talk is a new point of view of subjects that are already out there.

When Christian asked me to talk here at Solutis I didn't want to re-use one of my previous talks so I proposed a couple of options. Actually from those options this is the one I didn't want to be picked since it's the one that involved more research and effort to develop and I'm a developer that means I'm lazy by nature.

But here we are, I really wanted to say a few things about how we got here, how we ended up talking about bundlers and package managers because I feel I got into the industry just about the right time and I've been seeing every trend and new shiny thing that's out there. I feel that by telling you my story I can tell you about the last 15 years of web development.

About me

Old picture from cherta

This is me around the same time I got my first job in a software development company. Honestly if I were those guys I haven't hired myself.

It was 2005 and I joined this big company called TCS -you may have heard about them- and landed in an internal development group, that means I had no client pressure so we could innovate and try new things.

Around the same time Jesse James Garret an engineer working at Adaptative Path coined the term Ajax that will change how we develop applications and it will put JavaScript into a place that few people thought it could be placed.

Timeline I

Timeline with Ajax and some previous frameworks

This is interesting because all the previous framework we used to work with didn't come with asynchronous development in mind, they were regular server side frameworks where you issue a request and the response was expected to return another web page.

Dependent combos

Dependent combos reloading the whole page

You may remember these type of interactions if you are old enough like me.

As ugly as you may thing this is something developers like me did this all the time, first because the web as a platform was not evolved as it's right now, that means our only tools were these ugly dropdowns and a few other components and second because Ajax wasn't a thing so frameworks didn't thought about users ergonomics but developers ergonomics and I think this is still the case for some tools.

Timeline II

Timeline with Ajax and now Gmail wich is prior to Jesse James Garret article

Honestly I was lying to you a bit just to fit these timeline into my own career schedule. Actually there was one company doing better things than reloading the whole page by 2005. Of course we were years behind them but still, people started to get use to these type of interfaces.

Gmail

First Gmail UI

Gmail set the bar for everybody else an while people were getting used to it we developers needed a new way of deveoping web applications.

Please remember I worked for big corporate companies and they live in their own world very far away from consumers and this time was not an exception we kept doing ugly web applications even tho the technology was there.

Timeline III

Timeline with everything and also rails and jquery

By late 2006 three big things were released Rails, jQuery, and Dojo.

They all solve different issues but in a similar way so I think it's funny -and very handy for this presentation- that they appeard in a similar moment in time in the history of web development.

Rails

Missing

The rails people or should I said David Heinemeier Hansson who's rails creator and still maintains the framework wanted to tackle the common parts of web development in a nice gentle way. They knew there were several frameworks out there but none of them did what he needed.

These people were sick of configuring things and if you did java I bet you are sick of that too so they created a framework where most of the things worked out of the box without the need of configuring them. Convention over configuration they called it.

Rails started a trend that survived and it's still very core to a lot of the tools we use today, people like Yehuda Katz extended that idea and ported it to his other projects like Ember.

jQuery

Browser compatibility

It was 2006 and junior web developers like me were asked tom support multiple browser, there was the nefarious IE6 that we all learned to hate and by late 2004 we had Mozilla. jQuery landed just at the right time for a whole genration of developers that were maintaining browsers inconsistencies and for -again- lazy developer that didn't want to learn JavaScript (I don't blame them) and prefered to learn jQuery's API.

DOJO



Fast forward

Missing

So why should I care about all this ancient history you should be asking. Well, a fun fact is that it's not that ancient and secondly I think these tools shaped in several ways the tools we have now.

So let's take a look to the current landscape of tools and frameworks.

Ember

Tomster

Ember started around 2011as a spinoff of another framework named SproutCore but it was not until late 2012 when Ember reaches 1.13 when it took the shape of what I think ember currently is.

Since Ember was created by tilde.io the company of Yehuda Katz it's not a surprise that most of the core values rails have had during the years landed in Ember as well.

So Ember is a framework, not a library -like jQuery- it solves many issues and has the convention over configuration philosophy, more on that, Ember has a great CLI -which was ported to Angular- because the creators learned that developers are lazy and want their framework to do more for them.

Ember II

Another great feature is that similar to rails the framework is built to last and to carry new technologies and convert it to framework specific idioms.

Build to last

Ember is one of the bests choices if you are building long lasting projects that can't afford a major re-write every couple of years. Ember may take more time to land features than other frameworks but they will eventually land with the added benefit that they will always provide a migration path and probably will warn you months after about the changes you need to make.

Innovation within the framework

The same approach rails took websockets and background jobs and added them into their own rails-flavored way Ember takes different technologies and approaches to mix them into their own idioms.

Ember succesfully added VDOM diffing and later his own -faster- way of compiling templates, whitout touching most of the idioms they already had.

Some history



https://github.com/mraible/history-of-web-frameworks-timeline

- Early 2005 - Ajax
- Late 2005 - Rails
- Mid 2006 - jQuery
- Late 2008 - Chrome
- Early 2009 Node
- Mid 2009 - Flex 3.0
- Early 2010 - Angular Open Sourced
- Early 2010 - Steve Jobs thoughts on flash
- Mid 2012 - Ember 1.0
- Early 2013 - React

Before 2005