I dont get it; or the DAG of Meteor

help
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
35

Could you pass me a link where I can read about this, cause this is a mystery to me too…

Cheers

36

does this help?

37

I read the documentation for api.export and think you misunderstand my issue.

Suppose I have a package called foo that exposes a variable it calls “bar” and another package, baz, that exposes a variable it calls “bar”.

Using AMD this is not a problem: define( [‘foo’, ‘baz’], function(a,b){…}); It isn’t even possible to realize there “might” have been a problem. Same with CommonJS and ECMAScript2015.

Even if the packages had the same name, there are mechanisms to handle it. In fact it is physically impossible for two different packages to actually have the same name.

I agree that load order is largely irrelevant, though there are nice things one can do with a dependency graph.

38

Dear Professor Phenomenal :wink:
The answer that you are looking for is the only answer that matters and it says …

It seems that Meteor will get you funded faster than anything else out there.
Likely even your not so technical spouse could pull off a proof of concept.
Once funded there is nothing that money can not buy ( : she can hire you : )

DAnG !!!

1 Like
39

dude professorphenomenal ask yourself this one question:

Does page refresh even gonna exist in 5 year? 10years?

Stop saying oh we don’t need reactivity now, ask yourself what the world is going to be like in 5 years. you think refresh button is going to exist in 5 years? Hell no. So start building your app like a real app. And meteor is only real solution to this problem right now on the web.

1 Like
41

As I see it, refresh button will be the new IE6.

42

does this solve the problem?

also see this

43

@professorphenomenal did it help?

1 Like