31–40 of 45 posts
Holy "shiny new tech buzzword compliance" batman! This is hipster dev certified!
Now that you've gotten the Reddit out of your system, how do you really feel about this project?
This is a Meteor.js killer right here folks!
Looks like everyone's hopping on the React bandwagon, trying to grab a piece of the hype.
Looks like everyone's hopping on the React bandwagon, trying to grab a piece of the hype.
It's not without its issues, but it's really changed the way I build things, which after 18 years is kind of impressive.
I guess this is intended for trusted clients?
Is there such a thing? ;-) This file shows how they authenticate users: https://github.com/mikemintz/react-rethinkdb/blob/master/exa...
So if you log in and authenticate (through that file), it seems like you can just open the javascript console in chrome and run any type of db query you want.
Earlier quoted context omitted.
Is there such a thing? ;-) This file shows how they authenticate users: https://github.com/mikemintz/react-rethinkdb/blob/master/exa...
I think the issue is that the client code is running actual database queries on the server, and I don't see any restrictions on what queries can be executed. So if you log in and authenticate (through that file), it seems like you can just open the javascript console in chrome and run any type of db query you want.
Earlier quoted context omitted.
Is there such a thing? ;-) This file shows how they authenticate users: https://github.com/mikemintz/react-rethinkdb/blob/master/exa...
I think the issue is that the client code is running actual database queries on the server, and I don't see any restrictions on what queries can be executed. So if you log in and authenticate (through that file), it seems like you can just open the javascript console in chrome and run any type of db query you want.
Looks like everyone's hopping on the React bandwagon, trying to grab a piece of the hype.
I think a lot of people make snap responses to the subject of new developments in the JS world because they see a lot of change happening, do not trust any of it, but also haven't bothered to further their education on the subject.
I'm curious to hear comments from those who are very knowledgable on React but also view it as a bandwagon.
Earlier quoted context omitted.
> Unfortunately in the Ruby world live webservices like this haven't really taken off much yet And they probably never will, whatwith blocking I/O being the norm and no decent concurrency primitives. Too many better alternatives at this point.
The choice of I/O model has nothing to do with Ruby (see eventmachine for a commonly-used evented NIO setup). If you want asynchronous io with an event-driven model, there are good options for most languages.
Earlier quoted context omitted.
Never did any Ruby, nor Node.js, so take this with a grain of salt. What I understood the OP to mean, and what I experienced myself, is that a language needs to actively promote (OS-level) async I/O for it to be usable, not just support it. If sync I/O is the default, too many libraries will use it (it's easy and works fine, until it doesn't). Because Node.js has no threading, async I/O is the only choice. Result: 10…
This is exactly my experience as well. If you provide synchronous, blocking interfaces and no concurrency primitives or expectation of non-blocking functions, IO, etc., people will use them. In languages where concurrency is a built-in, understood pattern (Go, Erlang/Elixir, Haskell*, to name a few) people don't need to care. Ruby has the worst of many worlds (sync I/O by default, incredibly expensive memory model, i…
Anyway, I do agree with your argument. Unfortunately Ruby is from the generation of programming languages in which I/O was just seen as an api, so the sane thing was to just map to the system api directly.
JavaScript is from that generation as well but got lucky because its requirement to run in the browser forced it to have I/O fully abstracted.