Meteor is great! Why is not more popular?

Well, I wasn’t trying to single-out MySQL: the thread is less specific. However, as far as MySQL support is concerned “in-core”: are there any JavaScript frameworks which support MySQL without using an npm package? (That’s a genuine question - I don’t know the answer).

In Meteor, MongoDB support is through an npm package - granted, there is an isomorphic abstraction layer in there too - but an npm package does the heavy lifting and is written by Mongo Labs. Livedata is a feature added by MDG - does that make it more or less desirable?

There’s an “official” equivalent for MySQL which you can use in Meteor if you don’t need livedata.

I’m sort of losing the point here, which is that if you can do it in Node.js you can do it in Meteor. If you want Meteor Goodness™ you may have to accept that some of that comes from non-official sources.

5 Likes

Ubuntu Linux 14.04 running Apache. The Meteor apps, produced using Meteor Build, are deployed there. We can take this discussion offline if you like.

Thanks will give it a bash.

Meteor is not great, no web frameworks are great. Technology keep evolving every years.

On the technical side, we dislike Garbage Collector in Node.js as Java do. If there is a need for fastest performance, a bit of trick in Rust with assemble is feasible, useful for Big Data/Small Data.

Rust DDP talk to Meteor? Perfect!

https://raw.githubusercontent.com/tbrand/which_is_the_fastest/master/imgs/result.png

1 Like

Meteor is not great, no web frameworks are great. Technology keep evolving every years.

Meteor is not a framework. Its a platform / environment. It just happens to have some really awesome packages that go really well with today’s needs

In my opinion, Meteor has has lost its appeal to newbies (and speed of development) after forking (another pivot?) into database hosting company and flirting with Facebook/React.

If I remember the story right, the team was searching for a tool to build their travel web-site, and there was no such tool, and they pivoted into the development of Meteor. Would it be easier to build that ‘travel web-site’ with Meteor Meteor 1.0 or Meteor 1.2.1 or Meteor 1.4?

But it is still the one - number one - https://github.com/showcases/web-application-frameworks?s=stars ahead of rails and laravel and well ahead of expressjs

P.S. Just signed up for paid account for Galaxy and got lost in containers/DNS/etc. It is crazy even for me (returning beginner) even after 100+ hours of meteor to set up everything to see the results on the Web. The magic of meteor deploy is gone so it requires much bigger attention span to get the right results. I hope the tools like "Visual Meteor" coming soon :) will help to return the magic.

2 Likes

I agree that Meteor is a bit un-focused right now, or so you’d think if you still see Meteor as a closed system but saying containers/DNS takes long with Galaxy… seirously? Galaxy has way too little features and I’ve seen the entire interface in 10 minutes. There are barely a few settings for an entire app, most of them are one-click checkboxes, how can this possibly be too complicated already?!

1 Like

I do not mean Galaxy is hard to learn (enough features for me :slight_smile: ).

I mean that learning curve is dramatically increased when you have to go to mlab, register account there, go to galaxy, register account there, put configuration data into your project, and only then see ‘the real thing’. Magic is gone.

BTW, you keep your Windows configuration secret? :wink:

And is this a bad thing? Honestly, you need to sign up for an account, copy & paste a mongo string and you’re done. Your “magical” alternative is hooking up your database to your ubuntu server by default and having the fun of running all your MongoDB setup and maintenance yourself, including lots of fun with scaling issues. How is that more easy for production apps?

Sometimes copy & pasting stuff for 10 minutes can go a long way to safe hours in the long run :slight_smile:

PS: I use the most expensive Dell workstation laptop you can buy. I find it pointless arguing over things that are obvious ;).

2 Likes

Nobody says it’s bad thing. But it is no good for spreading community. People are not born advanced geeks.

Re: configuration: What a coincidence. I use Dell Latitude. Even if you are using Dell Precision, processor/memory/SSD and how Meteor uses them still matter, not money spent on workstation :wink:

The unofficial Meteor+Vue integration still offers more features out of the box and is better documented than official Rails+Vue integration.

Also the Vue+Meteor project is written and maintained by a member of the core Vue development team.

5 Likes

No offence, but frankly I don’t understand how 10 minutes of creating and account and copying and pasting mongo url is considered for advanced geeks? If that’s too complex, how will then they build and deliver a mobile or web app? there’re legitimate concerns and areas of improvement but that one I really struggle to understand.

2 Likes

Would it be easier to write a prototype in Meteor 1.0 / 1.2? Sure it would. Would it be easier to write a maintainable website that you can safely make your source of income? No.

