I would choose Flask over Meteor any day. JavaScript is the unholy union of various browsers introducing hacks which are then standardized by committee. Considering that's the design process, it actually is pretty well done. But there's no reason to inflict JavaScript on yourself when you can use a language with a coherent design.
I haven't used meteor, but I have used a few other JS frameworks and libraries on the backend. My major criticisms of JS on the back end are: they like magic, in that they tend to decouple code to the point that there's no way to trace the code. Instead, pieces are structured and tied together by convention, i.e. thingController goes with thingModel, and stuffController goes with stuffModel. It creates terse code, but a) if you need to do anything slightly unique (and you will) you're screwed, b) it's a huge pain to debug and trace because you can't just read function calls, and c) since the JS world doesn't care about reverse compatibility, you have to always know when the convention changes, and if you fall a few versions behind, you're basically stuck there. In particular, Ember.JS gave me PTSD. Meteor may avoid some of these issues, but when I evaluated it a while back it didn't seem like it did.
reframing the question to "python vs. node" on the server-side, the answer seems very dependent on the use-case. there's not (to my knowledge?) much agreement in the python community about how to compile to javascript, much less regarding an ecosystem of client-side libraries. if a rich client-side that shares logic with the server-side is part of the story, i don't think python is a good choice. i wonder if the Django project could do anything a/b this or if it's too big a chunk to bite off?
all that aside, i like Flask a whole lot. Proxy objects are brilliant, and i wouldn't be surprised if koa.js was partially influenced by Flask. i'm considering going back and fiddling w/ Sinatra for the project after next as i'm given to understand that it was a partial inspiration for Flask's routing.
all in all, there's a lot of cross-pollination. i suppose jquery + html -> frontend framework (angular, marionette, etc.) -> express.js + sequelize/bookshelf -> Flask + SQLAlchemy would be a pretty smooth transition w/ lots of docs, stack overflow, community, and sample code to help out.
I don't think many python devs are espousing Python for the client side. I use react/underscore/Jasmine/sinon with ES6 run through Babelify for the client side.
Sharing logic between client and server side means that your client and server side don't have clearly-defined responsibilities. The one exception to this might be input syntax validation, but generally that's a place where you don't want to roll your own anyway.
idk, could imagine wanting computation to run on the client when it's a desktop (to save server cycles) or the server when it's mobile (to save battery)... not a level of optimization i practically run into, but not an unreasonable example.
i guess a better thing to say is "exactly": specs often change and responsibility gets shifted around. so "runs everywhere" can be useful, whether it be js or otherwise.
I disagree, that's a totally unreasonable example. Not only is that a bizarre combination of requirements, but that's not a good way to approach meeting those requirements. I'd write the code to run on the server and then profile and optimize on the server. JavaScript if never going to outperform hot spots rewritten in C.
You're forgetting the first rule of optimization: profile.
> But there's no reason to inflict JavaScript on yourself when you can use a language with a coherent design.
JavaScript has a coherent design specially if you're using ES6+ in strict mode with a linter. Modern JavaScript is a great language, and comparable to Python.
I'm using ES6 in strict mode with a linter and Babelify to transpile for browser compatibility and I stand by what I said. I've been writing JavaScript since there was JavaScript to write, and the situation has improved drastically, but JavaScript is still far from being a coherently designed language.
I haven't used meteor, but I have used a few other JS frameworks and libraries on the backend. My major criticisms of JS on the back end are: they like magic, in that they tend to decouple code to the point that there's no way to trace the code. Instead, pieces are structured and tied together by convention, i.e. thingController goes with thingModel, and stuffController goes with stuffModel. It creates terse code, but a) if you need to do anything slightly unique (and you will) you're screwed, b) it's a huge pain to debug and trace because you can't just read function calls, and c) since the JS world doesn't care about reverse compatibility, you have to always know when the convention changes, and if you fall a few versions behind, you're basically stuck there. In particular, Ember.JS gave me PTSD. Meteor may avoid some of these issues, but when I evaluated it a while back it didn't seem like it did.