81–90 of 189 posts
Honestly, I used meteor and tried pretty hard, I went to their hackathons, etc... I just don't think it's as good as the other options technically (does not scale well as a server, which is a problem for most applications). More importantly, as a developer, I do not believe VC money should be bringing opinions to the open source community (which is what this is) is a bad idea. The whole point of open source projects…
I'm sorry, but how are you in a lead position but somehow didn't understand a timeless principle of software development?
I personally enjoy seeing people voice their mistakes in a honest way so the rest of us can learn.
Edit *your
I loved meteor. Was committed to it for 6/7 months while still learning JS (and working on ember and rails projects with others). I knew it was a risky decision, but it seemed like a good choice for making it as a one-man dev agency. For me, there's no stack selection problem, for me, the main problem is the co$t of launching a working demo-app or a prototype. The only thing i wanted was a simpler/cheaper way of depl…
In regards to cost of launching a working demo-app or prototype my solutions was a Digital Ocean $5/month box + Dokku https://github.com/dokku/dokku
Worth mentioning that there are many more solutions now than there were a year ago, when i was facing this challenge.
I was never able to get on board with Meteor because of the Mongo dependency. Not to get too far off topic, but Mongo is guaranteed to lose data under certain well-defined conditions. I completely fail to understand why some developers seem to be allergic to learning about data structures and the means of query-ing them. It's not really that hard. If you can JS, you can SQL.
> I completely fail to understand why some developers seem to be allergic to learning about data structures and the means of query-ing them I'm not a fan of Meteor's dependency of Mongo either, but proper database architecture for a rDBMS is not an obvious skill. Even with an ORM (Rails/Django), it still takes care to set up PK/FK relationships and that's not necessarily taught in a CS curriculum. Mongo would be suff…
I don't know what gets taught in CS degree plans. But I will say that if I can learn how to model, query, and display data, then pretty much anyone can. Especially those with the benefit of a CS degree.
I don't use an ORM beyond certain limited functions. I use SQLAlchemy for a lightweight connection to the database and for migrations with Alembic. (apologies and accolades to zzzeek)
Beyond that I have a wrapper around database stored procedures that objectifies results from the proc. I wrote it once. It has worked really well many times.
It's not quite as easy as doing everything in your code. You have to support and maintain your SQL in addition to your web app code. But it is blazingly fast to do things this way, and in addition, you are going to have to do it this way eventually.
You must implement business rules in the database, or you will suffer at some point.
I disagree with you that Mongo will ever be sufficient, even if the Mongo team does manage the data loss problem (which, in my understanding, is that it's a feature--not a bug). I don't know of a method in the Mongo system that allows you to enforce business rules the way that SQL Server or PostgreSQL or Oracle does.
But I would happily be enlightened. This could be a case where I just don't know enough.
I'm sorry, but how are you in a lead position but somehow didn't understand a timeless principle of software development?
I'm sorry... Literally your entire posting history is negative without adding any value. Why is that? I personally enjoy seeing people voice their mistakes in a honest way so the rest of us can learn. Edit *your
Also it's "your", not "you're."
I'm sorry, but how are you in a lead position but somehow didn't understand a timeless principle of software development?
Everyone makes mistakes, and this one's more common than one might think :)
Seems like a good analysis of Meteor's shortcomings. I did some research on related areas a few months ago. My ideal stack at the moment would involve: * redux or cerebral with immutable model * react * css modules * webpack * a realtime-enabled version of falcor, which doesn't exist yet. The last bit is still the missing piece for realtime, as far as i'm aware. Neither GraphQL not Falcor seem to been designed with r…
I'm currently using Meteor to teach a college-level course on Web Development for beginners. https://csci16.hellometeor.com/ It's incredible how accessible Meteor is for this purpose: * One line complete local setup * One line deployment (to Meteor servers, but still) * Javascript only (no need to learn Python, Ruby, etc in addition) * Out of the box User Accounts * Simple templating engine with Blaze I can think of…
I can sympathize greatly. I played around a bit creating an isomorphic "framework for frameworks" to explore some techniques I didn't get to use in my day-to-day. There is a constant tension between leaky abstractions and expressing functionality meant to run in very different environments that I personally am taking years to fully grok [0]. Of course, unlike the meteor folks, I'm doing it for fun, so there is no pre…
"Isomorphic" or "Universal" are fancy terms for dual execution. Your code is run on the client and server. It has technically been possible ever since Node came out, but the problem is that client-side and server-side code interact with different APIs and carry out different tasks with them. The inputs and outputs are different so the code ends up different, even if written in the same language and even with the same design patterns.
TL;DR: JS on Client + JS on server != JS everywhere.
It's hard to understand this.
The big mistake was trying to provide anything beyond Minimongo on the client side. People are very picky about what front-end frameworks they use on the front end, and typically people who have strong opinions about that are less opinionated about what they use on the back end. I'm firmly in that camp, for instance. I've been a huge fan of Firebase for a while because it frees me from the tedium of having to create…
You are slightly wrong in your history of Meteor. It was extract from an app they built. Unlike Basecamp or Facebook, the app died off and they focused on just building the framework. So while it was extracted, I think MDG has missed a lot of the learnings that something like Rails gets from core contributors that are building applications and the framework together.
MDG has actually talked about taking one week twice a year to build 'apps' with the framework, but that just hasn't been enough. I am glad they are finally working with Meteor itself to build Galaxy and supporting Galaxy customers as well, that really gets some skin back in the game.
Imo, this post is just a manifestation of the deeper issue around profitability and the fact that MDG will need to jettison some of it's development costs and pick up a much larger base of customers if they want to be profitable.
Which PaaS also builds it's own programming framework...