I wonder if Meteor will go 1.0 before NodeJS.
Introducing Meteor 0.9.0, the Meteor Package Server, and Isobuild
21–30 of 64 posts
Re: Introducing Meteor 0.9.0, the Meteor Package Server, and Isobuild
#22If you're thinking about using Meteor for something important, now that they're at 0.9.0, don't. Meteor still doesn't have a UI component API, so making reusable, reactive interface components is basically impossible (or far more difficult than it needs to be). There's a deliberately undocumented and incomplete API that's supposed to help a little bit, but you're basically out of luck if you don't want to write spagh…
I wouldn't write a commercial, production application with anything less than 1.0. In fact, I wouldn't write a commercial, production application with anything less than a 2.1. ;-)
The cost of supporting these projects early is that you're likely to be rebuilding anyway a year from now, but I think that's implicit in the version number.
In my opinion, the biggest risks of Meteor are this:
1. It hitched its wagon for now to mongo, so you'll be doing the same. If you happen to believe that schemaless isn't all its cracked up to be, that's a real problem in production.
2. You're picking both a client and a server. Sure, you can strip apart DPP or Blaze, but why would you? If you're not wanting to benefit from Meteor's reactivity, you can just use any server+client combo and, say, a websocket connection or something like React.js for UI components.
3. Meteor has a financial incentive to round up as many devs into their own ecosystem (atmosphere?). They want to sell you servers, services, et cetera, like Heroku does. Nothing wrong with that, but it's something to be aware of.
For all the debate about JavaScript frameworks, I have Backbone code I wrote a relatively long time ago and it's still durable and not being refactored. I can't say the same for Ember or Angular code in my experience or observation. Backbone as a library is lightweight enough that I create the framework, following good design principles, that's best for a given application. Your mileage may vary.
It's not to say the people at Meteor aren't a great bunch of people who really love what they're making. Meteor does some interesting things and I think hopes to solve some complex problems. Hope they get there. I'd love to see Meteor mature and become a tool to build bigger things (UI components I agree would be a welcome step).
Re: Introducing Meteor 0.9.0, the Meteor Package Server, and Isobuild
#23If you're thinking about using Meteor for something important, now that they're at 0.9.0, don't. Meteor still doesn't have a UI component API, so making reusable, reactive interface components is basically impossible (or far more difficult than it needs to be). There's a deliberately undocumented and incomplete API that's supposed to help a little bit, but you're basically out of luck if you don't want to write spagh…
I wouldn't write a commercial, production application with anything less than 1.0. In fact, I wouldn't write a commercial, production application with anything less than a 2.1. ;-) The cost of supporting these projects early is that you're likely to be rebuilding anyway a year from now, but I think that's implicit in the version number. In my opinion, the biggest risks of Meteor are this: 1. It hitched its wagon for…
Not that I implied a lack of data validation was my reason for disliking mongo - just to keep myself honest - there are the collection2 and simple-schema packages that help enforce schema validation on Meteor collections.
Re: Introducing Meteor 0.9.0, the Meteor Package Server, and Isobuild
#24Weird, no matter what I try, it only updates to 0.8.3 :(
Re: Introducing Meteor 0.9.0, the Meteor Package Server, and Isobuild
#25Is there a time table for when meteor will support a relational database?
Re: Introducing Meteor 0.9.0, the Meteor Package Server, and Isobuild
#26Earlier quoted context omitted.
The roadmap of Meteor includes "Server-side rendering" planned after 1.0. https://trello.com/c/Lz07fBAm/7-server-side-rendering In my opinion, server-side rendering is a bit overrated since Google knows how to crawl ajaxy apps. SEO is a big concern but you can always render your pages with phantomjs (also a popular approach in the Angular world) or rely on Google being smart. For rendering the page to the end-user, F…
I'm more concerned with end user page load speed than crawling. I find Facebook and Twitter pages annoyingly slow to load, personally. Sure, server side rendering is difficult but it's exactly the sort of hard problem that a framework ought to be able to solve for you. Edit: actually I just went to twitter and it loaded pretty fast, so I looked at the network requests and they do server side rendering for your timeli…
Hm, looks like you are right. At least the new timeline is server-side rendered. I guess they are updating parts of UI to be rendered on the server to be faster.
Interestingly some websites like GitHub are doing the opposite: they are slowly bringing incremental ajax-based transitions to every page, some "real-time" features are implemented with a socket signal refreshing the whole page.
One of the community solutions is "FastRender" package, which is not really about rendering. What it does, it puts most of the initial data into HTML page so you don't need to wait for the websocket connection and the data arriving to render the initial page. Improves the initial page load quite significantly: https://meteorhacks.com/fast-render/
Re: Introducing Meteor 0.9.0, the Meteor Package Server, and Isobuild
#27Earlier quoted context omitted.
The roadmap of Meteor includes "Server-side rendering" planned after 1.0. https://trello.com/c/Lz07fBAm/7-server-side-rendering In my opinion, server-side rendering is a bit overrated since Google knows how to crawl ajaxy apps. SEO is a big concern but you can always render your pages with phantomjs (also a popular approach in the Angular world) or rely on Google being smart. For rendering the page to the end-user, F…
I'm more concerned with end user page load speed than crawling. I find Facebook and Twitter pages annoyingly slow to load, personally. Sure, server side rendering is difficult but it's exactly the sort of hard problem that a framework ought to be able to solve for you. Edit: actually I just went to twitter and it loaded pretty fast, so I looked at the network requests and they do server side rendering for your timeli…
[deleted]
Re: Introducing Meteor 0.9.0, the Meteor Package Server, and Isobuild
#28I used Meteor for a project and almost killed myself. Its good and fancy but loads a bajillion javascript libs that you have no idea. Also loads of dependencies on specific versions. DO NOT USE IT FOR PRODUCTION PROJECTS! I've had a very very horrible experience.
Re: Introducing Meteor 0.9.0, the Meteor Package Server, and Isobuild
#29Weird, no matter what I try, it only updates to 0.8.3 :(
Likewise. I reran the install script (curl https://install.meteor.com/ | sh) and it removed my existing install and installing 0.9.0.
Re: Introducing Meteor 0.9.0, the Meteor Package Server, and Isobuild
#30If you're thinking about using Meteor for something important, now that they're at 0.9.0, don't. Meteor still doesn't have a UI component API, so making reusable, reactive interface components is basically impossible (or far more difficult than it needs to be). There's a deliberately undocumented and incomplete API that's supposed to help a little bit, but you're basically out of luck if you don't want to write spagh…
I wouldn't quite call it spaghetti code... You can still structure things into models, views, controllers, and view controllers (event handlers that pass data to controllers basically). Having a component API isn't really a deal breaker.