131–140 of 163 posts
I like meteor, I think it's a good framework, that solves well the "Make a webapp with non critical data but where real time is critical" problem. I've also used angular, which I also like, but has a little bit more of a learning curve drawback. I do unfortunately believe that a project or framework should make it not because it's CEO or leader is good at selling something, pitching VC's, and creating a brand, I thin…
Earlier quoted context omitted.
Sidebar.io is based on Telescope which powers a number of sites: http://sidebar.io/
Hmm. Sidebar is an example of a site that has no reason to use client-side scripting at all. It's a plain list of links, and yet doesn't work without Javascript, and is far, far slower than it should be.
But you make some good points. Meteor is not for everything, and if I had known from the start that Sidebar would end up being just a list of links I might have used a different stack (like Rails, or even a static site generator).
Not trying to sound like a jerk, but I'm just wondering is it really a good thing to put on your homepage that there are nearly 12K questions posted on StackOverflow about Meteor? Seeing a number like that makes me wonder if maybe the documentation and or APIs are not very well done if it's generated that kind of activity on SO.
Maybe you're right and everyone else on this comment thread are suffering from some cognitive dissonance? I'd be willing to bet much of those SO questions and replies are a part of keeping up the Meteor hype with most questions being answered by a core group of devs. The PR machine for Meteor is crazy. It's funny because this 20M will go to generating more hype and PR opportunities, while the actual development will…
Disclaimer: I'm one of these "wide-eyed open-source evangelists", I guess.
I looked into Meteor and it's amazing how everything clicks together. It's just such a drastic change in complexity and feels like a breath of fresh air. The one thing that made me drop it as the choice for a primary stack was the fact that it's tied so heavily into MongoDB. Meteor has a mongodb 'server' replicated client side, that's how they can actually make Meteor so god damn snappy, it's latancy compensation. If…
I'm not a huge fan of isomorphic JavaScript. While it seems great for prototyping, I have doubts on its stability, security, and ability to scale. It seems to be a knee-jerk reaction to just having the technology to write web-client and web-server code in the same language and the emergence of SPAs.
The thing is, we've had working client-server application architecture (which is what an SPA is) for decades. Every multiplayer game you've ever played. Chat programs. Etc. Nobody would risk the headache of tightly-coupling your data layer, presentation layer, and business layer just to save a few lines of code. We separate our concerns in our code itself with MVC frameworks, why are isomorphic frameworks trying to tightly-couple our actual application layers? It's a little bit contradictory to me.
While Meteor seems like a great tool for a couple of newbie developers to rapidly prototype an idea, I'm still not convinced it has the potential to grow into a reasonable architecture.
Earlier quoted context omitted.
I'm apprehensive of the security model. Everything is highly ease-of-use optimized, to the point that you can query Mongo via the browser console. My preferred "easy/simple" model of app design is Firebase (backend and JS lib for pure web clients), who have security figured out.
What you're saying is only true on a barebones default Meteor app. Please don't comment on a tool if you've never used it for anything other than a hello world, you're doing a very sophisticated tool a huge disservice. You remove the autopublish package and you can no longer query records from the client.
It leaves a "I should triple check everything again before going live since I cannot trust the tool to do its job" thread running permanently in the back of the mind. It's such a slowdown. Don't get me wrong, it's important to read the documentation and double check settings, but insanity by default does not build trust.
That said in the case of meteor beyond the autopublish package that should be off by default, I think everything is spot on. I mostly use PostgreSQL, so I cannot use it as much as I'd like to, but hopefully that will change.
My worry is that with JavaScript-based stacks evolving so fast these days, monied interest in one way of doing things would ultimately be incentivized to suppress better ways of doing things, as they emerge.
Has anyone seen DDP used outside of Meteor? https://github.com/meteor/meteor/blob/devel/packages/ddp/DDP...
People here are even pissed that they got more money and other frameworks didn't. Nobody invest (their money at least) without a good risk/reward ratio.
Earlier quoted context omitted.
What you're saying is only true on a barebones default Meteor app. Please don't comment on a tool if you've never used it for anything other than a hello world, you're doing a very sophisticated tool a huge disservice. You remove the autopublish package and you can no longer query records from the client.
A lot of software engineers are wary of frameworks/tools with an emphasize on ease-of-use over security, or benchmarking over data integrity. Rightly so in my opinion. It leaves a "I should triple check everything again before going live since I cannot trust the tool to do its job" thread running permanently in the back of the mind. It's such a slowdown. Don't get me wrong, it's important to read the documentation an…