Tag Archive for typescript

Why Alice Runs JavaScript

Over at The Mad Botter I’ve been working my tail off trying to get a new version of our AI Slack bot Alice out before the end of the new year. As the code has become more complex, I turned to Typescript, Microsoft’s programming language that’s intended to bring static typing and a number of other quality of life improvements to JavaScript. After writing a few classes and a module in Typescript, I switched to pure ES6 JavaScript. Here are my reasons and please do keep in mind that I am writing a large scale bot, so I have some pretty high-end architecture needs.

Classes: As much as I’ve railed against previous efforts to impose classical inheritance and object oriented patterns on JavaScript by efforts such as, Class.js, they’re useful. Alice’s code-base is getting large enough that managing the overall architecture is a problem. For things like data models an object oriented class structure makes a lot of sense as longs as you avoid coupling. So, I went ahead and started writing some Typescript classes such as this simple example:

class Contact {
    fullName: string;
    emailAddress: string;
    profileImageUrl: string;

    constructor(fullName: string, emailAddress: string, profileImageUrl: string) {
        this.fullName = name;
        this.emailAddress = emailAddress;
        this.profileImageUrl = profileImageUrl;
    }
}

Nothing too fancy here. Out of curiosity I took a look at the generated JavaScript for this and was a little surprised:

"use strict";
Object.defineProperty(exports, "__esModule", { value: true });
class Contact {
    constructor(fullName, emailAddress, profileImageUrl) {
        this.fullName = name;
        this.emailAddress = emailAddress;
        this.profileImageUrl = profileImageUrl;
    }
}
exports.Contact = Contact;
//# sourceMappingURL=contact.js.map

WOW! That looks basically the same? Couldn’t I just write that and not have to deal with the complexity of having an dist folder full of generated code? Yes, I can, so it seems ES6’s classes have done a pretty good job of mitigating that need from Typescript.

Static Typing: I can feel some of already drafting your tweets pointing out that in the vanilla JavaScript version of the code, I lost all the types. That’s true, but I’m not really sure I care. Sure, static typing has benefits, such as empowering the compiler to catch a number of common programming errors. There are ways around this issue; you could always do what Ruby developers by replacing the compiler type checking with a bunch of unit tests that do little more than check types; sorry, couldn’t help myself there. If you really want the type of static typing protection that Typescript offers, then that might be a reason to stick with Typescript, but I’d urge you read this great post by Eric Elliot before you fully throw down your gauntlet in favor of static typing as a must have.

Debugging: Debugging Typescript just doesn’t work the way I want it to in Node. When an exception is thrown, the line referenced in the exception is not the Typescript code the developer wrote but rather the generated JavaScript code. That’s pretty terrible. The workflow seems to be something like this: you look at the exception in the JavaScript code and have to extrapolate back to the Typescript you wrote and figure out what exactly is causing that behavior. In small code-bases that might not be too hard, but at scale this doesn’t make a lot of sense.

For me, the primary benefit of Typescript ended up being classical OO and the debugging issue became too much of a nuisance to tolerate. I am sure that there is some awesome project out there that I could have integrated into my work-space that would have at least mitigated the debugging issue, but that would again add more complexity to my tool-chain and possibly to my staging and production environment. Let me know what you think in the comments or on Twitter.

 

FOSSGiving 2017

Long time readers of this blog and Coder Radio listeners may recall that for the last few Thanksgivings I’ve been writing up or covering on the show my list of open-source tools that I am thankful for that I feel will be significant in the year to come; if you’re curious the first year I did this was 2012.

Electron: I know this might be a little controversial, since there are a lot of strong feelings around the Electron project and how Electron apps use more resources than their native equivalents would. However, it’s undeniable that Electron has had a huge impact on the entire computing community and more specifically those of us who run desktop Linux. Doubt me? Have you used Slack, Atom, or Visual Studio Code at all this year? If so, you’ve used an Electron app. Given the trajectory of JavaScript and web technologies becoming mainstream and full-scale application development technologies with ever increasing performance, you can bet that Electron will continue its trend toward becoming the mainstream consumer and enterprise desktop application development technology for many organizations.

Node.js: I’ve spent a lot of time in the past railing against Node.js being used as a replacement for more traditional web application development technologies, such as Ruby on Rails, but I have to pass the turkey leg to the Node team this year. Over the past few years, Node has been maturing into more of an engine for writing large-scale JavaScript applications and we are really seeing the benefits of that in 2017. For example, my AI Bot Alice is written using the Microsoft Bot Framework using Node. Oh and every Electron app also uses Node as well as most Electron-like frameworks.

Typescript: Microsoft’s Typescript team came to liberate us from the complexity of managing large-scale JavaScript applications, however, Typescript has turned out to be something of a conqueror. With large-scale projects from other major tech vendors transitioning to it (think Google’s Angular), Typescript has gone from one of many compile-to-JavaScript also-rans to all but dominating that field and is now influencing the design of ECMAScript / JavaScript to the benefit of the wider community.

My three picks this year are all along one theme that I think has been emerging for a few years now – the dominance of open web technologies in just about every area of mainstream development. This makes not only practical sense for developers having to manage how they invest their training / education time, but also for business stakeholder who need to get work done as quick as they can and if possible in a cross-platform way. Native app development might make sense in some rare cases, but those are fewer and farther between. I fully expect JavaScript to continue it’s relentless march to world domination well into 2018. Let me know what you think of this list on Twitter and check out The Mad Botter INC.

