Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introducing Meteor 0.9.0, the Meteor Package Server, and Isobuild

meteor.com

Post reply on HN
Print view View original

51–60 of 64 posts

Re: Introducing Meteor 0.9.0, the Meteor Package Server, and Isobuild

#51

Post by jimmytidey »

jonperl wrote: post #44
chaostheory wrote: post #25

Is there a time table for when meteor will support a relational database?

The only thing I found is that additional databases are under consideration for 1.1+ https://trello.com/c/6ugalZMG/54-additional-database-support

I've found the absence of joins very frustrating, as well as aggregations such SUM etc. The reason is, I presume, that these are very intensive for a reactive app. If it has to check for a re-render everytime anything is updated across 4 tables then that's expensive. Or for aggregation, everytime something new is inserted into a table.

Re: Introducing Meteor 0.9.0, the Meteor Package Server, and Isobuild

#52

Post by phpnode »

pdkl95 wrote: post #46

The problem with meteor (and similar frameworks): curl -s https://www.meteor.com/blog/2014/08/26/meteor-090-new-packaging-system \ | sed -e '/[ ]/,/[ ]/ d' If you want someone to read your article, actually sending that article would be useful. If that article has advanced features that require javascript, flash, or video/audio, you should probably give me a reason to whitelist the page. Sending and empty body tag, o…

Your sense of entitlement is simply staggering.

Why do you assume that your attention is so valuable that developers should go out of their way to cater specifically to you? The number of people who disable JS is statistically insignificant.

You have chosen to break your web experience, you have no one to blame but yourself.

Re: Introducing Meteor 0.9.0, the Meteor Package Server, and Isobuild

#53

Post by kungfooguru »

kristiandupont wrote: post #36

Having worked with Meteor for 8 months by now, my love affair with it is slowly fading. I guess I've realized that it's too far on the left on the [framework...library] scale for my liking. It's very "don't call us, we'll call you". Which is awesome when you start because you just sort of put stuff out there, functions, collections etc., and Meteor magically picks it up and does stuff with it. Yes, you can still debu…

Having not used Meteor (beyond toys) but trying to understand how it works this sounds exactly like what I would expect to hear.

But I hope you are wrong about becoming a major platform for the web, unless it drasticly changes. These Node frameworks keep astounding me in their use of stateful servers and relying on vertical scaling.

Re: Introducing Meteor 0.9.0, the Meteor Package Server, and Isobuild

#54

Post by possibilistic »

mrcwinn wrote: post #33
primigenus wrote: post #31

Earlier quoted context omitted.

That's funny, because not having to write "spaghetti code" is one of the reasons I tell people to use Meteor. Perhaps we have different definitions. For web apps, I tend to define spaghetti code as the huge layers of glue and boilerplate you have to write to get your data out of your database in the server, serialized into some JSON or XML format through your controller in order to send to the client and into an XHR…

Backbone is not an MVC framework, and it's important to know that. It's one of its greatest strengths as a client-side JavaScript tool. A well structured Backbone app can stand the test of time, and I can't say that for some other options. Meteor shows promise, but I have to agree that without a mature UI toolkit, you just end up with the same junk we've had for years (not speaking to other components of Meteor). For…

Will Backbone stand the test of time as both data binding and DOM eventing continue to evolve? I'm not resolutely convinced of Backbone's staying power, but I'm open to entertaining other thoughts on the matter.

Re: Introducing Meteor 0.9.0, the Meteor Package Server, and Isobuild

#55

Post by primigenus »

denom wrote: post #40
pinouchon wrote: post #9

Earlier quoted context omitted.

I too was disappointed that the blog post doesn't go into any detail about unibuild. One of the best and only explanations of isobuild is in this talk by Geoff Schmidt, one of the founders of meteor: http://youtu.be/EZUfQ1zA_NM?t=11m33s [iso]build Like 'make' or 'scons' but for distributed systems. One source tree One package system Multiple languages Multiple targets Multiple architectures

I think that this notion of _generality_ that meteor embraces is essentially the struggle for platform relevance. I take isobuild to mean iso-platform, one platform to rule them all. Take the discussion in the video about DDP. It's like "get on board people, we've figured it out!" There is a tension between generalities and specifics, between abstraction and things that are concrete. I don't doubt that having a solut…

I feel this way too sometimes, but I've come to relate it more to the fact that Meteor is relatively new, and the community has collectively built relatively few complex apps, so the documentation, available blog posts, Stack Overflow questions and answers, wikis, books, tutorials and videos just aren't really in place yet for that kind of architecture.

There are more and more solutions and patterns emerging every day as more and more people try building complex stuff in Meteor, though. Just look at some of the packages by Arunoda like fast-render, subs-manager, and kadira: all designed to ease development around common bottlenecks you run into as you start to scale up.

