No trippier than the Windows 386 video https://www.youtube.com/watch?v=OcjvgxAKiHs

𝓖𝓻𝓮𝓪𝓽 𝓯𝓸𝓻 𝓹𝓪𝓼𝓼𝔀𝓸𝓻𝓭𝓼

Meteor does feel a little heavy (especially when you get around to deploying it) but take a look at demeteorizer, at https://github.com/onmodulus/demeteorizer

It converts Meteor apps into more traditional node.js with a package.json

Demeteorizer is a offensively named script that automatically builds a package.json for you. It doesn't make Meteor apps lighter weight or anything like that. It simply makes it easier for you to install the requisite npm dependencies.

TL;DR: It's great for realtime apps, but not so much for the traditional web app as compared to something like RoR.

My perspective as someone who has been using it since its release. It depends on what kind of app you are building.

Coming from RoR, Meteor actually is more of a pain given that it still has edge cases that can eat developer time, especially once you dive past the initial levels of tutorials and documentation. RoR also has well established best practices and norms, unlike Meteor and perhaps Node.js as a whole. This means you will be writing a lot more boilerplate code. Meteor has some memory issues as well at times. You have to be aware of memory leaks and will frequent the profiler often, especially with large client-side applications. I've had some projects that I've worked on in Meteor hit 1GB of RAM client-side. Recent releases have been working on this, though. Live reload and hot code pushes are kind of a moot point with something like the Live Reload plugin for Sublime Text or equivalent.

For realtime applications, Meteor is a whole different beast. Realtime applications are much easier to code. I'm comparing this to making a realtime Node.js application. Meteor takes care of the boilerplate for you, pushing changes automatically to the client. It's not difficult to do something like socket.io and node.js but it is nice to have that all handled for you.

It's great for getting an application off the floor - it has a lot of that magic RoR had when it was released. Once applications get more advanced, the structure and maturity of RoR make it easier to work with. These issues are things Meteor is working on, especially in terms of stabilizing the spec/API and working on fixing the edge cases. With 1.0, it seems they are bringing some more stability to it by making it production ready. Its strengths are much more apparent in realtime applications as compared to a traditional web framework.

Edit: As compared to other node.js frameworks like Express, Meteor is much easier to work with - I probably would not go back to raw Express after Meteor. It's been moving fast to 1.0 where many of the issues I've had with it should be resolved with stability and as edge cases are resolved.

I've been using Meteor since its release and its been great at making apps at maximum velocity.

You mentioned that some people are already scaling Meteor across multiple servers. Looking at it, round robin load balancing won't work given requests to a server seem to be stateful. How is that being done as of now? Do you guys have any guidance on how to do that?

Yes, if you're using DDP over sockjs instead of just over websockets (which Meteor currently does out of the box to support older browsers), you'll need to use a HTTP proxy with sticky session support.

This will be in the official docs at some point, but for now, Arunoda's blog post about this is a great starting point:

http://meteorhacks.com/load-balancing-your-meteor-app.html

Linux driver support with the proprietary Nvidia drivers has always been iffy, if it worked.

Here this is, formatted so it is more readable.

  p = "<" + "pre>";
  for (y in n = "zw24l6k\
  4e3t4jn`t4qj24xh2 x42kty24wrt413n243n\
  9h243pdxt41csb yz43iyb6k43pk7243nm\
  r24".split(4)) {
    for (a in t = parseInt(n[y], 36) + (e = x = r = []))
      for (r = !r, i = 0; t[a] > i; i += .05) 
        with(Math) x -= .05, 0 > cos(o = new Date / 1e3 + x / PI) && (e[~~(32 * sin(o) * sin(.5 + y / 7)) + 60] = -~r);
    for (x = 0; 122 > x;)
      p += "   *#" [e[x++] + e[x++]] || (S = ("eval" + "(z=\'" + z.split(B = "\\\\").join(B + B).split(Q = "\'").join(B + Q ) + Q + ")//m1k")[x / 2 + 61 * y - 1]).fontcolor /\\w/.test(S) && "#03B");
    document.body.innerHTML = p += B + "\\n"
  }
  setTimeout(z)

* Edited for formatting

Personally, I find your comment less readable than TFA.

Whoops, I used backticks instead of spaces to mark it as code.

Tickmarks don't work here, you need to indent by two spaces.

https://news.ycombinator.com/formatdoc

It's back up now.

I noticed this since my websites have been down for the last two hours.

A cron job where a request is sent at regular intervals to a dyno from Phantom should solve your issue. It should be justified if you are buying addons. For free sites with no revenue to Heroku, it's reasonable since they have many sites that only get visited monthly, if that.

Isn't what you're suggesting exactly what he has three services doing? Why from Phantom?