1 Like

If it’s easy in Meteor 1.0, it’s identically easy in Meteor 1.2.1 or Meteor 1.4. Meteor is backwards compatible. If you liked the way you used to do things circa 1.0, simply keep writing apps that way. Later versions just gave a few more options to people who wanted them. The magic didn’t go away; maybe it got obscured a little.

3 Likes

With pm2-meteor deployment is really, really simple. Not as easy as it was with native meteor deployment, but it’s not complex

3 Likes

I believe Meteor is still very popular, I don’t think you can say it’s not popular. I would say that is has lost some developer community support and you might be feeling that.

Meteor is still pretty popular.

But honest answer - a couple events have led to people being a bit worried about losing Meteor.

First, there was a bit of a fiasco when MDG announced they were going to switch to React. That was eventually changed to supporting Blaze/Angular/React, but even after they decided that, some of the damage was done and people were a bit worried about future changes.

Then last year a somewhat similar situation happened with Apollo. There was a lot of fear of Meteor getting abandoned. Also, one issue that had a lot of people worried (including myself) was backwards compatibility as Apollo gets integrated in to Meteor. This brought up a lot of potential issues, starting with having to do import statements, to atmosphere packages, and so on.

MDG has stated we don’t have to worry too much, and so far that has been true. But I do believe any users with a large Meteor project probably do have a bit of worry about this. Huge refactors are never welcome in most projects. But so far there’s been no major issues.

Prior to these 2 events, Meteor had a LOT of steam, and I seen a LOT of people talking about it positively.

I think once MDG is past the potential refactors, it will be a great time for them to step up advertising and bring Meteor back up. Because the main issue (both times) has always been users feeling “safe” working in Meteor. Feeling like they have not been forgotten, or abandoned, after supporting Meteor through the tough times.

It’s a hard balance to be simultaneously welcoming to new users, supportive of your current community, as well as developing the platform/framework with modern features that will keep Meteor appealing in to the future.

(Oh, one thing I forgot to mention, the update a little over a year ago, 1.3 I believe? It made the “new user tutorials” MUCH more complex than they were before. They were very well targeted at someone who is first using Meteor before. The new tutorial is more an example of “best practices”, and from having our new employees try it out, their opinion is it is very difficult to understand for someone new to Meteor. I had to personally train them Meteor, because Discover Meteor was out of date, and the new tutorials only confused them.

I think their worried about users getting the wrong idea about what Meteor is if they make it too basic. A lot of experienced node users would look past Meteor, I imagine because the “magic” seems like you have less control over your project. It’s not clear to them that they are using an insecure/autopublished version of what Meteor really is.

So before, the tutorial was great for new users, but turned off experienced Node users. Now the tutorial probably looks wonderful to experienced Node users, but looks complicated to new users.

I still think they should have multiple tutorials. One targeted at complete new users of Meteor, that shows the “magic” of Meteor. Other ones can be put in the Meteor Guide and show best practices. )

9 Likes

Excellent assessment.

They’ve also been working through some super gnarly refactors, which has slowed things down. On the other hand, they’ve also been moving towards a development process that includes long-term support (LTS) of specific versions of the platform (i.e. v1.4.0 included Mongo Enterprise support and Node LTS support). As that LTS gets more formalized and gnarly refactors get accomplished, popularity will start ramping up with larger players.

Also, while the new import statements can be overwhelming for new developers, that’s a problem that can be addressed with proper tooling.

2 Likes

This ‘magic’ never existed. For production Meteor deployments, all this and much more always had to be done. In fact Galaxy simplifies things a lot. The real magic in Meteor is still there.

Are you seriously saying this is hard? This is trivial stuff compared to manually building/deploying a node app on a server.

4 Likes

I still think the classical Meteor stack is great for rapid prototyping. I couldn’t believe how much I got done in a week when I first started using it. I was elated. I think the biggest thing today is that there are so many moving parts in the JavaScript ecosystem – picking a framework-level solution (rather than a basket of libraries) is kind of betting the farm on one key piece of tech. And there are certainly no silver bullets.

No one could have predicted how the JS ecosystem would change since the Meteor 0.x days, but I don’t think we should be surprised by the developments. And I think MDG has been making great strides in a world where they ease deployment, while also owning less of your tech stack. It’s a different message than the early days, but I think from a business perspective, MDG has to have happy enterprise customers – and that flexibility is key.

In terms of its future, I see it being where it is today. They have a number of happy customers but it’s not the Apple or Google of app development. Meteor’s vision in the early days was something really cool and admirable.

1 Like