In other words, I think this problem will eventually go away as more people keep trying.

Just like it did with Ruby on Rails 8 years ago :)

Re: Introducing Meteor 0.9.0, the Meteor Package Server, and Isobuild

#56

Post by arbesfeld »

pdkl95 wrote: post #46

The problem with meteor (and similar frameworks): curl -s https://www.meteor.com/blog/2014/08/26/meteor-090-new-packaging-system \ | sed -e '/[ ]/,/[ ]/ d' If you want someone to read your article, actually sending that article would be useful. If that article has advanced features that require javascript, flash, or video/audio, you should probably give me a reason to whitelist the page. Sending and empty body tag, o…

try https://www.meteor.com/blog/2014/08/26/meteor-090-new-packag...

Re: Introducing Meteor 0.9.0, the Meteor Package Server, and Isobuild

#57

Post by jonjamz »

evanscottgray wrote: post #37
vqc wrote: post #15

As a developer and maker, one of the most important things is to ship. And as someone who is not a self-professed [insert programming language] ninja or a full-stack this or that, I can safely say that Meteor has made it much easier for me to iterate and ship. I expect that as I grow, Meteor will continue to grow as well. Excited to see Meteor get closer to 1.0.

Definitely agree with you on this one, Meteor has made code easier to deploy. Haven't used it in a while but was able to get my project off the ground in less than 20 minutes. Have recommended it to non 'full stack' friends and they have had great success too. Hopefully this project continues to improve on the road to 1.0!

Don't make Meteor sound like a toy, though, 'full stack' engineers worth their salt can do awesome things with it if they understand its inherent limitations. I ran Meteor with Redis before their official Redis implementation came out, and I used Redis pub/sub to sync in real-time between 8 different instances of Meteor in production. It rocked.

Just because a framework comes out supporting only MongoDB doesn't mean you have to use MongoDB for everything. It's still on Node.js, and it still supports NPM packages, with some small caveats.

Re: Introducing Meteor 0.9.0, the Meteor Package Server, and Isobuild

#58

Post by jonjamz »

jonperl wrote: post #43
maxharris wrote: post #16

If 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 have built and integrated some pretty complex components with blaze templates without needing a component api. I am curious what use case you ran into where the template api was not sufficient? In your comment history I saw that you asked for reactive template variables. I know of two ways to accomplish that, 1) attach a ReactiveDict to a template instance in it's render function, 2) pass it in as a variable to the…

Since Meteor automatically scopes by file, you can write your template helpers and event handlers in the same file, and place a reactive data structure at the top of the file that both can access.

You could use reactive-object (my package), as it provides a fairly drop-in reactive object that supports arrays as reactive properties, including all the Array.prototype methods.

Re: Introducing Meteor 0.9.0, the Meteor Package Server, and Isobuild

#59

Post by jonperl »

jimmytidey wrote: post #51
jonperl wrote: post #44

Earlier quoted context omitted.

The only thing I found is that additional databases are under consideration for 1.1+ https://trello.com/c/6ugalZMG/54-additional-database-support

I've found the absence of joins very frustrating, as well as aggregations such SUM etc. The reason is, I presume, that these are very intensive for a reactive app. If it has to check for a re-render everytime anything is updated across 4 tables then that's expensive. Or for aggregation, everytime something new is inserted into a table.

Joins are a really hard problem, many people have tried to support joins with a package but they all miss a corner case or have less-than-ideal performance. I think it is something we will have to wait for meteor core to support. https://trello.com/c/BGvIwkEa/48-easy-joins-in-subscriptions

In the meantime I have been using the publish-composite package and denormalizing data that has a lot of reads in an update hook using the collection hooks package.

In mongo ideally you should have rich documents and not spread out relations among too many collections. However I can imagine how hard it would be to try and sync w/ a relational database without native join support.

Re: Introducing Meteor 0.9.0, the Meteor Package Server, and Isobuild

#60

Post by jonjamz »

kristiandupont wrote: post #36

Having worked with Meteor for 8 months by now, my love affair with it is slowly fading. I guess I've realized that it's too far on the left on the [framework...library] scale for my liking. It's very "don't call us, we'll call you". Which is awesome when you start because you just sort of put stuff out there, functions, collections etc., and Meteor magically picks it up and does stuff with it. Yes, you can still debu…

I would recommend checking out Kadira for optimizing your app. It's pretty amazing the kind of information you get out of it, and Kadira Academy teaches you a lot about Meteor's internals.

Also, if your app is now "suddenly slow", I'm guessing it's been around for a while. If you don't have the proper indexes on MongoDB it's going to get slower as it loads up with more data. I've experienced this first-hand, migrating a Rails app from Postgres to Meteor/MongoDB. We have millions of records, and one missed or incorrect index can slow the whole app down, sometimes unbearably.

Post reply on HN