Is
It all started at a Hackathon in Mai 2015.
I wanted to realize my idea of a Pricing Research Application based on heavy quantitative magic (i. e. discrete choice analysis).
My weapon of choice then was AngularJS + Java Spring. I downloaded a boilerplate example for all the authentication and screen flow and within 12h I had the demo ready:
Half a year after: I was not so happy with the complicated spring auth, oauth troubles. I thought: if I can do that in Java in 12h how long will it take with the so apprised Meteor productivity? It seamed exciting and solved my auth problems because of Meteors good support for that
Gee, I made one big mistake here. It took me at least a man week, and I blame Blaze, Hot Code Replace and some nasty quirks in the minimongo framework.
Blaze: For a seasoned Java dev like me Angular was so much fun and easy to use, but Blaze? The helpers are always juggling to get the template data. Sometimes your out of scope sometimes not. Iron Router is part router part controller. You do database operation on it! When I discovered that reactive programming does not equal two-way binding, I startet to regret to not have used AngularJS at the first time. But the Meteor comunity says: 2-way binding is overrated. Certainly it makes my life easier.
Hot Code Update: Slooow. Either you have strong typing or you have fast debugging cycles. Java has hot code replacement too and its as fast as the Meteor stuff. Because of perfect tools support I can be more productive in Java than in Meteor. I tried 1.3 for a moment but it was not faster.
Minimongo or general js support: for example you never know if {id: myid} works or you must fill in a javascript map and pass it to the Mongo thing. Combined with the Hot Code slowness to get such quirks takes hours.
My anectotal comparision for building the same app:
Actually, to be fair, Google say two-way data-binding a performance hog that leads to UI state that is hard to reason about, so they’ve dropped it from there next release (Angular 2), as have Ember and of course React never had it in the first pace for the same reasons (this is a good brief discussion on that http://stackoverflow.com/questions/35379515/why-is-two-way-databinding-in-angularjs-an-antipattern?lq=1).
Routing wise, mixing data-retrieval into the routing is not recommended anymore in Meteor, template level subscriptions are the way forward.
You’re right about the slow rebuild time, that is frustrating - using React may ultimately make this easier as the community already has HMR working with Meteor which speeds things up a lot.
In general though, reading your post it kinda sounds like your comparing the amount of time it took you to code a project in a toolset you knew well (Angular 1.x and Java Spring) to the time its taken to try and simultaneously learn a new framework and code a project in it, which is obviously not a fair comparison.
It also sounds like you may not be looking at the most up to date documentation as some of what you are doing is not best practice and some of the issues you are having are more easily understood with a fuller understanding of Meteor. You may want to look at the official Meteor Guide if you haven’t already.
@rolandk I am coming from a javaee background myself, but instead of hopping on the angular train, I bet on facelets and a few good jsf component libraries first, with spring in the mix for the overall app architecture.
Then I moved on to the awesome play framework which removed boilerplate hassles and introduced hot class reloading.
But when I discovered meteor - and it was 3-4 years ago, a time documents and examples were scarce, I immediately got hooked because of the productivity.
I can honestly say that a spring app and an angular frontend that would take me 12 hours to build, would perhaps take me no longer than 2-3 on meteor.
In your case, you already have the option to build it reusing your angular skills instead of blaze.
But it is perfectly normal to discover meteor today and be overwhelmed by the number of choices, the extent of abstractions (and complexity) you can achieve if you wanted to.
If you want to go back to the basics, though, which I think you should before moving on to advanced concepts,
are great resources that are really easy to follow and skim through in a matter of hours.
The official meteor guide, as @tomRedox has pointed out, is also a great source of information in terms of application design guidence and best practices.
If you are seriously evaluating Meteor as your tool of choice, let’s keep this conversation going and let’s get you there.
As a person who prioritizes productivity a lot myself, I agree with you. If you find coding with Angular a better, easier and faster experience, by all means use Angular. Meteor+Angular combination works pretty nice. If you find Angular+Java combination better, because you have years of experience with Java, by all means continue to use it. Whatever works better for you, is a better option.
But on the other hand, as a person who came to Meteor from Angular a longer time ago, I’d blame most of what you write on lack of Meteor experience and knowledge. Just a few examples:
The official Meteor recommendation for router is not Iron Router, it’s Flow Router. You can read about it at http://guide.meteor.com/routing.html. Flow Router’s only responsibility is to be a router. All the rest you do in your templates.
2-way binding with Meteor is even better than with Angular. Check out http://viewmodel.meteor.com - it’s Angular on steroids.
You can’t really blame Blaze for having different scope than Angular’s $Scope, which has been so much complained about that Angular dropped it for Angular2 together with ViewModel.
As for “Sometimes you’re out of scope sometimes not”, it’s all explained in the Meteor/Blaze/Spacebars documentation. But if you want to always have the same scope, again use http://viewmodel.meteor.com - it keeps the same scope everywhere, it also makes helpers more convenient to use, if you don’t like the juggling.
I don’t find myself having such problems. When something doesn’t work for me, I usually know why, because I’ve already encountered similar case in docs/guide/issues, I’ve read what other people had problems with on forums/SO/slack/gitter/irc or I’ve digged the source code so I know how a particular thing works internally. If I don’t, I repeat the cycle and I find the solution.
Thank you, Tom, Serkan, and Brajt for your contribution. I already learned a lot from this thread
Tomredox pointed out the performance hog that two-way binding is. Fingers crossed because I’ve a pretty complex Angular app out there, taking 40 MB of Heap and its still working good.
Serkan guessed the productivity increase in his opinion is 4 times bigger compared to my Java stack, and that the many choices make meteor hard to begin with.
Brajt gave me this promising Viewmodel stuff, which I think I will incorporate into my app and a hint that I may have picked the wrong routing lib. But it’s too late I think to change to flow router.
Iron Router was popular 1-2 years ago because there was no alternative. In the spring of 2015 Flow Router debuted to address Iron Router’s issues, with the one you mentioned among them, and since then it became an official Meteor recommendation for a router. I wouldn’t say it’s difficult to make this switch, and it’s definitely not too late, after all you just started recently.
As for two-way data bindings, I use manuel:viewmodel in all my projects and it works great, so if you miss this feature from Angular, go for it.
@rolandk a few of us gathered on a slack channel to discuss everything meteor. also, every week, we do a live hangout where the more experienced of us answer questions others may have.
Here’s a whole thread about what we’ve been up to.
I think Meteor really hits its stride in productivity once you select the right tools and packages from the community - if you pick the wrong ones that are either not recommended or worse not maintained, you could end up in a tough spot. I think some more mature platforms like Java and Angular have more clear winners in important categories.
Maybe someone can help maintain a TL;DR version of the Guide? Like, things you absolutely need to know when you start a new serious production app in Meteor? It’s clearly unreasonable to suggest that you should read the whole thing before starting a serious project, but I think MDG will bring the most value by maintaining the detailed version vs. various getting started guides and resources.
Nah, I actually think reading the whole guide from A to Z is worth it, for anybody who’s not only starting a new serious production project, but starts learning Meteor at all.
But I’ve been thinking lately about a guide with short tips in the form of FAQ. Sadly http://faq.meteor.com is taken, even if not used anymore.
How do you guys approach the biggest downer, which is browser reload, hot code replace during development, you name it. I saw the promising Webpack package, and I wonder if you use it? Or have you found other solutions to it?
Webpack kickstarter is for React. There are rumour that in theory it could work with Blaze but as far as I know it, nobody confirmed that he managed to achieve it.
I use 1.2-faster-rebuilds.0 which has similar rebuild mechanism to 1.3. It made my rebuilds much faster than before so I’m very happy with it.
How do we approach it? We get patient. Patience has been a key feature of every programmer since the 50’s.
I think that the addition of testing to Meteor in 1.3 has a big role to play here. I come from a TDD .Net background. In that world I very rarely run code in the browser, I simply build tests that are automatically rerun in tenths of a second whenever code they cover is changed. I then write my code as pure functions that takes inputs and produces repeatable outputs. That’s faster than even hot code push and then has all the benefits that tests bring too.
I’m going to start digging into 1.3 testing this week, I’ll let you know how it goes.
It sounds your unfamiliarity with Meteor hurt, but of course it will.
Here’s my anecdotal point:
I had a proof of concept app done in 15 minutes, that would have taken at least 9 hours in something like Rails. Using React and MongoDB, nothing eccentric.
Keep truckin’ with Meteor and she’ll do right by you, believe me.
