Pick your platform #

Let's say you're building a site or app for a business, whether that's yours or someone else's. Time was you really only built for the web atop the Internet. There was no real alternative, to be honest. Now, of course, the web is there, but so are a whole heap of other non-web platforms that operate just fine on top of the Internet.

To add to that they often have access to features and capabilities that simply don't exist in the browser. You can say what you like about the ubiquity of the web vs any other platform, but most people only have a device or two and they care about what they can do on that device. I'd also ask whether you ship exactly the same assets and logic for all devices, and since you probably don't I'd say that the concept of ubiquity is probably illusory at best.

The other thing I'd like to point out is that programmers are often not the decision makers for an app's delivery platform. Rather, managers and executives who are swayed by the perception of a platform's capabilities and its return on investment are the ones making the call. So it's important that we let our platform shine whenever we can.

It's important that we let our platform shine whenever we can.

Improving a platform #

To my mind there are three ways you can improve the state of the art:

1. Add features to the browser.
2. Update the language(s).
3. Programmers do better things in the browser.

I'll quickly step through each and highlight what's bothering me.

Add features to the browser #

We all need standards around which to rally, but there's an infamous problem with committees: they can be ridiculously slow, such is their nature. At this point there's someone who will tell me that things just can't change that quickly, that these things take time. That's entirely true, but I would also point you to iOS and how quickly features start getting used there.

If Apple roll a new API for the next version of iOS you can bet that the feature will be used by a whole suite of apps nearly immediately. That can't be said for browsers right now. That's what worries me.

Update the language(s) #

In our case the language is, of course, JavaScript. There seem to be two camps: those who accept JavaScript, and those that love it. I am in the former camp, to be honest. There are many things I appreciate about JavaScript, but I have a fundamental objection to it today. In order to run quickly we have JITs that evaluate and replace JavaScript with C++ code. If that's the case then I need to write JavaScript that is favourable to that process, not necessarily the code I would otherwise write. So do I really benefit from the dynamic typing or closures? Well it depends on how well the JIT in question can deal with my code, and that’s not immediately obvious at the best of times.

TC-39 is the standards body that governs where ECMAScript (and therefore JavaScript) goes, and it's taken them a long time to add classes and modules to the standard. Now we play the waiting game until vendors ship the changes which, let's face it, will be a long time in some cases. Meanwhile, other non-web platforms release a bunch of features that make development far easier and we suffer. That's what worries me.

Now we play the waiting game until vendors ship the changes which, let's face it, will be a long time in some cases.

Programmers do better things in the browser. #

I love helping developers, it's why I'm in Developer Relations, but if I'm honest this is the one I worry about the most. When I watch our industry the pattern I see is the reinvention of the wheel ("Ohai everyone, I just launched my new MVC framework! CHECK IT OUT!") and, lo, we have eleventy billion of the suckers. That doesn't improve things, it just means we have yet another way to do the same stuff as before. I’m picking on MVC, but empirically we know there are a heap of variants of virtually any kind of library you care to think up.

But, we say, it's helpful for developers to learn how to do these things, so why not? How do we know if we don’t try? That is absolutely true, but then I'd also say don't push it to GitHub and promote it as a viable alternative to the other frameworks. I'm just as guilty of doing this with my 3D engine A3, although I'd posit that I never claimed it as a viable alternative to Three.js. In hindsight I probably shouldn't have pushed it to GitHub, but there we go, lesson learned.

At this point, now that you have a much richer understanding of "how to build a framework / library for [insert task here]", it would help everyone out a huge deal if you put your energies into an existing project and help to shape that for the better. If we rally around specific solutions we can make progress much more quickly than if we all pull in different directions. Many times we don't do that. That’s what worries me.

As a side-note to this, I'm not suggesting that we need one solution for things. Not at all, we need innovation and competition, but we still need to question whether our time is better spent making a new solution to a problem, or iterating and improving on an existing solution.

If we rally around specific solutions we can make progress much more quickly than if we all pull in different directions.

I do believe our platform needs better primitives because we see developers solving the same problems over and over again, and to my mind the browser should handle many of these things. But, more desperately, we need to push the state of the art, not spend our time repeating ourselves. At the risk of repeating myself (for maximum irony), we are competing against other delivery platforms and so the best way to do that is to improve existing solutions not recreate them.

What to do, what to do… #

We need a sense of urgency, we need better tools, better language features, a better approach to building applications. At the end of the day we're the developers who build sites and apps, and we have a responsibility to shape our platform for the better.

We're unique in that we do have standards bodies to which we can contribute (which we really should, we all have experiences, insights and opinions on how our platform should evolve), and open-source browsers for which we can file bugs and commit patches (if we so desire), but, while we wait for platform and language improvements to come, let's spend some time on improving our existing libraries and frameworks (file bugs, commit fixes, write documentation and tutorials), and not reinventing the wheel.