Meteor, a Web Design Journey

23 Mar 2017

First Impressions

I think I made it perfectly clear when i began working with meteor that I thought it was complete garbage. I recognized it to be perfectly managable, but in a world where hundreds of frameworks exist it’s hard to sell something on being only managable. My initial reactions were formed by a lack of understanding of certain facets of the framework. To some extent I still have these issues, but have found the underlying cause to be a flexibility that is both endearing and useful to spagetti code my way through certain issues.

When I first began learning Meteor I didn’t quite understand it. There isn’t a great teaching tool for meteor and that is because it is so interweaven. I now understand it and am still occasionally met with war like flashbacks of my first few hours with the system. While not being a strict requirement of any good framework, being able to have a simple structure to teach people piece by piece is handy. It’s 2017, and colleges teach students java and python first for a reason. Machine code can be amazingly optimized, but why should someone learn memory managment before being able to write hello world.

Current Impressions / The Change

I’m not sure where the realization of how to use meteor hit, and I’m not entirely sure it did hit all at once. There was a point where I was copying code and then a point where i was writing out applications like without a single reference and strangely there was no inbetween. Perhaps this is a compliment to meteor or perhaps a compliment to the learning system used. Either way I now feel confident enough to state my current, and probably to the death, thoughts on meteor.

I’ll start nice enough, since few can honestly believe this is going to end with love and rainbows. Meteor being perfectly manageable was a reoccuring theme throughout development with it. I recently was introduced to a few websites with pre-made packages in it that made my day. One of my earlier arguments against it was lack of support but after some more research I found myself to be completely wrong.

Wait…

As I sit here trying to think of more things to write to show how well meteor works, I keep hitting a wall. I keep wanting to give it small compliments but whenever I try, I realize that the compliments are misplaced. All of the benefits of Javascript are because of Javascript. Autoreload is nice, but i actually found it to be more inconvenient than manual compilation. The number of times I was working on a page and repeatedly saving only to go back to the console and find that compilation was backed up by 20 something changes was insane.

Furthermore anytime I want to include a script into my website I have to determine what kind of script it is. Is it a helper? Is it something else? This seems trivial and it is, but enough frameworks don’t have this requirement allowing you to just write the function and call it in the page where needed.

Don’t get me started on the speed. Anyone who has used meteor knows how ridiculously slow it can be. This isn’t just a personal problem, meteor themselves recognized this. Rendering once the page is loaded is generally fine (if it wasn’t this would be a much bigger issue) but loading a project and compilation in meteor is abysmal. I know that they are working on a new version but “working” on it doesn’t make it go any faster in the short term.

Final Verdict.

Do I like meteor? Yeah, it’s fine enough I suppose. While all my examples take it to the extreme, I honestly don’t have a giant problem with it. It would never be my first choice but if a project requires it I wouldn’t snub my nose to it.

Meteor: 5/10 average.