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

Meteor Raises $20M

techcrunch.com

Post reply on HN
Print view View original

141–150 of 163 posts

Re: Meteor Raises $20M

#141

Post by sgdesign »

murbard2 wrote: post #56
sergiotapia wrote: post #26

Earlier quoted context omitted.

Do yourself a favor and set aside a weekend to go through this book: https://www.discovermeteor.com/ All of your questions are answered there.

It's not cheap and I can't even find a table of content for it. I've also read excerpts that dealt with autopublish etc, and they didn't really address the point I'm making. Is there a benefit to using meteor beyond the fast prototyping? I'm not saying that's not potentially a huge benefit, but once you're done with your prototype, I still feel like you have to rewrite the whole thing.

The table of contents is right there on the homepage. And you can read the first four chapters for free here: http://book.discovermeteor.com

Re: Meteor Raises $20M

#142

Post by danellis »

sergiotapia wrote: post #139
Xixi wrote: post #135

Earlier quoted context omitted.

A lot of software engineers are wary of frameworks/tools with an emphasize on ease-of-use over security, or benchmarking over data integrity. Rightly so in my opinion. It leaves a "I should triple check everything again before going live since I cannot trust the tool to do its job" thread running permanently in the back of the mind. It's such a slowdown. Don't get me wrong, it's important to read the documentation an…

I agree with what you're saying, but a lot of people make it look like Meteor allows XSS and SQL Injection by default. You really only need to remove autopublish from the get go right after meteor create foobar and you begin with a secure app.

You should never have to do anything to become secure. The mantra is: secure by design; secure by default; secure by configuration.

Re: Meteor Raises $20M

#143

Post by shams93 »

Lol Meteor just literally saved my bacon, the combination of meteor + ionic enabled me to build an entire app in less than two weeks working part time on it and if I hadn't told the client it wasn't native there was no way for them to tell, the performance is that good. Plus the error messaging is awesome and the isometric approach is just a huge win, the previous version of the product was in angular + rails, industry standard but slow as hell, absolutely did not perform like a native mobile app, but Meteor is just fantastic in my experience for extreme starup scenarios where we are going with Mongo anyways. Certainly if I needed to tie into legacy sql based systems I would be looking at loopback, but with lookback you are still stuck with the weight of the other available front end frameworks and the back end is easier, but you still have to do tons of boiler plate, except perhaps with react + loopback in the case of place a really modern front end on a legacy system while still having ok performance. Meteor feels native because you're not issuing all this old ajax, its data format is even smaller and tighter than json.

Re: Meteor Raises $20M

#144

Post by aliakhtar »

smileysteve wrote: post #125
aliakhtar wrote: post #109

For those who're looking for a full stack framework, I can't recommend GWT enough. GWT lets you write java for both client & server, and then compiles the client code to javascript. This compiled js is highly optimized and your css / images / html templates are bundled together to minimize HTTP requests. On the server side, this lets you use java which is a lot more performant than javascript is.

> On the server side, this lets you use java which is a lot more performant than javascript is. Is it? http://benchmarksgame.alioth.debian.org/u64/javascript.html

Yep: https://www.techempower.com/benchmarks/

Its also fairly obvious that a statically typed / compiled language will have better performance than an interpreted language. Compiler optimizations make a huge difference as well.

Also, even the link you gave shows js being slightly faster in 2 or 3 benchmarks, but for the remaining 4-5, java is significantly faster.

Re: Meteor Raises $20M

#145

Post by accounthere »

debaserab2 wrote: post #71
sergiotapia wrote: post #31

Earlier quoted context omitted.

What you're saying is only true on a barebones default Meteor app. Please don't comment on a tool if you've never used it for anything other than a hello world, you're doing a very sophisticated tool a huge disservice. You remove the autopublish package and you can no longer query records from the client.

There's no excuse for insecure defaults.

It's more of a development default.

Re: Meteor Raises $20M

#146

Post by morgante »

rezistik wrote: post #42
smanuel wrote: post #5

That's cool. Does Meteor actually make, sorry for using such a dirty word, money from something?

Some investments are multipliers not profit centers. If you invest in 9 companies that use Meteor then investing in Meteor means you've invested in those 9 companies. It's an investment in infrastructure.

> If you invest in 9 companies that use Meteor then investing in Meteor means you've invested in those 9 companies. It's an investment in infrastructure.

