• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

Dion Almaer

Software, Development, Products

  • @dalmaer
  • LinkedIn
  • Medium
  • RSS
  • Show Search
Hide Search

JavaScript

Can Syntactic Sugar be Nutritious?

December 11, 2017 Leave a Comment

When it comes to nutrition and food, there is nothing that we vilify more than sugar, as we find out how wrong we were with fat. As programmers, we often poo poo syntactical sugar, but two interactions that I witnessed reminded me look deeper.

The two stories were of Kotlin and ES6.

Once you kot, you can’t stop

Let’s start with Kotlin. There has long been excitement with the language, and when we announced our support at Google I/O there was a huge cheer, as this signaled that, not only will we not be doing anything that could harm Kotlin support, but that we would invest in making it great. Java isn’t going away, but everyone knows they can safely dig into Kotlin. I would go even further and say that you should at least be playing with it. Many top apps have been using it in production for some time, but if you aren’t quite ready for that, look for other areas to get your feet wet such as writing unit tests to get a feel.

Pat still wasn’t sold. Why bother with a new language? Functionally what can it do that can’t be done with Java? What about finding knowledgable engineers? Or the fact that we don’t have as much documentation for it yet? At a high level this is logical, but then something happened. Pat tried it, and after a weekend of hacking with Kotlin realized how productive and fun it was. As often happens, the expectation bar rose and it meant that going back to the verbose Java code seemed…. old fashioned. Less code, fewer NullPointerExceptions, and new libraries got the juices flowing in a new way, and it didn’t hurt that Android Studio was a nice helper along the way.

I don’t need no stinking classes

Devyn saw ES4 come and go. After years of working with JavaScript, with The Good Parts on the office desk, the notion of prototypical inheritance was a huge feature, and there was no need for class syntax.

CoffeeScript came around, and although Devyn actually liked many of the features (arrow functions, the role of spaces, rest…, lexical scoping) they never seemed worth the cost.

Then we started to see changes in JavaScript itself via ES6/2015, and Devyn was still skeptical. Do I really want to use babel in my flow and set things up for older browsers? Once again, a coworker pleaded with the TL to give it a go on a small project. Fast forward a couple months and Devyn is one of the biggest proponents on the team. When asked why, a huge turning point was the road from callback city, to promise mountain, to async/await lake. Finally, it was all making sense.

const makeRequest = async () => {
  try {
    // this parse may fail
    const data = JSON.parse(await getJSON())
    console.log(data)
  } catch (err) {
    console.log(err)
  }
}

Say what you mean

All of this was wrapped up in our project’s mantra: “say what you mean”. —Alex Russell

With this cleanup, we are moving developers closer to the point where they can cleanly say what they mean, without scaffolding getting in the way. Gone is some of the verbosity, and we can huffman encode things that we use all the time.

  • Don’t function make me function in my function chain
  • With custom elements we can get away from div div div divitis
  • Not having type information shoved in your face all the time gives your code space to breath (Dion (a Person) went home (a House))

It turns out that paper cuts really do matter. Speaking of types, one area that ES2015 has stopped short on is optional types, leaving room for TypeScript to become yet another example of something that many developers thought they didn’t want. Casey thought types only get in the way, and pattern matched “types” to “the way Java does types” (static, strong, and traditionally in your face), which happens far too often.

We have had myriad attempts of adding types in a variety of ways (beyond ES4). The Closure Compiler was one version, which has always been a phenomenal tool (to this day it normally beats the pants off of other tools when it comes to final code), but I always did a lil body shake when seeing context in comments:

/** @const */ var MY_BEER = ‘stout’;
/** @typedef {(string|number)} */

Pragmatic. But I admit to a preference of getting optional types into the language itself. Ideally even without type erasure!

One of the features in TypeScript that really tickles me is String Literal Types which allow you to get the benefit of enum without having to create enums.

String literal types allow you to specify the exact value a string must have. In practice string literal types combine nicely with union types, type guards, and type aliases. You can use these features together to get enum-like behavior with strings:

type Easing = “ease-in” | “ease-out” | “ease-in-out”;

Language features can often get rid of the need for more verbose patterns. These allow you to get around, or change fashion.

One fashion that comes to mind was when fluent APIs hit the scene hard with the growth of jQuery. I often like the way a chain looks, and they are very natural in the functional world, but when writing an API that has `return this` throughout feels a lil bit smelly to me at this point.

Dart fixes the itch without you needing to return this. Their cascade feature gives you the same flow and ability to ditch the object name shouting at you:

