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

41–50 of 64 posts

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

#41

Post by jonperl »

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…

What is nice about meteor is how quickly you can get off the ground and build something with it. Then you realize: I have no idea how this stuff works. Is it secure? When do things update? Is there too much magic?

But if you spend a bit of time learning how meteor’s core packages work (deps, ddp, livedata, blaze, etc) and how they work together — almost all of the apprehension disappears.

I recommend digging into the Deps package first, it powers reactivity and is surprisingly simple (only 1 kb).

EventedMind has great videos explaining reactivity and Deps https://www.eventedmind.com/classes/meteor-meteor-reactivity...

Meteor also started putting together a manual to explain the core concepts http://manual.meteor.com — the first chapter is about the Deps package.

With any new concept there is a learning curve. But I believe the concepts meteor introduce are too powerful to ignore. The saying is that any sufficiently advanced technology is indistinguishable from magic :)

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

#42

Post by waitingkuo »

jonperl wrote: post #41
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…

What is nice about meteor is how quickly you can get off the ground and build something with it. Then you realize: I have no idea how this stuff works. Is it secure? When do things update? Is there too much magic? But if you spend a bit of time learning how meteor’s core packages work (deps, ddp, livedata, blaze, etc) and how they work together — almost all of the apprehension disappears. I recommend digging into the…

You can also take a look at http://manual.meteor.com/#deps , which is provided by meteor offically

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

#43

Post by jonperl »

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 template inclusion {{>template myDict}}.

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

#45

Post by progx »

primigenus wrote: post #31
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…

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…

1 cent for every new System that promise no spaghetti code and i will be rich ;-)

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

#46

Post by pdkl95 »

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, on the other hand, looks more like a rendering error than any kind of real content.

Don't bother replying with the usual nonsense assertions that "everybody has js", variations of "js is mandatory/expected", or that not running js in stupid/luddite. Sorry, with pages asking for js from 10-20 hosts and the current drama about network security, js is whitelist only. So give me a reason if you want to be added to that whitelist. This means actual content, not "I'm too lazy to statically render a copy on the server".

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

#47

Post by coffeemug »

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…

> js is whitelist only

You're not representative of the majority of online users. Not even close, by an enormous margin (95% of people don't know what JavaScript is, let alone how to disable it; out of the remaining 5% that do know, 4.999% don't care). Given that you're in an extreme minority and wield no power in the marketplace, could you give them a reason as to why they should dedicate development time to making this use case work?

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

#48

Post by dburles »

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…

This is something that's on the roadmap, though currently there is an unofficial package available.

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

#49

Post by seanmcdirmid »

coffeemug wrote: post #47
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…

> js is whitelist only You're not representative of the majority of online users. Not even close, by an enormous margin (95% of people don't know what JavaScript is, let alone how to disable it; out of the remaining 5% that do know, 4.999% don't care). Given that you're in an extreme minority and wield no power in the marketplace, could you give them a reason as to why they should dedicate development time to making…

That makes me wonder: what is Lynx's market share these days?

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

#50

Post by BtM909 »

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…

You're completely right. Although I think meteor is eating its own dogfood ;)

Normally you would use meteor for your webapplication and only render the dynamic parts with meteor instead of the entire page.

Post reply on HN