I dont get it; or the DAG of Meteor

help
14

Here’s the catch, OP, Meteor was made to solve a specific set of problems, not become a monolithic framework for everything. Hell, even Node (that it was built on) was made to solve a subset of web development problems.

It’s about choosing the right tool for the job. The problem with software dev, sometimes, is that things become hyped.
You find yourself needing to hammer in some nails. You would choose the hammer for that job. If you choose another tool, it will just cause frustration and a terrible final product, obviously.

What meteor offers:

  • Publication and subscription made extremely easy
  • Data abstraction on the client and server
  • Rapid prototyping and building
  • Package based development
  • Abstraction from event loops
2 Likes
15

Hello. From the perspective of being the friend and co-worker mentioned in the original post, I must say that that list of offerings is the exact reason why I feel Meteor could fit in real good.

My main concerns are that:

  • We need more stuff than just those points.
  • We need a way to handle the the files that our system will create and make them reachable from with in 1-n instances of our application.
  • We have such a tight budget / deadline to get up to speed.
  • We actually don’t know how far we need to go with our products, or
  • if it needs to be as complex as it is today

These reasons both speaks for and against using meteor, which I’m well aware of.
But often I think that we as SW-Devs tend to add complexity that isn’t needed at all.

// Jonas

16

It’s built on Node, you can use fs

17

I know. :smile:

And there seems to be quite a few nice file handling packages as well.

18

This is a bigger issue though.

19

These reasons are also why I’m trying to get a more in dept talk with the Core team, so that we could dig deeper into the product that we’re talking about here.

20

While I agree with a lot of the questioning that has gone on here, my experience with SOA and enterprise software ecosystems is that we never think anymore of any one framework being the main choice for everything. Think of how fast the concept of “web frameworks” has grown over the past 10 years since the advent and success of Rails. But Rails itself is like an enterprise application, it can’t throw out its old paradigms and embrace new ones (like data over the wire, socket support, and other core tenants of Meteor) without alienating it’s user base. Certainly they try to add some new features every year, but they don’t think from a fresh perspective and perform a rewrite.

This is why so many Rails developers have moved on to either using Rails as an API layer only, to moving to other frameworks and languages. Today most serious apps that are “written to scale” are based on micro services, apps and message queues talking to each other and sharing events and data streams. This gets more complex at enterprise levels, where almost all the value of an application lies in the Business Intelligence and data mining areas, where trends and insights can be extracted from your user base so that a business can get key insights that will achieve more incremental growth, which is the nature of a business “at-scale”, not of one trying to gain traction and achieve product-market fit.

I think (wisely) MDG goes after the younger programmers and the startup communities, because in 10 years these will be the people making big decisions and scaling big enterprise applications. 10 years ago when I pitched my first Rails application, I never imagined that big companies would be trying to hire Rails developers to work on greenfield applications inside of a big billion-dollar business, but the reality of a big business is that they can’t build one monolithic application that manages everything, and have a team of 100 programmers all on the same code base, releasing code daily.

Meteor to me as a manager of a small programming team of 8, definitely hits the sweet spot where I can feel like it’s not just a toy that I am building. I can scale a meteor app far faster and easier with less money than my current Rails apps in production. I can hire junior programmers with JS experience and have them be productive in the isomorphic API without having to have them understand the MEAN stack (or worse), and I can easily find suitable programmers for the hard things (or do them myself). For me, picking Meteor as the next thing we are using to build another part of our SOA stack is not completely a no-brainer, I did wait almost 2 years from the point that I “fell in love” with Meteor, until today when we have official React support, SQL support on the horizon, and better professional deployment options.

Those are my 2$, I can’t find the cents symbol on my iPad.

2 Likes
21

