The companion site to a book and tutorial for the Meteor JavaScript framework, with posts on Meteor's state and direction.
HN commenters recommend it as the best starting tutorial for Meteor, calling it more useful than the official documentation.
Good question. I struggled when I wanted to try some API sample code and I had to start by configuring Yeoman, brew, and whatever other infrastructure just to get to the point of being able to run a "simple" sample.
I have also been to 4hr workshops where 3 hours was taken to help students get setup with whatever environment we were there to learn. It would have been trivial to setup remote VMs.
An even more interesting question is how to keep tutorials executable as the underlying technologies evolve. This is a big problem with older books where code doesn't even compile. Microsoft Press is especially notorious for this.
I agree that combining technologies does not make sense. There is one very good approach I've seen used by the Meteor book team. I will use the same approach for writing tutorials for my technology.
The entire book is valid Meteor code. As it evolved and broke compatibility between 0.8 and 0.9, the book became outdated. However, the team continued to evolve the code.
Their approach was centered on checking out the next branch instead of typing it manually as you read. As you start reading next code listing, you can type "git checkout chapter4-1", for example. So, as the code would evolve and no longer function with latest version of the framework, they would update the branch tag and it would magically work again.
Although the code hasn't been updated since 2017, you may find it very interesting. If you run it with that era's Meteor, it will still…
Ember.js 1.0 was release in 2013. The udpate pipeline strictly follows the Semantic Versioning standard. There is a new minor version every six week. Backward compatibility is extremely important. Ember.js 2 was released middle of last year, the transition from v1 to v2 was super smooth. Big startups and corporates (like financial companies) are migrating to Ember.js, because of the stability and because of the opinionated, convention over configuration features. An Ember developer can jump in someone else Ember project immediately, because most of the Ember.js app follows the same principals and rules. This is a good video about how Intercom.io was able to ship new features much faster and more often because of they switched to Ember: https://www.youtube.com/watch?v=fVwDuMGVhYY&sns=tw
I read this article about Meteor recently. https://www.discovermeteor.com/blog/the-state-of-meteor-part-1-what-went-wrong/
Looks, they have to find a new way. It is kind of the same story as happened with Angular, the Angular 1 was a cul-de-sac and they had to build up a totally new framework from scratch.
Meanwhile Ember adapts the best solutions all the time. Ember begun to use ES6 almost two years ago. Implemented React inspired view layer a year ago. Server side rendering just released a couple of weeks ago. Ember-cli stable version is released a year ago, which is so good, that Angular 2 would like a similar cli tool, and of course Ember-cli team helps them. Hopefully Angular 2 will…
I've been working with the framework almost daily and regarding your comments:
1.) Yep. I've gone from a jQuery-mostly front-end dev to being able to build full blown apps inside of 6 months. Not only that, the apps run really well.
2.) Incredibly. Even without the meteor.com service, it's super easy to deploy using things like Demeteorizer (https://github.com/onmodulus/demeteorizer) which strips down a Meteor app to a raw node.js app that can be deployed anywhere (that supports node, of course) in < 2 minutes.
3.) My favorite part about the framework is that the core devs have meetups/hackathons frequently to talk about progress on development, show off demos of pre-releases, and allow community devs to showcase their own work (if you're curious, I highly recommend checking out the Devshop videos: https://www.youtube.com/user/MeteorVideos?feature=watch).
Even if it doesn't sound like your bag of chips, at least do what the OP did and check out Discover Meteor: http://discovermeteor.com. It's worth the day or two it will take you to complete.
Project developer here.
The library is not new, it's actually been around for almost two years, but I've just pushed 2.0.0 and realised I never did a Show HN on it before.
In the past few weeks I've seen a lot of talk around Meteor (spawned in part by Sacha's posts[1][2] on the state of the framework), so I thought to share what is my practical take on it.
I never liked Meteor too much as a full-stack framework, but I found it fantastic as a real-time API server, a fully open source alternative to services like Firebase. In this regard, Asteroid is basically a js sdk for Meteor.
At my current company we've been using Asteroid in production in several projects, so I'd say its functionalities and utility have been battle tested. :-) Feel free to play around with it and ask questions!
[1] https://www.discovermeteor.com/blog/the-state-of-meteor-part-1-what-went-wrong/
[2] https://www.discovermeteor.com/blog/the-state-of-meteor-part-2-what-happens-next/
About joins in subscriptions, other than the community package Publish Composite, there is an officially supported alternative yet very poorly documented or mentioned, using the Spacebars layer: It is the template helper argument feature, which is in my opinion must more reliable and developer friendly, you can read about it here: https://www.discovermeteor.com/blog/spacebars-secrets-exploring-meteor-new-templating-engine/
A typical example would be to display a "post" with comments from two different collections:
Template:
<template name="posts">
{{#each post}}
{{title}}
{{body}}
{{#each comment _id}}
{{username}}
{{body}}
{{/each}}
{{/each}}
</template>
Helpers definition:
Template.posts.helpers({
post:function(){
return Posts.find();
},
comment:function(post_id){
return Comments.find({post_id: post_id});
}
})
I think it depends a bit on what you want to build with it. It's turned 1.0 and seems stable and you can make stuff like http://illustreets.co.uk/ with it. (see https://www.discovermeteor.com/blog/illustreets-mapping-the-uk-with-meteor/)
It doesn't seem designed for large complex things though. Postgres support is on the way. I've been playing with it and trying to implement uploading profile pictures and that's quite hard. The standard thing in Meteor seems to be to offload the job to someone else's server probably running PHP. It's fun to use, I recommend playing about and trying to build something.
Josh Owen's talk is quite good on the business case for it. His company has built 40 apps using it, he says they tend to take about 6 weeks vs 10 for Rails.
https://www.youtube.com/watch?v=JOpPG6kiud4