From working with Rails over the last couple of years, I have become increasingly aware that the problem that server-side frameworks such as Rails are trying to solve are not the framework challenges that application frameworks will need to solve in the future. With the rise of component specialisation and service oriented architecture as well as the Node/io.js technologies bringing the dream of isometric application design to a new reality, it occurred to me someone really needs to write a framework that both shared data models whilst maintaining a strong service architecture. Needless to say I was impressed to discover that with Meteor it had already been done.
So I have decided to give Meteor a whirl and share my experiences live as I get to know the basics of working with Meteor by documenting them in a few blog posts.
Simplest bootstrap ever.
I am astounded as to how simple it is to get a demo app going:
1) Install the cli:
https://gist.github.com/ryardley/055e3e9ba16d6f28511c
2) Create your app:
https://gist.github.com/ryardley/349a1d6dc66f0d4814a6
3) Start your app:
https://gist.github.com/ryardley/4c32e719586f45da009c
Then surf to http://localhost:3000 and you have an app.
So whilst I do certainly plan to write mainly awesome button click tracking apps for the rest of my foreseeable career, before I retire to the fridge to crack a cold one and admire all my fine handy work it might be intellectually stimulating and enlightening to have a little poke around at what has just been done by this this runtime in my name.
The app structure.
Let's load up the folder into sublime and poke around:
As you can see Meteor has created the 'app' files:
- myapp.js
- myapp.html
- myapp.css
These files look like stubs for js, html and css respectively and assumably where the differentiating components of your app that make it your app are created. Meteor also seems to have created a '.meteor' folder which looks like it has configuration files and MongoDB files as well as a build folder that meteor probably runs a node server and serves out of.
One file defining both client and server.
The most striking thing about looking at this generated code is the way in which the JavaScript file generated appears to have been defined to run on BOTH the client as well as the server. Initially it's seems to me to be a little awkward to attempt to separate the two using a simple flag to tell us not to run the server code on the client and vice versa but thinking about it I can see some power with including the same libraries into both as you write modules that span both client and server and represent slices of functional interaction. I am writing this knowing very little about Meteor so for me right now whether or not Meteor actually works that way remains to be seen so lets dive into the docs and checkout whats going on.
So if we have a look at the above link it seems like Metor uses a kind of Handlebars style templating engine called spacebars to do templating and I have just decided I want to build an app that lists all the most popular javascript github repositories instead of a todo app so I am going to try hacking my template to list the repo name address and stars:
https://gist.github.com/ryardley/69f710d19025de547a52
Add the HTTP Meteor package
https://gist.github.com/ryardley/0ec6555131ca38a299e9