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.
My anectotal comparision for building the same app:
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,
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.
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.
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.
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?
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.