I’m trying to learn Meteor by first going canonical before I dive into any books or tutorial that may use a non canonical approach. Since these books are all written for Meteor 1.2, it seems wise to use 1.2 for now. But how can you force meteor create myapp to use version 1.2?
Add --release 1.2.1 command line param? Or if that doesn’t work, add that same param after you’ve created the app, calling meteor update.
Though, I should add: There’s nothing in 1.3 that is not backwards compatible with 1.2. At least for web, I’m not entirely sure about mobile. So anything that has been written for 1.2 still holds true for 1.3. 1.3 brings a few new ways of doing things to the table, but you can completely ignore them initially and that will not bite you.
Whoa, you just scored a hat trick…right on all three answers. And scored again for a fourth overtime goal for replying so quickly on Saturday evening. As a total newbie, this gives me a good feeling about the Meteor community so far. Thank you.
When you say “seems to reload”, are you getting the console message Server modified -- restarting..
or Client modified -- refreshing
Do you have your code in the /client folder or are you using Meteor.isClient to split the code up? If you are putting code files in the client folder, changes to them shouldn’t result in server restarts.
In my experience, Meteor 1.3 is faster at reloads than Meteor 1.2; in either case, however, it will unfortunately be slower than something like Webpack due to the way the current build system works.
What Nathan said. Make sure to separate client and server code by putting them in client/ and server/ respectively (and shared code can live elsewhere, that’s fine), so you’ll at least save yourself the unnecessary additional reload time.
But yes, the reload times are still super slow, even with Meteor 1.3. That’s quite unfortunate as it makes development potentially a lot less enjoyable. (At least that’s my experience.) Here’s to hoping that the core devs are going to figure this out sooner rather than later, or that someone from the community takes charge of fixing that.
(Meteor is still an amazing platform, and is on an excellent track in its development.)
When you say super-slow, how slow are we talking? For me, reloads are really fast when there aren’t too many files in the project, and I would assume that that’s hexatonic’s case, so I suspect there might be something else that’s wrong.
Yeah, it’s quite fast when there’s very few files / packages in the project, I can confirm that.
When I said “super slow” I meant something like 10-seconds-slow. Which isn’t horrible, but not a pleasant experience either when saving & reloading a lot.
But yes, good point. With a small project OP should not have these kinds of reload times. Though I suspect that he won’t have them (any more) once they’ve properly separated client from server code, which seemed to be the original issue here. If that does not improve the situation then yeah, there might be another problem lurking
EDIT: I want to add – I don’t know how the 1.3 build responds to pulling in lots of packages from npm or Atmosphere. It might be that even with very little actual project code and many 3rd party packages the reloads would be slowing down a lot already. Haven’t done much Meteor coding lately.
Hi folks, I jumped back to Python / Flask for now because I just couldn’t find node libraries for the things I need. It’s been such an eye opener learning Meteor, though. Combined with Coffescript and Jade, I was able to build a web app very fast without having to deal with the unpleasantness of coding in ecmascript. I’ll be returning to it if I ever need a standard use case web app, but for now, I need to be able to run pandas on my server for number crunching. Thanks for you help.
Perhaps a micro services architecture to combine the power of python for analytics on the back end and Meteor for front end might be the way to go.