Wednesday, August 19, 2015

Dynamically vs Statically Typed Languages

There's a huge divide between programmers that like dynamic languages vs those that like static languages. The usual argument for dynamic languages is that it makes it so much easier to add things and change things. You don't need to bother with changing the types of things. They just work.

I strongly prefer statically typed languages now, but I used Python 2 for a number of years. Coming from C/C++, it was awesome. I loved the conciseness, and I didn't have to worry about declaring variables before using them. After my first 1-5AM debugging session where I mis-capitalized one variable, I began to waver in my position. After a few more debugging sessions where I wondered why my properties are undefined, I was beginning to hope for a better way. But I couldn't give up lambdas and list comprehensions. It was so much easier to describe things.

Fast forward a few years, and my first job was at a .NET shop. Although they used VB.NET, I fell in love with IntelliSense. It told me what was available and it was right 100% of the time, regardless of how I had made a typo. Back in Python land, I always had at least one browser window open to the docs to make sure I spelled everything correctly. I had just thought this was the way things worked. After getting IntelliSense, I don't need to worry about spelling anymore. Occasionally, I can even use a library without even reading the docs first! The types and names told me everything I needed to know, right there in my IDE.

Now I use a mix of .NET on the backend and JS on the frontend. When I need to rename something in .NET, I can use ReSharper and it'll just do everything for me. Sure it takes 30 seconds, but I'm chilling those 30 seconds. When I want to rename something in JS, I do a find all through all my files and go through each line to see if it's something I need to rename. If I want to change Name into FirstName and LastName, ... well, there are 1000 references. I say screw it, that feature is too expensive. They'll never split their names.

A huge annoyance with the loosely typed world of JS is how it tries to have method overloads, but in a really clunky manner. I would prefer a bunch of different function names, but the community has embraced a few idioms that mimic overloading. I am glad TypeScript is gaining momentum as we build larger systems out of JS.

There have been a few times when I thought a dynamic language would be good. When I'm prototyping a small program, it is pretty annoying to have to declare classes for everything. I think languages with more aggressive type inference than C# would probably help me out, here. C# doesn't allow me to have anonymous types across method boundaries. This is a huge pain in the butt. Even ReSharper doesn't make it completely seamless. I still have to think of a name when I generate a concrete type for the anonymous type. Unfortunately, these little projects grow to something bigger rather quickly, so I prefer to take the productivity hit (or use dynamic types in .NET) initially.

Another reason to use a dynamic language is that you can get macros with it. Sure some static languages have a little bit of macros sprinkled in, but nothing as awesome as Lisp. Unfortunately, it's impossible to get that level of language defining macro with static types. Several people are working on something close, but it's still icky. At the extreme end, you could pull some stuff from the network and have it generate something. Well, there's no way I can know the types ahead of time. I haven't seen many compelling reasons to use this aside from DSLs, so I don't really want to give up my static types for this.

For the near future, I'll be reaching for statically typed languages first.

Friday, June 19, 2015

SPAs Should Be Used Less Often

I've been building Single Page Apps (SPAs) for the past two years. I think they definitely have their place, but I think I, and many other developers, have used it a little too much.

Some developers (myself included) have said that any web application should be a SPA. WordPress type sites are fine as they are, but anything more complicated should be a SPA. There are quite a few good reasons including responsiveness, server side load, dynamic content, ease of porting to PhoneGap, client side load.

These are all great reasons, but I think they are often over stated. There are well known solutions for many of these for classic MVC (whether MS MVC, RoR, django, etc.) apps. These have been proven to work, and are solid.

When we go to SPA, we typically are granted a lot of "freedom". These freedoms are things that we often take for granted like:
  • loading bar
  • history
  • right click - open in a new tab
  • sharable URL
  • loading panel
  • error logging
Each of these things are things I had to reinvent for myself when doing SPAs. This is on top of SPA specific issues such as SEO, long initial page loads, and page full of spinners. The browser handles many of these things for classic MVC apps, but SPAs have the option to implement these or not. Many times, these are features that SPAs would like to have, but must reinvent or pull in a package for.

I think there should be a mix of JS heavy pages and classic MVC pages. We shouldn't throw out MVC on the server side just cause we can do it on the client.

The boundary I would like to draw is to leave routing on the server side, and have the client do dynamic things only on one page. Yes, there are things that I would love to have persist across pages, e.g. toasts that stay forever or user notifications that stay forever, but I would rather pull in one or two packages for these features rather than all those other features.

This would leverage most of the browser's features while giving us the flexibility to use a lot of JS to have dynamic content. Most pages I have done have few JS features that cross pages anyway. Within a single page, there is often a lot of dynamic content, but not many cross the page boundary.

I am hoping that soon there will be a framework out there that will solve this issue. It looks like most frameworks are still stuck on basic components like the best way to do binding, write web components, and decorate HTML with functionality. Hopefully there will be a clear winner in the next wave of web frameworks. Until then, I will be going back to MVC.

Thursday, June 18, 2015

WebAssembly

The 4 major browsers have come together to create WebAssembly (https://blog.mozilla.org/luke/2015/06/17/webassembly/), a binary compilation target for the web. This is very exciting news.

I see this as something like JVM for browsers. While not everyone loves Java, most people have really good things to say about JVM. You can compile your language down to Java bytecode and have it run everywhere. A major limitation of many languages is that it only runs where there is a virtual machine built for it. By compiling down to Java bytecode, the language can run anywhere.

JavaScript is the standard language of the web, but it is truly lacking. I firmly disagree with anyone who thinks JavaScript is a great language, but there are, unfortunately, no alternatives. TypeScript has gone a long way to fix many of JavaScript's issues, but there are still many things not fixed. I am hoping that WebAssembly will fix some of these issues. At the very least, it will let us cover over these issues with a better language. This is something I am eagerly hoping for.