- Day 1
- Day 3
Straight out of the gate we had the opportunity to hear from Jonathan Turner (developer at Microsoft on the Typescript team) more about Typescript and I've got to say... it's awesome.
For starters it allows us to use, well... types. If you're someone who's not a big fan of static languages, so you don't want to have to write the type name 4 times just to use it. I get it, you don't have to, what it gives you is some development time checking for objects and parameters so you don't have the instances where you're passing in '1' instead of 1 and it blowing up. It also gives you the ability to use as much or as little of the type system you want.
If types aren't your thing, then how about all of (or at least most of) the new features from ES6 (or ES2015) and the coming features from ES7 (at the moment it looks like we'll be getting async/await in Typescript by the end of the year)? These get compiled down to ES5 or ES3 if you're stuck targeting IE8 and below so you can use them in your code and have them work in the browser, the future is now!
Okay, so you don't like types, or new features (man you're hard to please) you want to wallow in the mire and stay with the standard ES5 syntax. Cool, you're able to benefit from first class tooling support in most IDEs and editors (Visual Studio, VS Code, Sublime with a plugin, WebStorms, brackets, the list goes on), which means we can get intelligent auto completion and peek to/go to definition for any of our application code.
I plan on digging into what's new and awesome in ES6 and typescript in another post (or a few) so I'll jump off my new language features soapbox (for the moment).
There’s been a lot of talk about SPAs failing in a number of ux and tooling contexts because things aren't rendered server side and we have to wait for all of our scripts and libraries to load before we see anything useful. I won't go into this too deeply here (you can look at almost any of the links in the search I've just linked to) but I was thinking a bit "meh, it'd be nice but the effort to get there isn't really worth it", I've changed sides on this completely.
First up the benefits are really tangible:
· Non server rendered pages are almost impossible for social media sites to show those nice inline previews we've all gotten used to.
· SEO, sure Google is starting to index SPAs, buuuut we're not really there yet.
· The web app gap, that janky loading screen we've all coded hundreds of times
Then there's the fact that it's not hard any more (I've got some serious love for the angular community) it works like this:
1. Write your app (making sure you don't touch the raw window or document object, abstractions ftw!)
2. Install the angular 2 server plugin
3. Bask in awesome
One of the cool things that will be coming with this is that Patrick Stapleton and Jeff Whepley have been working on a tiny library that will be emitted with your server rendered site and capture any user events prior to the angular libraries loading then will fire them off for the app to handle them (magicks!). This of course is still in the works, keep in mind angular 2 is still Alpha.
Most of the rest of my day was spent learning about the way forward using angular and cordova/ionic for hybrid apps, which is really super slick and adds an awesome way for really tight validation loops to get rapid prototyping off the ground quickly (things like local emulation, cloud publishing for apps and bootstrapping).
One of the really interesting sessions was from Peter Bacon Darwin, lead developer on the angular 1.x team. He spent an hour(ish) telling the story of how to get involved in developing fixes and how the angular team deals with the huge number of feature requests and issues that are being raised. The long and short of this is that the team is working on getting as much as they can out the door, but any help from the community is loved. One of the "of course they do that" but before Peter saying it was something I'd not thought of for me was that with any bug fix that comes in, before doing any work on it (as devs we're always super happy to jump straight in and fix it) was to write a failing test. This is something we all do for new development (right?) however adding it in for fixes is as standard practice to stop regressions is awesome.
The closing keynote from Steve Souders was all about performance from the user experience perspective. This was an awesome talk, and he challenged the common (developers) perception that the best/only way to increase time to a usable app is to shrink down the size of the data over the wire. Instead he was urging us to think about how we load various assets and how things like blocking scripts and styles can completely block the user experience from working like you'd expect it to. The best part of this was challenging us to not think of these things in isolation but within the context of what matters most to users. Fast is cool but unless it's what the user really needs you may just be shaving yaks.
The second day was seriously full on and awesome, I look forward to being able to put out a few more posts that dive deeper into some of the awesome new tech and features that we've learnt about and are starting to implement in our workflows.