Wednesday, August 19, 2015

Go as a client side language

I was talking to a colleague of mine and we were both expressing the same feeling towards Javascript: bleah.

As I was going home, I've noticed this "piece of joy" on Reddit https://www.reddit.com/r/golang/comments/3hlfo6/do_you_guys_think_go_will_explode_the_same_way/ and I got frustrated with the answers there. One of them frustrated me in particular: https://www.reddit.com/r/golang/comments/3hlfo6/do_you_guys_think_go_will_explode_the_same_way/cu8c7rb (in case it disappears it says: "No because go isn't a language used by the web browsers.").

Leaving aside the lack of technical understanding that the user displayed, it got me thinking: what would be the reason that would get in the way of Go being used browser (client) side? Turns out that I can't find any, or at least my lack of technical understanding says: none.

How would it work?

There are two major approaches on this: ship the code or ship the compiled module.

I've tweeted the idea of creating a runtime for browsers and someone said: yeah but in this case you'll end up just like NaCL did. As I actually didn't knew why NaCL didn't took off, I've searched for NaCL on Wikipedia and discovered that Mozilla made a stupid decision to focus on HTML (Picard facepalm).

So, it's possible that Mozilla will again say no to this because in their stupidity they'll focus on HTML again, or maybe they'll say that they now have Rust and they should build a runtime on that, it's their language after all, no?

And this is such a pity as Go really is a beautiful language and the use of channels for events and all the concurrency stuff would be a nice fit for the modern web.

Too bad we all can't play along and personal (and corporate) interests dictate the free web and how we, the developers, have to suffer from it.
Post a Comment