Tag Archive for typescript

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.