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

211–220 of 250 posts

Re: Meteor hits 1.0

#211

Post by kristiandupont »

aliakhtar wrote: post #160
imslavko wrote: post #155

Earlier quoted context omitted.

The logic runs on the client only for optimistic UI changes (getting to the right state and displaying the right data w/o waiting for a server to reply). In Meteor this is called "latency compensation" and you can read more about it here: https://www.meteor.com/full-stack-db-drivers . Meteor implements it in such a way, that app developer decides what logic is latency compensated and what is not. Furthermore all the…

Querying your database from client javascript seems like a bad idea. Even if they're not real queries, you are exposing the internals of your system, db column names / queries, etc.

Why would that be a bad idea? Unless you are relying on security through obscurity, which you are hopefully not, that shouldn't create any threats?

Re: Meteor hits 1.0

#212

Post by KhalPanda »

dandv wrote: post #179
general_failure wrote: post #167

What is meteor's revenue model? What am I missing...

Galaxy, an enterprise-grade, multi-tenant hosting environment for Meteor apps - https://www.meteor.com/blog/2012/07/25/meteors-new-112-milli...

For a second there I was like "Woah! $112M?". Damn friendly-URL's.

Re: Meteor hits 1.0

#213

Post by mrcwinn »

GordyMD wrote: post #206

I am excited to give Meteor a go and take advantage of its isomorphic nature. I am particularly excited by the potential of being able to swap out Mongo for RethinkDB ( https://github.com/tuhinc/rethink-livedata ).

That project has been abandoned, it seems, and wouldn't work with 1.0.

Re: Meteor hits 1.0

#216

Post by notastartup »

nathan-muir wrote: post #193
notastartup wrote: post #141

Earlier quoted context omitted.

> * You're product has realtime/ collaborative elements that are a SELLING feature [not just for your personal enjoyment]. What opportunities exist in the enterprise market that specifically benefits from this feature?

Sky is the limit here. Low latency (real-time) can be an important part of effective and engaging communication. Sure, it's not for everything; I wouldn't want my email communicating word by word to my recipients as I typed. However, enterprises usually involve a lot of communication - with team members, stakeholders, and clients. - there are many opportunities to spice things up and make them more engaging & effecti…

In what specific industries are these needed? I'm curious as to how I can build an enterprise app in meteor.js.

Re: Meteor hits 1.0

#217

Post by notastartup »

dandv wrote: post #178
notastartup wrote: post #141

Earlier quoted context omitted.

> * You're product has realtime/ collaborative elements that are a SELLING feature [not just for your personal enjoyment]. What opportunities exist in the enterprise market that specifically benefits from this feature?

I'm working on Google's Governance, Risk and Compliance management system.[1] Porting it to Meteor would accomplish several goals: * clean and much simpler code base * automatically (reactively) updated status reports on compliance across various systems depending on numerous components throughout Google in continuous flux * ease of onboarding new developers in the team given the simplicity and ease of learning of Me…

I worked with Meteor.js on an enterprise app a year ago but it seems to be more mature now. I think this is a great time to begin porting it.

Re: Meteor hits 1.0

#218

Post by pluma »

mrcwinn wrote: post #133
djmashko2 wrote: post #110

Earlier quoted context omitted.

(Disclaimer: I work at Meteor) That box is referring to the data syncing, event handling, and view rendering code that you don't have to write when you use Meteor, compared to some of the previous generation frameworks. If you put together the right list of cutting-edge components like React, Firebase, Bootstrap, and some build tools, you might get a similar improvement in code simplicity. Our goal at Meteor is to gi…

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 don't use Grunt or Gulp. If I want to re-bundle my client, I invoke a script that essentially does `browserify -g uglifyify lib/browser.js > dist/main.min.js`. My JSX build script and the bundler script are automatically invoked by a watcher.

This[0] is my entire build script and the only reason it's verbose is because I like to be able to execute each task separately if I want to.

The only problem with React is that it is only a view library. It only does components. The blessed solution is a Flux-like architecture as implemented by Fluxxor or Reflux, but you can integrate React into nearly anything you already have. I like the immutable/unidirectional approach React and Flux share and ended up writing my own library[1] because there were things I didn't like about the existing Flux implementations, but you don't have to do that.

I have to admit that Flux has a steep learning curve. And if you've never dealt with immutability before it can really melt your brain. But I don't see how Meteor is any easier to pick up, especially considering that it comes with its own entirely separate ecosystem (the only non-node library I use in my React app is an XHR-wrapper that replaces `request` on the client).

[0]: https://gist.github.com/pluma/61a1639906e188be8423

[1]: https://github.com/foss-haas/flox

Re: Meteor hits 1.0

#219

Post by pluma »

mrcwinn wrote: post #101

There's a lot to like about Meteor. Just compare setting up some kind of "dream team" of JavaScript: Rendr + React + Grunt + JSX = OMG WHERE DID MY FRIDAY NIGHT GO. Meter out of the box "just works," but it only works with Mongo for now, and it only works if you are all-in with the platform — on both the client and the server side. Those are two pretty big bets to make. I would say Meteor is ideal for learning, excep…

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 can find that suggests using Rendr with React is over a year old. React can be rendered on the server just fine. The only thing you need to solve outside React is routing, getting the data and making it available to your React components. Either use stores or pass all the data as `props`.

Thirdly, why Grunt? If you talk about a "dream team", I'd think Gulp is the current hotness, not Grunt. And you don't need either of them anyway, there is so little to configure that you don't even need a full-blown build tool.

I don't have a single line of database code in my React app. All the API calls are handled by a small wrapper around my database's domain-specific HTTP API. I could use the same API with zero changes for a native mobile app or a new web app that doesn't use any of the existing code. My web server is a dumb proxy for the database API and a pre-rendered for React (the pre-renderer essentially consists of a single line of JavaScript).

I can understand the appeal of Meteor, but it's not like anything you complain about has to do with React.

(Now Angular on the other hand... let's hope you don't need any prerendering ever.)

Re: Meteor hits 1.0

#220

Post by pluma »

jakozaur wrote: post #105
mrcwinn wrote: post #101

There's a lot to like about Meteor. Just compare setting up some kind of "dream team" of JavaScript: Rendr + React + Grunt + JSX = OMG WHERE DID MY FRIDAY NIGHT GO. Meter out of the box "just works," but it only works with Mongo for now, and it only works if you are all-in with the platform — on both the client and the server side. Those are two pretty big bets to make. I would say Meteor is ideal for learning, excep…

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, but that's an implementation detail.

Meteor is not a node-based stack. That's why it now has its won package manager instead of npm. It's a competitor to node with its own ecosystem. And that's fine.

Post reply on HN