Frontend frameworks for backend people

i probably should have titled this:

IS EVERYTHING IS A STEP BACKWARD FROM GWT 10 YEARS AGO ? OR AM I CRAZY. :) ?


I spent the last week revising thoughts on a bunch of frontend frameworks for our cloud native engineers.

Why would someone working on backend/kubernetes/golang orchestration related code need to do frontend work?

- UI's for mashups and testing:  Shell scripts are really just "mini uis" you build during the day.  They take alot of time and are throw away code usually.
- Interop with QA: QA engineers need fast easy ways to see if backend systems are working.  Generic metrics arent enough.
- Prototyping UIs for customers so that UX experts make sure they put FUNCTIONALITY into their form.

Here's what I found

Dart

I wanted this to work -- so bad.   A unified frontend platform that didnt rely on javascript to be productive up front.  However, as soon as i started googling for "dart web app hello world", I saw stuff referencing angular.js all over the place.

I was hoping it was just "generating" angular under the hood, but then i saw this *gasp*.


By far the most promising based on buzzwords and press releases.  Most dissapointing in practice.  The dart story is fractionated, I kept seeing this everywhere:

What?

Yeah really. They still want HTML templates.  Im out .

React.js , vue.js

React takes a while to get working (npm stuff, node stuff) and is hard to understand the domain model.  It feels very "tempaltey", in the sense that your embedding alot of HTML in your JS, and you dont have a clear integration point b/c of the complexity of the build.  In any case, if you get a react working, you then have to weed through all the cruft of Node.js examples to glue it properly into your backend.  Its not hard, but its time, and for backend developers that are building crucial functionality for million dollar clients that need real products (not just snazzy UIs), none of that adds value.

Conclusion:

React : probably not..... It  can work, but you have to dedicate yourself to it.  You cant just dive in and out of a react code base easily , and if something goes wrong and you want to start over, theres almost no blueprints to follow unless your whole dev. idiom is javascript/react based.  Also, the lack of types scares backend engineers alot.

Vue.js: maybe ! It is slightly less heavyweight and less biased.  Its easier to interact with it from a raw "html" perspective.  So I'd suggest it if you want a JS solution.

My vue.js code looked something like this: I would bind javascript objects on the JS side, and then reference it in html templates like so.  The nice part about this was that the view code wasn't embedded in javascript, and so , it felt like a real 'separation' of concerns in terms of managing the differences between how data was parsed/formatted from how it was presented.

React supports separation of concerns as well, but the programming model doesn't make the way that separation is implemented very obvious from a structural point of view.  Thus, as backend engineers that don't want to continually context switch frameworks, I feel like vue is a much better way to go.

Scala Play

To get scala play working, i had to do this:

➜  scalaplay cat project/plugins.sbt
addSbtPlugin("com.typesafe.sbteclipse" % "sbteclipse-plugin" % "5.2.4")
addSbtPlugin("com.typesafe.play" % "sbt-plugin" % "2.6.20")

In my scala eclipse ide (http://scala-ide.org/).  From there, sbt run was pretty much enough.

The red x's which werent referring to any real error were my first turn off, making me feel like play was more of a "toy" for scala geeks then something that i could really with a straight face tell my team to rely on for a multimillion dollar of business impact project.  But, since it was scala, and i love idiomatic scala, and i know engineers write better, faster code when they have type systems.... I didnt give up yet.

So, being that we're backend engineers, Typey languages are a good.  Getting play up and running is pretty easy.  Play is an "end to end" scala framework, allowing you to do mostly everything in scala, with a few html templates.

Out of the box, its leaner and less web bloated.  That lack of bloat, however, comes at a cost...  A stock scala play app looks like a 1990s mom and pop website.

So although I really liked the simplicty of Play and the lack of dependence on significant amounts of HTML, adopting a heavy scala/java stack for something that out of the box doesnt have hooks for the future (i.e. flash actions, docker recipes for deployment, clean CSS out of the box, embedded internationalization hooks) just seemed like a little bit of a stretch.  However, its probably #2 on the list of choices in this article.

Go 

Revel

Go has a few frameworks for web stuff.  About 50% or more are pure backend, built for fast json serving and API stuff.  Revel and Buffalo are the two that stand out as "Django"-esque.  Revel took a long time to get working for me compared with buffalo.  It does work, though.  You can't use idiomatic gopath's with revel, i.e. it wants to make your app directly under $GOPATH/src/, which i thought was annoying.  However it worked nicely once it started up.  The problem i hit with Revel was that extending past the basic apps was hard - there were'nt any good examples of how to do complex forms with it that were in the tutorials.

OMG Revel cant create a webapp in the right directory.  Scary.

Buffalo

Buffalo ranked #1 even though I hate the fact that it makes a huge site and has  a large vocabulary of templates that you have to think about on you.  Nevertheless, it worked out of the box, clearly had a look and feel and feature set, that scales to the future, and it could be built and added to other go projects easily (required a dep update to remove an old version of spf13/pflag).

To create it i just did "cd $GOPATH/src/github.com/jayunit100/myexistingbackendapp/cmd ;  buffalo new app my-app --no-pop" ... and now you have a new dir, under cmd/ where you can start hacking on a webapp to go along with your (probably terminal based) existing backend golang app.

If you use buffalo, you'll like it, make sure you don't make the mistake of gneerating your first app with a database.  There's an option to skip that step, so you just make a frontend.  OTherwise, buffallo wont start b/c you dont have postgres installed.

Its easy to extend structs to support templates in buffalo.  This will be production friendly. However, 

Python

Python is great for prototypes.  Once it starts scaling developers, managing builds, shipping in containers, making sure dependencies are easily managed when you need to integrate w/ kube apis, db clients, and so on, gets really fuzzy.  So even though Django and Flask are awesome, i didnt evaluate them very deeply for this work.  IMO, python is great standalone, as soon as you need a framework to do your  job - use a language with good dependency management.

I'm not going to bother posting a picture of what a python webapp would look like, like anything else written in python... its clean on the outside, and riddled with disgusting deployment cruft underneath.