dandv

I'm curious, have you looked at Meteor?

https://wiki.dandascalescu.com/essays/why_meteor

+1 for Meteor. It makes is far, far easier to develop a client-server + mobile web app than any other combination of server-side framework and client libraries. You get web, Android and iOS apps from the same codebase, and direct integration with the largest repository of libraries, https://www.npmjs.com/, with over 300k libraries.

Yes, 300k libraries means a lot of crap one, which is why there's http://npms.io, which searches by code quality + popularity + how well the library is maintained.

Meteor covers security, authentication, database, client-server sync, mobile app generation, but leaves the choice of front-end library to you. It works with Polymer Paper Elements (Material Design for the web), as well as with React.

It's an opinionated platform that makes a lot of choices for you, but has become more and more flexible. You can swap the view layer, and the database layer too (Postgres and MySQL are supported besides the default MongoDB).

More at https://wiki.dandascalescu.com/essays/why_meteor

JavaScript sucked indeed. ES6 though, has brought many improvements, and the language now is quite decent. With the advent of async/await in ES7 (which is available now if you transpile with Babel), the callback hell is completely gone, and the language is actually beautiful, powerful, and concise.

Using npm instead of Grunt/Gulp/etc. has been extensively discussed by Keith Cirkel at http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool.... Would've been nice to at least acknowledge that, if not join efforts and try to address some of the inherent shortcomings (e.g. the readability of long lines - https://github.com/keithamus/npm-scripts-example/issues/30).

There is no mention of Meteor in that article?

To be fair, a big chunk of the stars were part of Meteor's "We'll give $5 to organizations that teach kids to code, for every GitHub star we get". But still, pretty impressive growth!

Please stop spreading FUD and go read the source of https://install.meteor.com/

Exactly. And by the time you do need to scale, Meteor Development Group will have released Galaxy, the enterprise-grade Meteor hosting platform, which is their money maker.

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...

Very few know this, but probably the largest Meteor app in existence is Knotable, http://challengepost.com/software/knotable

There are such monolithic plug&play frameworks, targeted at line-of-business apps: Wakanda and Servoy.

If you're looking for a monolithic solution, Meteor may not be for you. Check out Wakanda and Servoy.

Delegating quasi-core parts of the platform to 3rd party libraries is quite common. For example, the preferred routing package for Angular, ui-router (https://github.com/angular-ui/ui-router) was born four years after the release of Angular, and for DOM state preservation, the ui-router-extras (https://github.com/christopherthielen/ui-router-extras) addon is required.

Maybe this will help - I just wrote a "Meteor vs. the MEAN stack" article: http://wiki.dandascalescu.com/essays/meteor_js_vs_the_mean_s...

Ha. Your writeup basically summarizes my extensive "Why Meteor" article. Curious if you've read it before, or if Meteor just makes developers become great minds ;)

http://wiki.dandascalescu.com/essays/Why_Meteor

While that puts commute in perspective, time is not fungible like that in reality. 5 minutes on the margin won't make much of a different. Will you really take an extra week of vacation if move 5 minutes closer? No. Let alone the huge time cost of changing workplaces or residences.

From http://jaxenter.com/angular-2-0-112094.html:

> the framework will be “drastically different looking”, meaning users will need to get to grips with a new kind of architecture. It’s also been confirmed that there will be no migration path from Angular 1.X to 2.0.

> Currently Angular is aiming for a release by the end of 2015 – but early 2016 seems more realistic given the drastic changes that are planned.

This essentially makes investing in Angular pointless, when there are far more capable and easier to learn frameworks out there - Meteor primarily, and also Derby.js, though it's got about 1/10th of the momentum of Meteor, which launched 1.0 two days ago, and had 20k GitHub stars without backing from some giant company. BTW, Meteor never broke compatibility with earlier releases in such drastic ways as Angular will.

See this previous reply: https://news.ycombinator.com/item?id=8522918

Client-side, you have Chrome DevTools, the best JS debugger there is. Meteor has extensive debugging support. See https://github.com/meteor/meteor/blob/devel/History.md#v094. Also, the popular IDE WebStorm has just released full support for Meteor, including debugging.

http://meteor.com is very snappy. So are sites using fast-render, see https://meteorhacks.com/fast-render/

See the section on "When not to use Meteor" at http://www.meteorpedia.com/read/Why_Meteor

Basically, if you need native MySQL support (some support already exists, but it's not in core), or if you need a web-site (SEO), not web-app.

Regarding scalability, by the time your app becomes so popular to exceed thousands of concurrent users, Meteor will have improved scalability again. They've done it a few times already with Mongo oplog tailing support and whatnot. If you already have a highly popular app, it will take you time to port it to Meteor too. So scalability may seem like a problem right now, but likely won't be one in, say, half a year.

By default, Meteor spawns a Mongo instance, with its own DB stored in the app directory, and your data is stored there. No database configuration necessary. Of course, if you have an existing Mongo DB, you can point your Meteor app to it.

You still need JavaScript on the client, so you have to switch context between Python and JS if you're a single dev, or have different team members work on the client vs. the server. Meteor is JavaScript everywhere.

Anyway, Meteor offers much more than data binding and client syncing. See http://www.meteorpedia.com/read/Why_Meteor

Executing arbitrary commands on your machine?

I applied too, they were in a hiring freeze before 1.0 :-)

You can create REST points from Meteor collection very easily - http://www.meteorpedia.com/read/REST_API

In the same vein, there's no way to shield the user from accessing the parameters of a REST request. Which incidentally is easier to replay outside the browser than a Meteor.call().

Galaxy, an enterprise-grade, multi-tenant hosting environment for Meteor apps - https://www.meteor.com/blog/2012/07/25/meteors-new-112-milli...

I'm working on Google's Governance, Risk and Compliance management system.[1] Porting it to Meteor would accomplish several goals:

* clean and much simpler code base

* automatically (reactively) updated status reports on compliance across various systems depending on numerous components throughout Google in continuous flux

* ease of onboarding new developers in the team given the simplicity and ease of learning of Meteor

[1]: https://github.com/reciprocity/ggrc-core

Or http://meteorpad.com - the JSFiddle/Plunkr of Meteor.

"We" is [edSpring](https://www.odesk.com/o/jobs/job/_~0155480bf02dee46f3/), built by [TIES](https://www.linkedin.com/company/948661).