Except that I don't think you could find a single a16z, Matrix, or Trinity startup actually using Meteor in production.

Meteor is great for toys and prototypes. But as soon as you start wanting to build an actual organization and team, it's the exact opposite of what you want.

Re: Meteor Raises $20M

#147

Post by djmashko2 »

murbard2 wrote: post #68
djmashko2 wrote: post #57

Earlier quoted context omitted.

Here's step 10 of the tutorial, which demonstrates how you can write custom RPCs to handle writing data in Meteor: https://www.meteor.com/try/10 You don't have to use the client-side insert/update/remove syntax if you don't want to. Unless you add an 'allow' call to let some of them through, they will all be automatically rejected by the server. (I work at Meteor)

Thank you, I know that you can do that. My concern is more of a soft question: in practice, in production, isn't that what you always end up doing anyway? And if that's the case, how much of meteor's coolness is lost in the process? If I'm going to be writing rpcs for all writes, why not just use some websocket library?

Meteor's RPCs support automatic optimistic UI updates, where the same code can be used to update the client side data store and the server side database, resulting in the perception of zero latency between server and client.

Building that functionality out yourself from scratch could be difficult, since all of the components of Meteor work together to make that experience possible.

Re: Meteor Raises $20M

#149

Post by dsyko »

murbard2 wrote: post #55
primigenus wrote: post #52

Earlier quoted context omitted.

> For intance, when is it ever OK to let your client write directly in the database, even for their own data? If you're going to pass their calls through a deny and allow call, why not just expose RPCs to the client that will handle any writing? If you have a client-side mirror of your server-side database whose changes are monitored by the templating engine, you can execute what Meteor calls "latency compensation",…

Sure you remove the autopublish package, but then your app stops working. You need to explicitely publish what you want published, you need to explicitely check and validate every input from the client... and that's fine, but then what exactly have you gained from using meteor over, say, socket.io or autobahn? Fast prototyping, yes, you've definitely gained that, but have you gained anything else? I'm genuinely askin…

To answer your first question, there are a number of attractive advantages to using Meteor over say socket.io or autobahn on top of Node. One major one would be a consistent API for accessing your data on the Client and Server. I would argue that using Javascript on both backend and frontend with Node boosts a developer's productivity by reducing language/context switching. In the same vein accessing data using the Mongo query api on both backend and front end with Meteor's MiniMongo improves development. Also Meteor comes with built-in latency compensation when using either RPCs (with stubs on the client) or Minimongo operations. Latency compensation is a non-trivial problem which would need to be implemented by the developer when using something like socket.io. You also gain access to a growing list of great packages that implement things like user accounts which you would otherwise need to write yourself or wire together from various projects.

As for your second question. There are certainty use cases where MongoDB isn't appropriate, and support for other databases is on Meteor's roadmap. For now there are some community created packages for interfacing directly with SQL databases in place of MongoDB, but there are a number of issues with them. You could also pipe data in and out of an SQL database inside RPCs, however the data would not be updated in 'real-time' to clients. I anticipate SQL databases will get some good support options in time.

Re: Meteor Raises $20M

#150

Post by murbard2 »

rglover wrote: post #124
murbard2 wrote: post #18

I'm actually looking into meteor at the moment, and the financial backing is a big plus, as it gives me some guarantee that the project will keep being maintained for the foreseeable future. It is indeed a breeze to prototype applications with it, but I am a little bit concerned about the costs of getting an actual production ready site with it. For intance, when is it ever OK to let your client write directly in the…

> For intance, when is it ever OK to let your client write directly in the database, even for their own data? If you're going to pass their calls through a deny and allow call, why not just expose RPCs to the client that will handle any writing? Good question. A pattern I like to use for this in Meteor is to rely solely on their Method calls which allow you to restrict any database ops to the server side. The trick i…

Yes, thanks, sort of! The pattern you use is basically the one I would naturally do, but it doesn't feel "meteoritic"... the client side manipulation of the db really seems centric to the magic of it.

Regarding the concurrent store, forget event about the client. You need to check whether or not the inventory has been depleted and then update the inventory, and create the client's invoice. That means blocking calls, double staged commits, and a whole lot of nasty things that have nothing to do with reactivity and everything to do with integrity.

Post reply on HN