Innovation, get used to it. - dotJS 2016 conference report

Published on December 7, 2016 by Christopher Zimmermann



I went to the dotJS conference in Paris for the first time. Billed as "the biggest js conf in europe", it is quite a crowd - something over 1000 attendees. But that's not what made it stand out for me - rather it impressed me as a quality event with an attention to detail, so kudos to the dot conferences team. I was impressed with the caliber of the other attendees I spoke with too.

One unique thing is that the subjects of the talks were not announced before the event - just a speaker list. Afterwards a speaker asked me if I didn't worry that I wouldn't hear what I expected or hoped for from a particular person. My mom gave me the guidance for this when I was heading off to university: Don't worry about the names of the classes; just search out the good professors. Anyway - when I attend a conference, I'm less interested in the specific details of a particular project (which I can find online anyway). I'm more interested to know "what's happening". What is the Zeitgeist of the moment? What are the deeper principles or expectations or concerns I should have for the subject as a whole?

So - at dotJS, with its impressive roster of speakers including the creators or important contributors from the angular, vue, electron, node, npm, socket.io, system.js / jspm, pouchdb projects - what is the word on the street?

 

Continuing web innovation

One theme that emerged is how to continue progress in the web technology world. Nolan Lawson eloquently presented why this is so important. Briefly summarized: Because if the web doesn't do it, then people will turn to the technologies that do - often from companies that have their own interests at stake. As digital and web become an increasingly important part of everyone's lives, it is ever more important that the net is open, free and available. Silverlight, Flash and Java applets could do cool things - but they were "on" the web, not "of" the web - and therefore had a lot of downsides for users and web infrastructure alike (searchability, copying text, etc). While those plugins are now a thing of the past, now consumers often turn to mobile apps instead of websites because they get a better user experience there. But is that the future we want? Everything silo'd away in apps instead of instantly accessible on the web? Progressive web apps were mentioned several times, from different corners of the browser world, as a way to bridge the gap - and keep more on the web. 

So how does this innovation happen? How do the new Javascript/ecmascript language features come about? I was interested to learn that proposals go through stages in the TC39 process, and that to make it to the fourth mature stage, the features actually have to be in use. Yeah - in order to join the language, they have to already be in use. That sounds like a catch-22. This is where the transpilers like Coffescript and Babel come in. Babel lets you use new experimental or custom features in your project, and transpiles them to javascript that actually runs in the current browsers. A result is that transpilers like Babel are not going to go away; they are the new normal. The best practice as recommended by Christophe Porteneuve is to use as few Babel transforms as you can - removing them as the native browser support catches up. But, we need to keep adopting the new bleeding edge javascript features in Babel so that they can be verified and battle-tested.

 

Javascript fatigue

There is a cost to the innovation, coined as Javascript fatigue or framework fatigue. It's exhausting to try to keep up when there is so much innovation. Worse, it's hard to maintain javascript apps based on a framework that is no longer popular.

Guillermo Rauch had this advice: Get used to it. And: it's worth it. 

 

Buzz

But where's all the buzzwords? Isn't this supposed to be a blog post about a front-end dev conference?

There is a lot of cross-pollination between different frameworks - with the result that many of the current hip js frameworks (Angular, React ecosystem, Vue) are adopting common patterns: component-based architecture, including component hierarchies. The idea of a "pure render function", that the entire UI is like a pure function. Given a state, the UI is completely determined by this state. So as a developer you don't bother with complicated interactions. You just manage changes to the state in response to user or server changes. The UI then updates itself. And they all use a "virtual dom" for performance (use service workers) and to increase portability of rendering (server, client or even native mobile app). A CLI to simplify common tasks and facilitate recommended best-practices.

This is partly due to common goals that the web community is pursuing: Frameworks should be easy to learn and the logic should be easy to reason about. Frameworks should lend themselves to developer tooling. Frameworks should support isomorphic rendering (templates can render on server or client side). Frameworks must be highly performant in order to run well on mobile.

Functional and functional reactive programming are really big - (even if no one agrees on what exactly that means) - as evidenced by the frameworks mentioned above, and by the popularity of RxJS Observables.

Easing development with asynchronous code is a big topic. Promises were a great step - but the new hotness in this space is "async await" and RxJS Observables.

 

Ease of development

A topic near and dear to my heart, ease of development and ease of adoption, came up repeatedly: in the Next.js presentation from Guillermo Rauch; in the Q&A after Ada Rose Edward's Web VR presentation, she was asked if it was something that people without 3D technical background should even try. She said that is exactly who should use it. The WebVR should be as approachable as HTML. That is the point. The live.js visuals and lighting performance from Sam Wray and Tim Pietrusky(which totally brought the house down by the way: fog machine via JS for the win!) showed how easy the new web audio API is to work with. In their Q&A they were asked, does it really make sense to do this kind of advanced hardware-centric thing with web tech? Answer: they never would have gotten into it if it was not available with web. That is the point - it makes things hackable and much more approachable.

It came up in several conversations I had with conference attendees. One person was really impressed with how the Vue framework can be used right away with just a script tag - but you can easily implement more and more of the features. This is the same philosophy that we apply to Magnolia's Light Development. In the latest promo video for Light Development, I start by saying "we embrace the paradigm of front-end development", and I got to wondering - what does that mean exactly?

At this conference I found a good answer: open and accessible.



Comments



{{item.userId}}   {{item.timestamp | timestampToDate}}

About the author Christopher Zimmermann

Christopher is a software developer and startup enthusiast with a focus on front-end web technologies. His interest in innovative UI leads to diverse experimentation from phone based GPS services, to Oculus Rift immersive experiences. He organizes the 'basel.js' javascript meetup group.


See all posts on Christopher Zimmermann

Demo site Contact us Free trial