I have always thought that the Holy Grail of web development would be to write all of my code in one language.  The main problem with this is that browsers only accept Javascript. Why is that a problem? Two reasons: the language is ugly, and back in the day javascript didn’t run on the server side. While there has always been the option of other languages being cross compiled into browser compatible javascript such as Coffee Script, Dart, and even Rails had a DSL at one point. That always seemed like it was just an extra step in the build process and another place that you could have to debug code. Today there have been some changes that seem to be bring this closer to a reality.

Why does it matter that Javascript is ugly? What else do you like to use that is ugly?  Nobody wants to buy an ugly car if they don’t have have to. Does an ugly house inspire you to do home improvement? I completely believe that ugly code leads to less productivity.  Even with the best syntax highlighting and linting you still find yourself struggling to find mistakes. Back in the day, I worked with a team of creatives and we needed a ticket system.  I went out and found the most functional system I could find with the best features and showed it to the Creative Director, my boss, and he said, “We can’t use that, it is ugly”. We found another system that was not as feature complete but had a much better design and we used it. A system is only good if people like using it.  I use an Apple computer partially because of the great design and clean looking applications. I think users these days put a high value on aesthetics and choose products based on that.  Javascript, as with many languages have adopted C-like syntax and that is not bad, but Javascript has added some interesting additions that have not helped clarify or beautify the syntax. Nested callbacks and anonymous functions have added solid functionality to the language, but have not improved the readability.  We are starting to see some improvement coming in ES6 and ES7 changes.

Likewise, the server side has always left me wanting. Node.js has been the main player in this space and has been adopted by many and it used in production by some large companies like Walmart and Netflix.  It is also intended to be more then a web frame work, being use in embedded applications such as robots and is one of the main tool kits for the Arm based Beagle Bone single board computer. When I would look at frameworks like Express.js I would feel like I was back in my early PHP days were you really rolled your own data layer and build tooling. Node has had success working with modern web features like Web-sockets which has been a bit of a challenge for tool kits like Rails. When looking for solutions to some of these issues, I found Meteor.js.

Meteor is a new framework that takes a different track then other Javascript frameworks that I have looked at. It has a few key features that caught my attention like real time data push, clients and server side coding support with a common API, as well as a solid set of tooling. This was the first JS framework that I reviewed that I didn’t have to spend time learning multiple different frameworks/components to make a complete web application. Every time I would get started on a new project I would have to figure out the data layer, service side language, client framework, and how to maintain build versions/database changes.  This was something that was daunting when getting started and Meteor has a clear story on how that can be handled. Meteor is opinionated and does have some limitations which won’t make it a ‘be all’ framework, but if it does fit your requirements, it could be a great tool.  We will get into more details in later posts.