Cuttlesoft at DinosaurJS 2017
Being a relatively new, budding developer at Cuttlesoft, I think one part of becoming a wise senior developer is being able to correctly diagnose a problem, knowing that someone has likely already solved it, and knowing which solution to trust when implementing a fix. With that in mind, the first talk that comes to mind when thinking of DinosaurJS is Laurie Voss’ (Twitter: @seldo) talk on solving "imaginary" scaling issues.
One thing you’ll realize while going through his slides is the number of decisions you, as a software engineer, will have to make regarding even one aspect of your app or website. In this case, we’re talking about scaling (Voss was able to write 22+ chapters on scaling alone, and that's but one part of engineering an app). During the talk, I had the feeling that Laurie had either experienced these scenarios himself or knew someone who had, which adds greater credence to making sure that I can recall Laurie's advice when the time is right, even if I don't hit these types of decisions for years to come.
My main takeaway from his talk was the simple yet powerful sentence he ended with. “The way to scale any application is: carefully.” In the age when new frameworks are constantly being created and marketed as the solution for your situation, it can be very tempting to think that "new" equates to "best".
Rather than running wildly into these framework’s open arms, I’ll now approach more skeptically while keeping in mind that the application I’m building is unique. The next application I build will be unique as well, and the solutions from before may no longer be applicable. Learning how to do my due diligence could very well be the difference between a successful app and a garbage fire. (After Laurie’s talk, I’ve even found myself weighing the pros and cons between NPM packages I install.)
Dale's "Making the Jump" talk at DinosaurJS 2017
Tom touched a bit on how it often feels like there’s an inverse relationship between developer satisfaction and user satisfaction, and how it doesn’t have to be that way. Oftentimes developers need to write large pieces of complex code to cater to vastly different audiences and user requirements. However, big pieces of complex code make applications slow, which makes users sad. What if we put the onus on our build tools and compilers instead?
What if developers were able to write big pieces of complex code that get compiled down to byte-sized (excuse my pun) files that download quickly and run just as fast?
Tom went through each of the following popular frameworks and tools, among others, that are available now or on the horizon that will help with this exact problem.
For React, there’s Prepack, which is currently in the works and promises to make React code run faster than ever. Additionally, there’s RollupJS, which makes use of some of the latest features available with ES6 to allow developers to take a bunch of small pieces of code and piece it together into a single big, fast application.
For Angular, there’s Tsickle which is currently available, albeit a work-in-progress. This allows TypeScript applications to convert the TS code into fast-running, optimized Closure code.
Tom, being one of the co-creators of the Ember framework, ended with how some of the latest changes to Ember allow it to compile and run faster than any other framework right now, right out of the box.
I have to say, I’m very excited to see a day where both developers and users can live in harmony together. :)
If you were at DinosaurJS this year, what were your favorite parts of the conference? If you weren’t able to make it, I’d definitely recommend putting DinosaurJS on your event list for 2018!