I’ve asked myself the same questions. And there are a lot of things about Meteor that are really attractive and some others less.

  • As already have been said other database support is on the way.
  • Maintainability and usability depends largely on the programmers that are writing the app and is no different then any other framework/platform. Except the platform/framework your are using should have enough flexibility to allow for good design. Personally the main obstacle I see in Meteor is that everything is in the global scope. It would be nice to have some module loading of some kind.
  • You don’t have to use the ReactMeteorData mixin in React, there are other solutions.

I’m also still looking at Meteor and how it is going to fit. In any case there are a lot of cool features on the horizon.

1 Like
22

Also, I think it’s important if you’re assessing Meteor, is to consider it relative to something else. Presumably you have a project you want to build. If you didn’t use Meteor, what would you use? There are plenty of choices out there and they all have strengths and weaknesses.

1 thing I think that people don’t understand about Meteor is that there are plenty of things that it doesn’t do that other frameworks provide (like say, a core model layer). It’s actually quite modular and quite flexible in this way. You either view that as a win because you can pick between other existing solutions (or even your own) or you don’t (because you’d rather be forced down the “1 true path”). But it’s not fair to make a mess of your code because there’s no 1 true path in an area and then complain that Meteor promotes crappy code. The reasonable exceptions here are places where there’s no way around it (like Mongo being the only db, but hey that’ll change soon).

23

We need a way to handle the the files that our system will create and make them reachable from with in 1-n instances of our application.

It’s hard to give advice without knowing more of the specifics. If your writing files that need to be accessible to other applications, perhaps you could use S3? We have two Meteor applications connected to the same mongodb. Our customers use one app to upload docs which we store in S3, and we access them from our admin app.

We have such a tight budget / deadline to get up to speed.

How quickly you can make something really depends on existing skills sets, how fast you can learn, familiarity with nodejs frameworks, clarity of your spec, etc. But in the right hands, you build things with Meteor in timeframes which are just not possible with other tools. But the success of a project depends as much on how well managed it is as it does on development skill.

I think the only way you’ll be able to know if it’s right for your team is to give yourselves some task (a demo app concept) and see how far you get. It will be hard to get any real answers until you are facing some specific problems.

24

Why would you think that? Look at Workpop.

Or look at what we’ve done at White Rabbit Express. Our first Meteor app was put in put production over two years ago, when Meteor was version 0.6. We used it to handle over ten thousand customer requests, generating over $1M in revenue.

Recently we launched an update. We split the app into two parts, a public-facing client and a ‘back-office’ admin app which share the same mongodb instance. It’s a large and complex ecommerce app with modules for order processing, payment processing, purchasing, receiving, shipping, customer support and bookkeeping. It has integrations with Stripe, PayPal, Saasu, Japan Post API, Help Scout, Mixpanel, Slack, Keen.io, Amazon S3, our own external Meteor-built micro services apps, among others. It’s possibly the most complex app anyone has built with Meteor.

I’m really curious why you’d think Meteor is somehow limited to “minor projects”? We didn’t get that impression at all.

Perhaps we should make a DevShop presentation about what we’ve built to help dispel this rumor.

1 Like
25

Here I go again - old story warning…

Serious programming has nothing to do with the choice of framework. Sure, Meteor is still evolving really fast (imagine that 1.0 saw daylight just last fall) and it does not have all those jiffy things you will find in solutions like Spring (yuk), Rails (ex girlfriend) or Django (yuk again).

Meteor solves serious problems and delivers awesome stuff. From to the Holy Doc:

Data on the Wire.
One Language.
Database Everywhere.
Latency Compensation.
Reactivity.
Ecosystem.
Simplicity.

Yes, you can create useless Blog examples. So does Rails scaffolding. Yes, you will often find solutions that weren’t in the documentation (or were last minute pulled from the documentation like Blaze @index feature by being non-existent). There are some things that might feel like hitting an invisible wall or somethings that you find missing. That’s where serious programming comes in.