querySelector(‘#confirm’) // Get an object.
  ..text = ‘Confirm’ // Use its members.
  ..classes.add(‘important’)
  ..onClick.listen((e) => window.alert(‘Confirmed!’));

// and with nesting
final addressBook = (new AddressBookBuilder()
  ..name = ‘kris’
  ..email = ‘kris@example.com’
  ..phone = (new PhoneNumberBuilder()
    ..number = ‘123–456–7899’
    ..label = ‘home’)
    .build())
  .build();

Is this all nitpicky? Do you enjoy being on the flip side once you get there?

On the one hand, the hard part isn’t the syntax. If you understand the Android lifecycle thoroughly, you are good to go… picking Kotlin will be a (fun) breeze. On the other hand, your language is your expression, and you live with it for hours a day.

As I become more curmudgeon-y with age, I am trying to remember: at least give something a try before I come to a strong held belief.

I am much happier to have modern ES6/TypeScript, Kotlin, and Dart 2.0 to play with in 2017, and I look forward to more improvements, and richer support, in 2018. Some sugar over the holidays is OK isn’t it?

Some people are TypeScripting

April 12, 2017 Leave a Comment

Programmers have debated type systems since the dawn of time, and maybe always will. When communicating with the machine, what level of information should we have to put into instruction for our digital friends? Do we have to be so explicit? Is it worth it? Can they just work it out for us? Can then even work it out better than we can?

"After having used TypeScript for nearly a year, I have to confess: I never want to start a new project without it again." – @tomdale https://t.co/fzXt7BfztP

— TypeScript (@typescriptlang) April 12, 2017

This has cropped up on the JavaScript scene again with the rise of TypeScript. We keep hearing from engineers discussing what and why they are doing here, such as Slack’s usage in their desktop app, and Sir Tom Dale on how TypeScript is used in Glimmer (and how it is used differently to Angular 2 tools for example).

One of the key decision choices of TypeScript makes it a fantastic gateway drug. The first step to usage is mv foo.js foo.ts. Not only is this trivial, but it makes the process non-daunting, and you often get value as the compiler finds subtle bugs that you didn’t know you had.

When you get this value, you start to think things such as:

“An autocomplete system that only uses words in the current document feels barbaric afterward” — Felix Rieseberg

increasingly dislike the term/philosophy of “trade-offs”. don’t pick between things, find the right balance. pic.twitter.com/JT0gK5nfDq

— Luke Wroblewski (@lukew) March 9, 2017

This is the heart of the trade off (sorry, balance) with TypeScript. When building large JavaScript systems many made the baby step to use doc comments to add @type info and more structure. This always seemed a sad hack. Rather than a first class solution we were resorting to hiding some extra goodness away from major parts of the system. Yes, we built special tools that would grok the comments, but man. It really didn’t feel right. If we feel the need to do types, can’t we put them more front and center?

In fact, is this the right balance, or are we failing to take a further step to a better place?

I honestly don't understand the draw to #TypeScript. Once you decide you no longer want to write JS, why stop at TS? 1/

— Phred (@fearphage) April 12, 2017

We are once again hiding valuable information from key parts of the system. The type erasure means that our runtime isn’t able to get the benefit of the information that we are conveying. This information could be gold when it comes to AOT compilation, especially important in the world of mobile. Will we keep pushing on from this next level of middle ground to take the next step with types? So many were burned by thinking that the experience of types == that hellish enterprise Java 1.1 codebase, but the grey beards have always been shaking their heads at us there. We have type inference and much sounder type systems abound now.

Lin’s diagram comparing phases of JS and WASM execution

And then we have Web Assembly. Lin Clark did her usual magic talking though the performance implications. We are seeing increasing experiments with wasm as a compile target that allows the system to boot up predictably fast. Get going, and then improve from there. This can be huge, especially in a world where the time from user intent (a tap) to a running system converts to engagement and gold.

It is also interesting to compare the rise in TypeScript with the rise in Kotlin. In my mind, the window opened for Kotlin at a time where the type of source code you wrote for Android didn’t have some of the cool functionality that came to Java later. Similar to TypeScript though, it offered a really smooth learning curve. You can look at any Kotlin code and grok it really quickly, and you can start using it in your projects incrementally. That factor is so vital for adoption for these languages. You don’t have to wait for a new project, you can give it a try in many other ways. Once you dive deeper though, as with TypeScript, there are more advanced features, and you run into practical choices around making the system grok Kotlin even more, and creating extensions to access support library compat methods, or dealing with platform nullable types.

The allure of the incremental step is real. Is it an ideal end state, or will the masses go to a place where we push further? The good news is that there isn’t a shortage of experimentation, and the core platforms are getting better and better!


“We are programmed to receive. You can check-out any time you like, But you can never leave!”

The bar has risen again in 2017

January 10, 2017 Leave a Comment

Remember these and all of the 500 errors?

Evolution never stops. On some days it can feel exhausting and on others it is exhilarating.

I was thinking about the bar for user experiences and how far we have come as an industry. Users expect fast, reliable experiences that are silky smooth. Long gone are the 500 “Error can’t connect to the database” of the slashdot era. But we still see a tale of two Web’s as we browse around from link to link and sometimes time travel through experiences.

On one Web we have slow experiences that are pinch and zoom with poor performing ads weighing everything down. We see the scroll handlers freeze the world as we try to interact with the site. This is the Web that we curse. The one where we reach for the special reader mode.

But then we get to the delightful Web. This one works seamlessly across mobile and desktop. It is fast and snappy, with no dinosaurs to be found. We see pleasant non-janky animations that feel right. Gone are the awful signup forms and instead the browser and auth providers take care of it for you, even through a nice payments experience. We find ourselves going back to this Web when we can, and dreaming of a world in which more of it was like this.

To be able to build something that belongs in the world of delight we need to see the pioneering work of 2016 become the default of 2017.

To reach the optimal performance and reliability we need:

  • code splitting, prefetch-ing and pipeline of data to be tuned (e.g. PRPL)
  • service workers at the helm
  • and we need all of the tooling giving you the honest truth on where the current experience stands and where to go next.

Fortunately, many of the frameworks are taking the work done on the leading edge and baking it into their CLIs and when I find myself on something slow, I often go over and tap on a fast bookmark.

Going beyond performance, there are new capabilities coming this year that will open up more “wow, I didn’t know the Web could do that” and I am excited to see what people come up with there.

Next Page »

Primary Sidebar

Twitter

My Tweets

Recent Posts

  • I have scissors all over my house
  • GenAI: Lessons working with LLMs
  • Generative AI: It’s Time to Get Into First Gear
  • Developer Docs + GenAI = ❤️
  • We keep confusing efficacy for effectiveness

Follow

  • LinkedIn
  • Medium
  • RSS
  • Twitter

Tags

3d Touch 2016 Active Recall Adaptive Design Agile Amazon Echo Android Android Development Apple Application Apps Artificial Intelligence Autocorrect blog Bots Brain Calendar Career Advice Cloud Computing Coding Cognitive Bias Commerce Communication Companies Conference Consciousness Cooking Cricket Cross Platform Deadline Delivery Design Desktop Developer Advocacy Developer Experience Developer Platform Developer Productivity Developer Relations Developers Developer Tools Development Distributed Teams Documentation DX Ecosystem Education Energy Engineering Engineering Mangement Entrepreneurship Exercise Family Fitness Founders Future GenAI Gender Equality Google Google Developer Google IO Habits Health HR Integrations JavaScript Jobs Jquery Kids Stories Kotlin Language Leadership Learning Lottery Machine Learning Management Messaging Metrics Micro Learning Microservices Microsoft Mobile Mobile App Development Mobile Apps Mobile Web Moving On NPM Open Source Organization Organization Design Pair Programming Paren Parenting Path Performance Platform Platform Thinking Politics Product Design Product Development Productivity Product Management Product Metrics Programming Progress Progressive Enhancement Progressive Web App Project Management Psychology Push Notifications pwa QA Rails React Reactive Remix Remote Working Resilience Ruby on Rails Screentime Self Improvement Service Worker Sharing Economy Shipping Shopify Short Story Silicon Valley Slack Software Software Development Spaced Repetition Speaking Startup Steve Jobs Study Teaching Team Building Tech Tech Ecosystems Technical Writing Technology Tools Transportation TV Series Twitter Typescript Uber UI Unknown User Experience User Testing UX vitals Voice Walmart Web Web Components Web Development Web Extensions Web Frameworks Web Performance Web Platform WWDC Yarn

Subscribe via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Archives

  • February 2023
  • January 2023
  • September 2022
  • June 2022
  • May 2022
  • April 2022
  • March 2022
  • February 2022
  • November 2021
  • August 2021
  • July 2021
  • February 2021
  • January 2021
  • May 2020
  • April 2020
  • October 2019
  • August 2019
  • July 2019
  • June 2019
  • April 2019
  • March 2019
  • January 2019
  • October 2018
  • August 2018
  • July 2018
  • May 2018
  • February 2018
  • December 2017
  • November 2017
  • September 2017
  • August 2017
  • July 2017
  • May 2017
  • April 2017
  • March 2017
  • February 2017
  • January 2017
  • December 2016
  • November 2016
  • October 2016
  • September 2016
  • August 2016
  • July 2016
  • June 2016
  • May 2016
  • April 2016
  • March 2016
  • February 2016
  • January 2016
  • December 2015
  • November 2015
  • October 2015
  • September 2015
  • August 2015
  • July 2015
  • June 2015
  • May 2015
  • April 2015
  • March 2015
  • February 2015
  • January 2015
  • December 2014
  • November 2014
  • October 2014
  • September 2014
  • August 2014
  • July 2014
  • June 2014
  • May 2014
  • April 2014
  • March 2014
  • February 2014
  • December 2013
  • November 2013
  • October 2013
  • September 2013
  • August 2013
  • July 2013
  • June 2013
  • May 2013
  • April 2013
  • March 2013
  • February 2013
  • December 2012
  • November 2012
  • October 2012
  • September 2012
  • August 2012

Search

Subscribe

RSS feed RSS - Posts

The right thing to do, is the right thing to do.

The right thing to do, is the right thing to do.

Dion Almaer

Copyright © 2023 · Log in

 

Loading Comments...