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

Meteor hits 1.0

meteor.com

Post reply on HN
Print view View original

241–250 of 250 posts

Re: Meteor hits 1.0

#241

Post by dmak »

pluma wrote: post #220
jakozaur wrote: post #105

Earlier quoted context omitted.

Yeah, one of the common critique is that "Meteor" does too much and doesn't integrate well with other stuff. For me it's a main advantage, I don't need to use "other" stuff to get the final effect. I wrote few projects and it's the best framework if you start from scratch. Though it's hard to swell if you need to add it later to some existing project.

I absolutely agree, but I don't understand why Meteor is frequently seen as a competitor to React or AngularJS or Ember. It's a competitor to combinations like node/browserify and full-stack solutions like Wakanda. Meteor doesn't integrate with anything, but that was never a design goal. If you switch from Meteor, you can likely discard your entire stack (well, except the database obviously). It's based on node, sure…

Well, you can compare it as a fullstack too. It is mainly compared with React, Angular, and Ember as a reactive framework which isn't an incorrect comparison and is very valid.

Re: Meteor hits 1.0

#242

Post by dmak »

liscovich wrote: post #139

I wonder if the criticism that the Flux team at Facebook has directed at two-way data binding is also applicable to Meteor. Jing Chen is her intro of Flux ( https://www.youtube.com/watch?v=nYkdrAPrdcw&list=PLb0IAmt7-G... ) says that two-way data binding creates a major challenge for scaling applications because views can trigger changes in data, and data changes can trigger cascading changes in views, which makes it…

That's an interesting point. I find two-way binding to be very convenient, but I wonder if the industry is moving towards a one-way bind solution (at least it seems like a common theme with most front-end frameworks).

Re: Meteor hits 1.0

#245

Post by pluma »

dmak wrote: post #241
pluma wrote: post #220

Earlier quoted context omitted.

I absolutely agree, but I don't understand why Meteor is frequently seen as a competitor to React or AngularJS or Ember. It's a competitor to combinations like node/browserify and full-stack solutions like Wakanda. Meteor doesn't integrate with anything, but that was never a design goal. If you switch from Meteor, you can likely discard your entire stack (well, except the database obviously). It's based on node, sure…

Well, you can compare it as a fullstack too. It is mainly compared with React, Angular, and Ember as a reactive framework which isn't an incorrect comparison and is very valid.

Sure, but good luck replacing React/Angular/Ember in your Rails/Django/Node/What-have-you app with Meteor.

It's not really a relevant option unless you are at liberty to swap out the entire stack. It makes more sense to compare Meteor with MEAN rather than simply AngularJS itself.

Re: Meteor hits 1.0

#246

Post by pluma »

dmak wrote: post #240
pluma wrote: post #219

Earlier quoted context omitted.

First of all, why is JSX in that list? It's essentially an ES6 transpiler with syntactic sugar for nested function calls. If you mean the additional build step it requires, that doesn't really make sense either: you should be bundling and minifying your client assets already and JSX is just another (fully transparent) link in the build chain. Secondly, why Rendr? Rendr was built for Backbone. The most recent info I c…

I am still using Grunt, and have been wondering how Gulp is. How do you like it? Why is it better?

I switched from Grunt to Gulp because I never liked Grunt's focus on configuration over code. But that's entirely a matter of taste. It's not "better" or "worse" than Grunt, it's just a different approach.

Gulp is pretty neat, until you try to integrate watch tasks. Want to run a transpiler whenever a file changes? Better don't have any compile-time errors or your stream will choke and die (without necessarily killing the process, mind you).

There are some workarounds (e.g. gulp-plumber), but depending on the actual tool you're trying to use they may not actually work -- or only work sometimes, which can be just as bad as not working at all.

Personally I've switched from Gulp to just putting scripts in my package.json file as god (or Isaac) intended. Every tool I want to use has a CLI anyway, and supports stdin/stdout, so it's all just Unix legos anyway. Except for browserify, which I replace with watchify in development for performance reasons (browserify in a large project can take a few seconds, watchify only updates the diffs).

Re: Meteor hits 1.0

#247

Post by pluma »

dmak wrote: post #239
pluma wrote: post #218

Earlier quoted context omitted.

I'm using React. My server-side rendering is essentially `React.renderComponentToString(App(data))`. The only difference between how I invoke my app on the server vs on the client is that instead of `React.renderComponent` I use `React.renderComponentToString`. On the client, React just uses the pre-rendered HTML and binds itself to that without re-rendering a single DOM node. All my scripts are in `package.json`. I…

I agree with you that it probably is not easy to pick up, but I have to admit, there is significantly less to deal with. Meteor is the fullstack, and it even has sockets built into it. You definitely have to buy into one ecosystem, and that's convenient because you don't have to know a serverside ecosystem (e.g. Rails) and a frontend ecosystem (e.g. Angular, React, and Ember).

Sure, but my current ecosystem is npm. For browser-specific substitutes to node-specific code I simply use browserify. If I decide React is boring, I can switch to an entirely different front-end without changing anything else. For stuff that isn't on npm I have to work with bower or something else, but that (i.e. ecosystem-external dependencies) is a problem in any application, not specific to npm.

With Meteor, you're developing Meteor apps. Sure, you can put a different front-end in it or replace its server-side with an API compatible equivalent, but that's like saying you can use Django without its template system or ORM (if you don't know anything about Django: you can, but Django's built-ins provide a lot of synergy that you can only get from tight coupling).

Re: Meteor hits 1.0

#248

Post by aryehof »

akhatri_aus wrote: post #46

Congrats to the Meteor team on 1.0! We're building our app http://servicelocale.com on it for high quality services & crafts in Australia.

This site takes about 15 seconds to load on my iPad in Europe, which is so slow someone is likely to tab away.

I haven't looked into fast-render mentioned elsewhere, but initial load time has always been a issue, and it seemingly gets worse as you add more functionality to your 'app'.

Personally, I'd only consider betting on Meteor for anything non-trivial once some form of incremental/optional loading of functionality was included.

Re: Meteor hits 1.0

#249

Post by ak39 »

sbking wrote: post #226
ak39 wrote: post #175

Earlier quoted context omitted.

Thanks for this info. Does it have to use Node.js on the server can the client side framework work with any server side JSON service?

You need to be running the Node.js Meteor application. The client relies on DDP rather than REST and right now Meteor is the only server framework using DDP. There is, however, an isomorphic HTTP library which makes it easy to communicate with third party REST APIs on both the client and server. It is also easy to create REST endpoints for your Meteor collections, so that third party services which don't support DDP…

Thanks!

Re: Meteor hits 1.0

#250

Post by uptownJimmy »

pluma wrote: post #218
mrcwinn wrote: post #133

Earlier quoted context omitted.

I'm doing a rebuild of a personal project over the holidays and I spent some time looking into binding together React, Airbnb's Rendr, and JSX through Browserify and Grunt. It's possible, but it's a nightmare. Meteor definitely succeeds and just delivering that. (Not that that is the only requirement you might have.)

I'm using React. My server-side rendering is essentially `React.renderComponentToString(App(data))`. The only difference between how I invoke my app on the server vs on the client is that instead of `React.renderComponent` I use `React.renderComponentToString`. On the client, React just uses the pre-rendered HTML and binds itself to that without re-rendering a single DOM node. All my scripts are in `package.json`. I…

Two problems here:

1. "I have to admit that Flux has a steep learning curve." & "But I don't see how Meteor is any easier to pick up..." are mutually-exclusive.

2. Most everything else you wrote does a pretty good job of representing why Meteor is so attractive to some of us.

Post reply on HN