[tomelders]

I don't know about meteor in particular - but my advice would be to eschew frameworks in favour of libraries, I'm not the first person to suggest this and it's worth using some google-fu to read the differing opinions.

Essentially, Common JS + NPM lets people/teams create their own "frameworks" with very little effort whilst also freeing them from the bulk and cruft of a framework that has a limited future; if it has any future at all. The tools and technologies we use to create websites/apps are changing at break neck speeds. Frameworks are in it for the long haul and they hope the decisions they make today will be relevant in two+ years time - but devs have to cope with demands in real time. We don't have the luxury of hope.

Here's some good reading http://tom.lokhorst.eu/2010/09/why-libraries-are-better-than...

[sgdesign]

While I agree in principle, I think it's fair to point out that glueing various libraries together takes a lot more work than using an all-in-one solution like Meteor.

If you can do it, more power to you, but I'm pretty sure there's a large population of developers who just want something that works out of the box (I know I'm one of them).

[jonlachlan]

You can weigh the trade-off between needing to configure your environment with what Meteor gives you. I would say Meteor has a value proposition that's definitely worth looking at. The list of things it helps you with is more than most other frameworks, and at the same time it's modular so you can swap in components that are better for your use-case. You also have the benefit of still being in the JavaScript/NPM ecosystem, which is easy to take advantage of.

[dandv]

That post was from 2010. I think you vastly underestimate the difficulty of building from scratch rich, modern single-page apps that satisfy today's users' needs. Have a look at "7 Principles of Rich Web Applications" [1] by the creator of Socket.io, and at my comparison between Meteor and the MEAN stack [2].

By the time you've built a reliable data synch transport that watches the server database and pushes changes to clients over intermittent connections, then pushes changes from client back to servers when they reconnect, all this with access control, a Meteor developer will have built 10 proof-of-concept apps, determined the product-market fit, and have a working web app for users to use.

[1]: http://rauchg.com/2014/7-principles-of-rich-web-applications...

[2]: http://wiki.dandascalescu.com/essays/meteor_js_vs_the_mean_s...

[collyw]

I think that depends on exactly what you are doing.

If your application doesn't diverge much from a "standard application" in your framework, then you are probably better off using one. If its going to need a lot of customization then probably libraries are a better way to go.

[shubhamjain]

Except that you underestimate the effort in incorporating the "framework" in your new project. Sure it isn't hard per se, but the steps involved in learning every bit of a process that surrounds the framework kills the excitement at some point or other. Like in rails, learning all the routing, code generators, forms, asset pipelines just makes you quit at some point.

I think things would be much easier if I had "grown" with rails as its features grew, but now, it being a behemoth, I would be pretty much disinterested in going in the effort of learning it just so I can make my shiny new project.

The learning would be much easier, if I get to work on existing codebase but then again, it is a chicken-and-egg problem.

[collyw]

Maybe you know one already.

I think it goes both ways. Makes some things a lot easier and others a lot harder. Django's admin for example, can often give you 90% of what you are looking for with very little effort. It doesn't take a lot of effort to learn it. The again, if your application falls outside that model, no point in trying to shoehorn it in.

I would also say that frameworks keep things consistent(I know Django well, so based on that). I recently added Django-rest-framework to my application. It took very little to learn that as they have tried to keep the coding style the same as the class based views. Using them is almost the same, so after the initial half day or so in the docs, everything just clicked into place.