My experience trying Meteor 1.3 beta-5 - it ain't pretty

Guys, it ain’t pretty. And it isn’t Meteor’s fault.

I just attempted to create a simple Meteor app with the 1.3 beta-5 version. Ok, cool it updated, installed and ran without problems.

Next step: Installing my data-layer package: Astronomy. Uh… lots of undefined errors. I need to export from somewhere, and import {something} from {somewhere}. Ok, two hours wasted there. I’ll look at it tomorrow.

Next step: Adding React. Uh… do I add Meteor’s react package? Nope, no dice. Should I google the official react npm module? Ok, npm install’d that sucker, now how do I integrate it with FlowRouter.

and so on and so forth


  • Where is the Meteor stellar developer UX?
  • What happened to my developer happiness? I used to feel so empowered with 1.2.
  • What will happen with all the packages that import to global? Nevermind packages that use Blaze, what about backend packages?

I have faith in MDG, but I honestly don’t see myself using 1.3 unless something is done about developer happiness first and foremost. I don’t mind modularity but this is tedious, just boring gruntwork.

In the meantime: I will continue to hustle with 1.2, Take Care of Business, and enjoy the freedom Meteor 1.2 gives me right now, today.

3 Likes

I think you answer your own question :slight_smile:

Meteor 1.3 is still beta and we are searching for patterns and how to build apps with it.

When it’s the time for general availability, you could have solid ways to build apps with it. And migrate 1.2 apps.

That’s why we have meteor 1.3 as beta. So, complaining MDG or meteor about that’s not fair. It’s not the final version yet.

We are working on some patterns to use React with Meteor 1.3. I will publish a blog post on this today on Kadira Voice.

EDIT: Here’s the blog post I’ve mentioned. Using Meteor Data and React with Meteor 1.3

14 Likes

Complaining about a beta app is like complaining about a car that has not even made to the factory production bands yet, let alone be driveable.

It is only for Meteor developers (not Meteor users) to work with/on. Do not try to use it in an actual project. It will become an epic fail quickly.

2 Likes

The point of a beta is to allow the users of product x to give feedback. The whole point is to complain so pain points are identified.

I don’t think I’m being unfair, just stating problems I had with the 1.3 version on a very simple Meteor/React app. Hopefully they use this feedback in some way.

2 Likes

A lot of packages won’t work on the beta yet. It is still being developed and I imagine that the Astronomy maintainers haven’t given the beta a look yet. Wait for MDG to make everything backwards compatible.

The default in the future will be: Install from NPM if you can. Those versions are mostly more up to date and we finally don’t need to make all those useless wrapper packages. Hooray!

If you ever have installed an NPM package before you know it is as simple as:

npm install react --save

Can’t tell me that is harder then:

meteor add react

The beauty is we can now install all possible react packages from NPM. And not just react but also moment, express, highcharts and all the other amazing stuff available. Hooray!

Good, now be patient young grashopper, a bright future is up ahead!

I’ll admit that the betas have had some rough edges (and sometimes they looked more alpha then beta), but it’s getting there. By default everything should stay the same, but now packages will mostly be installed from NPM. We’ll get modules, better testing, new es6/es7 features, better Cordova integration, they are working on performance improvement and everything should be backwards compatible (because MDG promised that from 1.0). Hooray, hooray, hooray!

They still have a month to improve everything (according to their own meeting notes), so let’s give them that time.

Using the text “it ain’t pretty” in your title is your opinion and putting oil on the negativity fire. Do people (like me) who do find it pretty have to write a blog or forum post now just to compensate this?

9 Likes

I agree with the calls for patience here. It’s early game for such a drastic change (might even have warranted a major version upgrade to v2.0 perhaps?).

I’ve had a brief look at beta 4 and though I have no problem using npm packages, I got a bit stumped by how I’m suddenly supposed to use import and export when before Meteor just figured that all out for me.
But that’s likely just me being a noob, so I figure I wait until 1.3 is finalized and all the good tutorials have been updated to demonstrate what exactly is happening here.

Until then, I do feel like holding off investing any further time into 1.2. Not because I always wait until the newest version is available, but because even noobie me can see that the direction 1.3 is going towards, is where the future of Meteor lies, and it is a bright one.

2 Likes

Note that you don’t have to use import and export if you don’t want to - previous meteor code works just as before. You have to opt in to modules by putting your code in the ‘imports’ directory.

@sergiotapia have you tried just not opting in to modules? If you like the auto loading functionality, you can still use that in 1.3, and you can import NPM packages as well.

2 Likes

That sounds like a great approach to me, but I couldn’t find any info on that specific workflow. Are there beta Meteor guides somewhere? I would like to only import things such as external npm modules (momentjs, limax, etc) and keep core things autoloaded such as React and the ReactMeteorData mixin.

Edit: And if there’s not any guides that’s cool too. I can keep working on features with 1.2 just perfectly. :slight_smile:

It works exactly how you expect - take a Meteor 1.2 app, upgrade to 1.3, NPM install something in the root, and then import or require it anywhere in your app and it just works!

3 Likes

I’ve only tried beta4 but it has been pretty flawless for me. I just needed to uninstall react and add meteor-react-data, and tweak a react to blaze custom package that I made. I used the Browserify exports file to require from NPM instead and they now are exposed so I don’t have to make imports right away (for other files).

Something that might not be apparent at first but the more packages you depend on the more pain you’ll have in these situations. I learned this the hard way when adding several packages that added a lot and I only used 1 or 2 functions from it. In retrospect I should have either written it from scratch or based it off of the plugin. This maximizes the maintainability while trading off initial development speed.

1 Like

I’ll try this out. I thought it was an all or nothing approach. Good to know!

It is disingenuous to present R&D as beta - beta 5 to boot!

I don’t see the issue… they are allowing people to try it and report bugs, which helps it release faster. You shouldn’t use it in production, it’s only released to get a preview and to help squash bugs.

6 Likes