Some simple steps to let Meteor grow on you:

  1. Do something spiffy with templating - like working in context and make use of Template.dynamic. Feel the power of becoming Desert DRY wearing Blaze shades… (or a fancy React Hawaii shirt)
  2. Use @aldeed’s fancy creations like SimpleSchema, Collection2 and Auto-Form. And rejoice in Mongolove.
  3. Be a Tom Cruise and run meteor remove autopublish and get a hang of publications and subscriptions. Dance with efficiency, tango with Minimongo. Start worrying about naming, like @awatson1978 quoted.
  4. Take out Excalibur by browsing on DDP. Chance to be King here.
  5. Along the way you will find marbles of Reactivity. Cherish them and make a necklace.
  6. Be like water - find that your code is the same everywhere.

Meteor killed dinosaurs. Headlines read by the animals who survived.

7 Likes
26

There are a couple of things that give that impression.

Meteor seems well suited for small projects, thus it is unsuitable for large projects. I know it’s a false dilemma, but it is a reason for the impression.

The completely undiciplined way files are loaded and dependencies resolved.

When I navigate to a Meteor-app, generally I am met with a blank page. Good on you for having at least a landingpage for White Rabbit Express. Now fix the rest of your app and explain why it is not the default in a framework that promises isomorphic JavaScript. :smile:

I’m unsure about the datamodel, but thats another topic.

Ultimately I am also biased against frameworks.

The only real problem here is “load everything and let Meteor sort them out” - some people might like it, but it disturbs me.

27

Meteor seems well suited for small projects, thus it is unsuitable for large projects.

A Cup of Tea
Nan-in, a Japanese master during the Meiji era (1868-1912), received a university professor who came to inquire about Zen.
Nan-in served tea. He poured his visitor’s cup full, and then kept on pouring.
The professor watched the overflow until he no longer could restrain himself. “It is overfull. No more will go in!”
“Like this cup,” Nan-in said, “you are full of your own opinions and speculations. How can I show you Zen unless you first empty your cup?”
-Zen Flesh Zen Bones

If you need fast startup time, Meteor may not be for you. That being said, there are very popular apps, like Asana, which need some time to load. Also the community has provided some packages which do some sophisticated things to allow fast rendering.

I believe @arunoda maybe using it here https://kadira.io/

On the other hand, once a Meteor app is running, it can be very performant. I think most customers would agree it’s worth the wait considering they don’t have to wait much after that–you can fluidly move between screens nearly instantly.

The completely undiciplined [sic] way files are loaded and dependencies resolved.

Often is doesn’t matter which order files load. When it does matter there are options to have control over it (you’ll learn about moving code into packages if you dig in.)

Ultimately I am also biased against frameworks.

Well Meteor was designed to make it easy to built the type of reactive sites which previously only very large companies could afford to produce. You can do it without a framework, but if your competition is using Meteor, they may burn less money and beat you to market. :wink: They being said, I think you’ll find Meteor is very flexible and agnostic about a lot of things and plays friendly with others. Our first Meteor app, two-and-a-half-years ago, was written in CoffeeScript used Angular templating.

The only real problem here is “load everything and let Meteor sort them out” - some people might like it, but it disturbs me.

Meteor rather elegantly addresses the single hardest aspect of web developing: keep data in sync between the clients and the server. Something I wrote elsewhere goes into a bit more detail.

2 Likes
28

I think meteor is made for “real” single page app like gmail that stays open in your browser during the whole day, and not for web page where you come and go.

3 Likes
29

I think nearly any website could benefit from the reactivity of Meteor. Once you’ve seen how nice things could be, I find it very irritating to be on a site like upwork.com (formerly odesk.com) where I need to refresh to see new applicants. Why can’t it just be reactive? Because it was hard to do this kind of stuff with the tools they were using to build their app.

Or when I’m on my banking site and I have to click refresh to see the latest transactions. It could easily be reactive with Meteor. On when on a bitcoin site and I have to refresh to see the latest exchange rates. Connected clients are better.

