A Fresh Perspective on Front-End at Midwest JS

Last month, I attended Midwest JS. In the interest of filtering out the conference excitement over new stuff/shiny objects/microservices, I waited a month to write my reaction.

Takeaway 1: Functional Programming Abounds

I loved the emphasis on—and excitement around—bringing functional programming concepts into front-end development. I find that most of my frustration with Angular 1.x, for instance, revolves around mutating data and managing state. It was nice to see that not everyone is thrilled by two-way binding.

The best decision I made at the Midwest JS was attending a talk on Elm put on by Jamison Dance. I was reluctant to attend the talk, because it sounded like a pet language with no practical use. It turned out to be my favorite talk of the conference: a very well-informed walk-through that related the concepts in Elm to front-end development in general. It was also a nice reminder that you can use functional concepts regardless of your front-end framework, even if it’s not enforced in any way.

Honestly, if there were one thing that I took away from this conference, it is that functional programming is the future and that the future is now.

Takeaway 2: Angular 2? ¯\_(ツ)_/¯

I spend a lot of time writing Angular code. The workshop for Angular 2 was scheduled for the conference’s largest room, which turned out to be a bit… roomy.

By contrast, the React workshop filled up before we could get in. We weren’t even late (despite a hotel SNAFU that landed us 40 minutes out of town). I sat in on the Angular 2 workshop–whose testing section became obsolete literally the night before because of a new release candidate–to see what it had to offer. I have to say, I didn’t come away thinking that:

1) There’s anything resembling a logical path for upgrading from angular 1.x to 2.

2) Given the cost of choosing Angular 2 for a project, that it has any advantages over what everyone is already excited about: React.

Now that Angular 2 is out, I’d still have a serious hesitation in picking it for a greenfield project.

Takeaway 3: Pleasant Reaction to React

Everywhere I saw React code, I liked it. As one attendee noticed in the conference Slack, it seemed like the basics of a React project were covered in every talk. This was not unwelcome for me, since I came in not knowing much about React. It definitely has a lot of boilerplate code. However, a nice difference between React and, say, Angular 1.x, is that React doesn’t require as much convoluted wiring of its components.

Marc was almost ready to implement his "hello world" React app pic.twitter.com/ptdg4yteF1

—  Thomas  Fuchs  (@thomasfuchs) March 12, 2016

Also, a key question that I’d never considered kept coming up: Why are we sprucing up HTML with JavaScript AND treating the two as if they are part of different layers of our app? I find this especially irksome in Angular, since I abide by the rule of moving as much logic to services as possible.

The distinction between controller and template is fuzzy and weird anyway. But with all the heavy lifting happening on the server or in a service, it seems especially odd to pretend that the controller is, well, a controller, and not a view. To me, this fuzzy separation of concerns is the major failure of Angular 1.x. I’ve gotten accustomed to writing nice templates in Angular, but realistically, even the best ones are terrible to read and edit, not to mention reading diffs.

Meanwhile, over in Elm world, HTML files are generated as functions which take two arguments: content and children.

https://github.com/evancz/elm-todomvc/blob/master/Todo.elm#L211
viewInput task =
 header
 [ class "header" ]
 [ h1 [] [ text "todos" ]
 , input
 [ class "new-todo"
 , placeholder "What needs to be done?"
 , autofocus True
 , value task
 , name "newTodo"
 , onInput UpdateField
 , onEnter Add
 ]
 []
 ]

A Fresh Perspective

So, what did I get from Midwest JS? I got a fresh perspective on front-end development. It hasn’t changed my daily work habits (although there has been a nudge toward fundamental functional concepts), but I feel like I’ve got a couple of good directions to go the next time I have to pick a technology for a new or existing project.