[HacktionLab] Web development language question

[yossarian]

Hi Mike,

I agree with Naomi and Mick: Python/Django and JavaScript/Node are 
extremely good choices right now, and both will be around and alive in 
the timeframes we're talking about.

In terms of how well Node works, we have built several large-scale 
systems in NodeJS/Express at work (tens of millions of users), and it's 
fast, scalable, and the people who built the systems have found it very 
enjoyable to work in.

Now for the hating :).

JavaScript is quite a strange language. It was thrown together as a 
10-day hack and was then released to millions of users, so it lacks a 
lot of basic language features. It hasn't evolved much since, because 
the browser vendors immediately got into a standards war which stunted 
its growth.

In terms of the language community, this has bad results. I have 
interviewed hundreds of JavaScript coders, and very few of them 
understand that there are multiple options for achieving common 
programming tasks like encapsulation. They typically learn one 
accidentally, maybe because that's how jQuery does it, or because they 
copy/pasted something from Stack Overflow and it worked, and they stick 
with it.

Note that I'm not saying these are bad ways to learn, and everybody's 
got to start somewhere (and I do this all the time). But I know very 
good programmers who can talk intelligently about their code in other 
languages such as Ruby, C#, Perl, Python, or Java, but who have all the 
mental power of a cocker spaniel when they try to talk about what 
they're doing and why in JavaScript. Something about the language itself 
seems to promote unclear thinking. Things like keeping code files short 
and separated, the single-responsibility principle, or writing class 
libraries with well-defined interfaces, are almost unknown outside an 
elite and relatively small group of JavaScripters.

So, if you use NodeJS, it's worth writing a style guide, really learning 
JavaScript, and setting coding standards right at the start. Otherwise 
larger projects will turn into a mess when that new coder shows up, 
doesn't know or understand the prototype chain encapsulation you've been 
using, and writes all that new code using the function-module pattern or 
Object.create().  And it's not just encapsulation: there are so many 
ways to do everything that the chances two JavaScript coders will write 
anything in a similar way is very close to zero. Left to their own 
devices, many JavaScripters will just dump everything into a few 
3000-line files, with everything organized just like the PHP standard 
library.

All of this is less of a worry if you're working mostly alone or with a 
small and stable team.

My dislike of JavaScript may change once the new JavaScript ES6 language 
is stable on Node. I very much like the improved syntax of that - it'll 
take a while for somebody to write a viable web framework in it, though.

Python, you absolutely can't go wrong with. If I was writing an API with 
it, I'd question whether Django was necessary, there are a bunch of 
smaller, more single-minded frameworks, such as Flask. If all you're 
writing is the API part, you'll have far fewer dependencies to deal 
with, and can probably concentrate much more on what you're doing in 
pure Python, picking exactly the libraries you want - it'll be way 
easier to upgrade and keep things current if you're not tied to whatever 
Django is doing three years from now.

If I was doing this in Ruby, I'd use Sinatra for this kind of system. 
Again, I think you can't go wrong with it, and there are some very good 
libraries available for JSON serialization, generating templated API 
output and other common tasks.

I've also used Scalatra, which is Sinatra's Scala equivalent, to very 
good effect recently. For larger systems, I've fallen in love with 
Scala: the combination of low-verbosity, high-power syntax, the wealth 
of library options on the JVM, and static typing that doesn't piss me 
off and makes refactoring sooooo much easier, has been a big winner. I 
suspect it falls into the <buzzy> category for you, though :).

The nice thing about any of the minimalist Sinatra-style frameworks 
(Flask/Sinatra/Scalatra) is that they give you the simplest possible way 
to express an API endpoint, maybe something like this:

get("/foos") {
   // retrieve a list of Foo objects here from some service
}

My thinking is: that's pretty easy to understand. If I'm writing an API, 
it's all I need to build out an HTTP interface to my system. Do the rest 
of it in as minimalist a way as possible, and think of the HTTP part as 
being just a thin layer at the front of my application. That way, if I 
need to re-use the functionality, maybe building a second interface 
based on message queues, my system is ready for that, because I've built 
it as a set of class libraries which happens to be callable from an HTTP 
layer.

With respect to Ember.js - it doesn't seem to be getting the same 
traction that Angular or Backbone are getting. The front-end coders I've 
spoken to perceive it as complex and a bit weird. I think that Angular 
or Backbone have effectively won out. At work, we're betting on Angular. 
Front-end frameworks, though, have roughly the lifespan of a fruit fly, 
and it's hard to predict what will happen there.

Lastly, you should probably go up and get drunk with Tom in Cambridge, 
it's a pretty great experience and since this is for work you could 
expense it as research.

Cheers,
Yoss


On 01/07/2014 08:58, Mike Harris wrote:
> Hi All,
>
> I've asked this question before to see what people felt, but that was
> well over a year ago so I'll ask it again.
>
> Say you work on a web based service with a lot of legacy code written in
> an older web-scripting language, Perl, and you're wanting to move to a
> newer language for web applications, or even a framework to do new
> development - you're still planning to support the legacy code for a
> number of years - what language and/or framework would you pick?
>
> What you'd like to do though is avoid jumping on something that is too
> new and too buzzy - http://ttfa.net/lemonmarket - as you'd like to make
> a technology decision that would be good at least for the next five
> years, if not more, and today's rising star could quite easily be in
> tomorrow's dustbin.
>
> Any ideas?
>
> Mike.
>
> p.s. and yes it's a work question, but one interesting I think
>