Or when I have to click refresh on a forums or SNS site to load the latest comments. Even Pingdom requires a refresh button to get it’s pages to load the most current data. If seems old-fashioned and out-dated.

It’s so easy to design a better experience–if they were just using Meteor. Without reactivity, your app is just a fancy fax machine.

2 Likes
30

What an asshole. A person comes around with a genuine desire to learn and understand; Nan-in throws tea at him.

My worry isn’t the order, but that all files are loaded; regardless; and are expected to contain random variables that are spewed into the global namespace.

AMD, CommonJS, ECMAScript2015… none allow the imported file to say what it should be called.

Is there a mechanism for a file to export an object without claiming a name from the global namespace?

Let say you want to calculate something from that value. Load the page, pull up a calculator, click a few times. Do the calculation again, just to make sure everything was right. A different answer, try again. Another slightly different answer. An hour laters, 40 different answers, you realise the website changes the exchange-rate randomly. Oh how glorious a reactive app is!

It’s just an example to show that blindly applying “reactive” is not the answer. You need to think through the UX better, partly because reactive is new but also it is inherently more complicated “get a snapshot of now when you load the page, reload to get updates”.

31

It’s just an example to show that blindly applying “reactive” is not the answer.

Then don’t apply it blindly. We don’t; and neither should you if your use-case doesn’t support it. Our USD <> JPY rates change once per day.

If you have an real-time data source, like bitcoin rates, you could also allow them to update in realtime but add a pause button. Mixpanel effectively does this when loading new events in their Live View. The events are queued in realtime and you can “play” them by clicking to load more. Kadira.io allows you to do this so that you can analyze a snapshot of your metrics:

When people are first learning about Meteor it’s very common to hear, “if I have an app that needs reactivity then maybe I’d consider Meteor.” But what we’ve found after creating several Meteor apps is that even when there wasn’t a specific requirement for reactivity you end up using it all over the place. Our dashboard charts update in realtime as new orders are created. Customers using our app get real-time in-app alerts when the status of an order changes. New Customer emails appear in our order views without needing a refresh to pull them. Web application languages can be changed between English, Japanese and Chinese without refreshing a page and losing the state of controls.

When you get reactivity for free you discover that it allows you to create some great UX which you never considered possible before because it would have been too much work. Like creating collaborative multi-user applications. Like this tiny app we created to demo Meteor to a group of 30. We invited everyone to connect and tap to create an object which is pushed down to everyone else in near real-time (works on mobile too!):
https://github.com/tokyojs/sunspots-meteor-demo

I think Meteor resists a lot of web developers because it rewrites the rules. For me it was an easy sell because I come from a client-server/n-tier enterprise background. In the client-server world we’ve had bi-directional, session-based, stateful protocols (RPC) for a long-time. Web development felt like a terrible step backwards. What instantly appealed to me about Meteor is that they are solving some of the problems we’ve been working around for 20 years, in a way that gives you these really powerful capabilities from simple fundamentals.

810×490 101 KB

I think the more entrenched one is in traditional approaches to web development, the more difficult it can be for someone to get their head around these new approaches. Its sort of like how our heads are so full of false ideas and bad assumptions about how the mind works from popular psychology that we wouldn’t recognize a good theory of emotions or intelligence if we heard one. Luckily Meteor also has a very large and active community to help you along the way.

1 Like
32
  • I have tshirts and hoodies, here, have this great new t-shirt for free.
  • Hey, it is winter here now, therefore noone should ever wear tshirts anywhere and you’re bad!
34

that’s not really how it works. you don’t just throw in the scripts. you load them explicitly and determine how to expose them.

Packages have namespaces (your Meteor organization). Packages are hyper-explicit in terms of what they make available to the outside world. If you don’t say it, it doesn’t happen. Any variables we want to “export” from our package to the host application must be passed to the api.export() method.

1 Like