How I Missed Web Assembly

As pointed out by an intrepid Coder Radio listener, I totally missed the importance of Web Assembly when it was in its initial nascent phases a year or so go. Now that Web Assembly is going to become a standard endorsed by the W3C and has backing from at least two major browser vendors to date (Google and Mozilla), I’ve done a full 180 and am convinced it is the future of not only web development but probably a good deal of mobile and desktop development as well; my assumption is that tools like Ionic and Electron will be able to leverage the performance gains brought by web assembly as well.

Looking back my mistake was that I failed to parse out the signal from the noise in the wider JavaScript conversation circa 2014 and on. There was (and in many communities still is) a lot of angst about the short-comings in the JavaScript language and a lot of people making noise about using alternatives to it that would simply compile to it –  CoffeeScript and TypeScript for example. There was of course a thread in the background about Web Assembly becoming potentially a language agnostic solution to this problem, but because I was looking at it through the lens of alternative languages to JavaScript and at the time didn’t think and I still don’t think  that changing from JavaScript just because you want a different language but then compiling into JavaScript makes any sense at all. In other words, I took a breathe and shouted a hearty “get off my lawn!”

My curmudgeon-like tendencies aside, I still firmly standby the idea that just writing in something like CoffeeScript to compile into JavaScript just because you don’t some features or shortcomings of JavaScript is silly. What I missed was that this whole language brouhaha was just a minor prologue to the real story — Web Assembly. Moving to Web Assembly not only increases web application performance significantly but also (as more languages create compilers for it) gives those developers who prefer some language over JavaScript a much more reasonable choice; they can simply use the language of their choice and compile it directly to Web Assembly! I’m totally on-board with that. In fact, I’ve been working in Microsoft’s TypeScript and find it great, so if we actually make it (we probably will) to this Web Assembly world, then I’ll probably go Typ eScript for most greenfield projects going forward.

As in Eden, there’s a potential snake in our garden — Apple. Web Assembly being fully supported on mobile Safari for iOS is absolutely necessary to unleash the full potential and development efficiencies that I believe Web Assembly can over the next five year period bring.

Questions? Comments? Blood curdling nerd rage? Tweet me! Also, take advantage of my free strategy session for your next project!

The Javascript Problem

Earlier this week Microsoft unveiled its brand new web programming language Typescript. If you don’t know what Typescript is or what features the language has, please take a look at Anders Hejlsberg’s great introductory video. Also, take a look at the Typescript ‘playground’ that Microsoft has posted if you haven’t tried the language at all; it is similar to the interactive console that Ruby has had online for a while. The big question that keeps getting asked is why yet another web development language? The ugly truth is that there is a serious problem in the web development space: a good portion of the Javascript code out there and that is currently being written is terrible.

Some people blame Javascript itself. Others feel that it is a fine language and the real issue is the developers working with it. I  agree with the second statemet to a point. I do agree that a lot of the blame for the current state of affairs can be easily laid at the feet of a large portion of the web development community, but I don’t think that helps or is productive in addressing the issue of poor code quality on the web.

The truth is your average developer knows Java or some Java-like language like C#. That means classical inheritance. It also means that most developers have been trained to think in a object oriented way and for these devs object orientation means classical inheritance. Javascript’s prototypical inheritance model is as foreign to them as functional programming. So, what ends up happening is that these developers end up trying to force what they know on Javascript and things get messy.

To be fair, we’ve tried to address some of the uglier issues in a Javascript development by developing tools designed to add some more discipline to the workflow. Still, we can’t seem to agree on if these tools are even valuable or what ones to use. Should client side Javascript be unit tested? If so, is JSUnit the tool for the job? Ask that question on a forum of web developers and watch the sparks fly. All this division does is further confuse our poor transplanted Java dev. Also, none of these tools actually do anything to change the nature of the language nor do they re-train the dev.

Ah training! Education! That’ll fix all our problems… right? Wrong. Take a look at O’Reilly or any other tech publisher’s Javascript offerings. They are publishing books on developing with the language at a furious pace. Certainly, there are more than enough texts out there for aspiring web developers to learn the intricacies of the language. Unfortunately, that is not a realistic hope and doesn’t take into consideration the vast majority of software developers: Dark Matter Developers.

Let’s assume that getting all (or even a significant number of) developers to re-educate themselves for Javascript or even that they’d be willing to do so is unrealistic. A number of tools have already come out that allow us to write our code in a  classical object oriented language and have it compile down to Javascript such Script# (C#) or the Google Web Toolkit (Java). Unfortunately, there have been a few problems with that approach; chief among them is that you often have to know Javascript to debug the generated code.

Ok, I’ve posted a lot of what we can’t or shouldn’t do here, so let’s get proactive! We can replace Javascript with an object oriented language that follows classical inheritance. Blasphemy! I know this sounds crazy but it makes sense when you consider that the size of the web is growing at an exponential pace and our clients / customers are going to expect increasingly rich and sophisticated web-based experiences as the HTML5 trend continues to grow. The need for a replacement language that is friendlier to the wider development community becomes more pronounced when you consider the fact that there are not enough of us Javascript literate developers to handle the coming / current workload.

Thoughts? Comments? Blood boiling rage? I’m happy to hear all feedback on Google+, Twitter, or App.net.