Old Meteor approach

blaze
1

Hey guys, just coming back to try out Meteor after a year or two away and the world has certainly moved on!

While I totally understand the move towards explicit imports, a huge part of the appeal with Meteor for me used to be how fast it was to prototype an app, how I could use Jade, stylus, coffeescript etc and the code was incredibly easy to follow. I was picking apart an old app and it was just incredibly efficient, close to zero boilerplate.

I’m just wondering if the “old approach” is still do-able? In my short trial, I was having issues with FlowRouter/BlazeLayout not finding templates - I really don’t want to have to import my template files into a JS file just to show a view, it just seems to go completely against what I used to find appealing about Meteor.

I think if the old approach is still workable, Meteor is still a great prototyping tool, if on the other hand all the code is going to become lost in a sea of import statements (even for including a simple template), then at least in my opinion, I’d find the completely decoupled approach of using an API with a separate frontend actually simpler than Meteor, which is a shame as I used to feel the exact opposite.

I completely get that this is just my personal feeling, I totally understand the reasoning for the more modern approach but the enjoyment of coding in Meteor has somewhat been lost on the way.

2

I’m on Meteor 1.8.0.2, prefer packages over imports, CoffeeScript over JavaScript (at least until it supports optional chaining). It works the same as pre 1.3 versions only a lot quicker. If you get errors they should be solvable, imports are completely optional.

3

Thanks! I think I’ve found out you have to remove the “meteor” part from package.json. Is it as simple as that?

2 Likes
4

Using imports for everything is definitely still optional! I tend to only use imports within a package, but not in the top-level client/ folder. And I keep almost all of my templates inside the top level client/ folder.

Imports/exports can be convenient, but is annoying and unnecessary when building Blaze templates. Load order doesn’t really matter for Blaze templates!

4 Likes
5

Thanks that’s good to hear! I was wondering if there is any official guidance/docs on the topic? Reading between the lines it appears the “meteor” settings in the package.json file excludes the eager loading behaviour? If so that might be a nice way of pleasing both sets of developers?

6

Yeah, that’s exactly it.
That way existing projects retain the old behaviour and the template for new projects includes the "meteor" part to more closely match the prevailing style in the broader JS community

1 Like
7

i had a similar question a few weeks ago (Classic Linking). Yes i removed the ‘meteor’ part to migrate an older app from v1.3 to 1.8. I still needed a very few imports and a few tweaks to get it going, and some older packages no longer work. In particular I use Collection2, and simple-schema is now an npm package I needed to import. It also needed a few schema changes, but as I have about a dozen apps im migrating from 1.3,the process to migrate and maintain ‘classic linking’ was quite straight forward.

2 Likes