Current Web App Tech Stack

At work, the product I currently work on uses PostgreSQL and Ruby on Rails 4. It was started well before the current front-end craze, so the front end is basically a mess of JavaScript, jQuery, and the ERBs that Rails provides. There’s been a push to move the front end to Angular 2, which seems like it’ll be a massive improvement over what we have now.

My impressions of the current stack:


PostgreSQL is awesome. In the realm of RDBMSs, PostgreSQL certainly seems like a top contender for the “prosumer” market. Every time I’ve seen a “MySQL vs PostgreSQL” comparison, modern PostgreSQL has slapped MySQL about. Also, MySQL being backed by Oracle is instantly a turn off for me (Oracle sucks, don’t you know?). I’ve only used MySQL in passing, and Oracle DB even more briefly than that, so my opinion is grounded in almost nothing but looking up internet articles. I managed the transition for my work’s current web app from MySQL to PostgreSQL (mainly for licensing concerns) and there didn’t seem to be a huge difference. MySQL’s historical lack of a first class boolean is a bit of a pain. It’s harder to reason about when *probably* that tinyint(1) is a boolean, but you’d best make sure…

Application layer

When I first started working in Ruby on Rails, I had a pretty strong aversion to it. I came from a mostly Java background with a tiny bit of C++, C, and Python. Syntactically, things like not explicitly calling “return” really threw me for a loop. Right off the bat I thought “how do you know whether the function just does something or whether it returns something?!?!? You can never trust any functions’ return value again!”. I have really come around on that particular issue – the explicit return provides very little meaningful value from my perspective in terms of both development and maintenance. You never really call a function from your own code without understanding what its doing, and you don’t refactor without considering breaking changes so it just never comes up. That said, I also never felt like typing “return” was bloat, and now there’s an inconsistency between early returns and regular returns, so while I don’t think it’s a black mark, I’m also not convinced it’s any better. Not having return types on the other hand…

Now I can safely say that I love small pieces of Ruby. The collection operators are so very terse and useful, it really showed me how much a language depends on them. Their implementation within Java with the .stream() function and all its bloat just seems cumbersome by contrast. Functions as first class citizens just makes for better code. No I don’t want to create a SortingStrategy interface and then pass in a concrete class which implements it – I just want to pass in a method. Go away needless layers of abstraction!

I can also safely say that I despise Ruby. I didn’t realize that something like an interface was such blasphemy. Heaven forbid I want two separate implementations of a concept adhering to the same API to be kept in sync. Don’t even get me started on enums. Obviously I wanted a typo in that symbol I had to type out in 20 different places to make it all the way to production – who wouldn’t? One of the daily pet peeves though is how I feel constrained with naming in Ruby. The lack of polymorphism leads to either gross looking function signatures, or resorting to something like repeating the parameter in the method name. Additionally, if you ever have any desire to refactor anything on a large scale, don’t even think about naming methods with common words. Thinking something like “find” or “valid?” would be a great name? Good luck changing it later! You’ll curse as you manually curate the list of possible invocations your IDE has presented you with. I constantly find myself resorting to string searches, which is a terrible sign.

I don’t have particularly strong opinions about Rails. It definitely gets you up and running quickly. At first I was upset with all the magic – “how am I supposed to know that if you name it like this, then this other file way over here is magically attached?”. The first time I had to debug having pluralized a name I definitely did not say anything nice about Rails. Then I had some exposure to the alternative – explicitly linking the TypeScript, CSS, and HTML files in Angular and I thought “they’re all sitting right there next to each other and named the same thing, why do I have to spell it all out?”. So there are definitely downsides to both strategies, but I personally find I don’t mind the “bloat” as it pulls back the curtain and there’s less magic, and I think automatic code generation hits the sweet spot in between the two. Code generation with tooling support to keep it out from under developers’ feet seems like it’s better than both options. I have my issues with how rails treats all models as mutable and ActiveRecord in general, but I haven’t seem something that is obviously much better, so I’ll reserve judgement.

All in all, I think Ruby on Rails is great to get going, but painful to maintain and scale up. If the app is a continuous project and not a “build it and move on situation”, I couldn’t recommend it. There are just too many avenues for bugs that could have been solved by static typing.

Front End

The unstructured world of old-timey terrible JavaScript and jQuery mangling HTML is awful. Throw in some Rails ERBs for even more inconsistency and it’s a giant unsustainable mess. I’m sure the technology *could* be used well – built in a sensible fashion, relatively decoupled and scalable. It’s just not, in my experience… Historically all of the “real work” has been done on the server side, so the client side hasn’t gotten the focus and rigor it needs. Definitely there are people who can write excellent client-side code with JavaScript and jQuery, they’re just few, far between, and likely underappreciated because people see “the button is more red than I’d like” and not how easily that button was integrated with the rest of the app due to well structured code. The web app I work on is definitely larger than a personal project, but it’s not *huge* by any means. It makes me wonder what the massive websites using similar technologies did. I suppose a lot of that is that nobody was really a professional JavaScript developer where I work, and code written by people who are learning as they go is never going to age well.

Angular is a conceptual change and a technology leap forwards for my work’s application. That said, I’m not totally positive it was the right step. The goal is to slowly transition from Rails powered front end to Angular powered front end. That makes a lot of sense by itself, but the entire transition period is a pretty gross. Angular and Rails don’t go together particularly seamlessly, as there is quite a bit of overlap between the two. First of all, it should be a no brainer that a technology built to support single page apps is at odds with the very not-single-page-app model that is Rails. So how do you address that in terms of deployment? It’s hard to go one page at a time when it means that every time you navigate off an Angular page and then back its essentially restarting the application.

I really like what I’ve seen of Angular so far, and it makes a lot of sense to me. I’m looking forward to compile time checks of the template code that is allegedly coming in Angular 3, as I *hate* the magic string matching that shares so much with Ruby and Rails. Other than that, it seems like client side development is finally starting to mature to the point where frameworks can hit it big even when they impose structure and opinions about how to do the work.

I’m excited to work with it more on my own!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s