Live data from Hacker News

Relay Modern: Simpler, faster, more extensible

code.facebook.com

81–90 of 111 posts

Re: Relay Modern: Simpler, faster, more extensible

#81
post #80

Seriously, your own homegrown garbage collection inside the js runtime? I looked at React the first time it came out and aside from the insanity of using xml mixed with javascript or some kind of pseudo js, it was waaaay too complex. I dont know but it seems crazy to me to write applications like that, it makes xaml look decently simple.

I still firmly believe riot.js (http://riotjs.com/) is the best "react-like" tool even though it's almost entirely unknown (sadly) and its website/PR/general presentation is a bit janky.

It's essentially a very very tiny, minimally opinionated structural layer that lets you build html components (called "tags") using almost entirely vanilla JS. It inverts the JSX paradigm: where JSX is "html in the middle of your code", in riot the markup is primary and the code is a supplement to it (expressions in the markup via templates/mustaches, additional tag-specific script added outside of the markup if desired, tag-specific scoped css) so there's no JSX insanity.

It's like a much leaner react/vue, and frankly I love it. It's entirely minimal and you can bring in any library you want to use along with it (e.g. jquery for ajax, redux if you want...). It has virtually no cognitive load (just looking at a sample "tag" file for 2 minutes gives you ~80% of what you need to know), you just pick it up and work with it and just occasionally peek at the docs if needed.

I'm a huge fan of the "minimally opinionated" approach. The fewer idiosyncrasies and custom abstractions in tools, the more productive you are (I'm looking at you, angular!).

Re: Relay Modern: Simpler, faster, more extensible

#82
post #80

Seriously, your own homegrown garbage collection inside the js runtime? I looked at React the first time it came out and aside from the insanity of using xml mixed with javascript or some kind of pseudo js, it was waaaay too complex. I dont know but it seems crazy to me to write applications like that, it makes xaml look decently simple.

FB employs one of the world's best C++ developers (Andrei Alexandrescu) to write custom string implementations and maintain/extend their homegrown PHP VM. Their development practices would be completely unsustainable for any company that has anything resembling economic accountability.

Re: Relay Modern: Simpler, faster, more extensible

#83
post #80

Seriously, your own homegrown garbage collection inside the js runtime? I looked at React the first time it came out and aside from the insanity of using xml mixed with javascript or some kind of pseudo js, it was waaaay too complex. I dont know but it seems crazy to me to write applications like that, it makes xaml look decently simple.

I feel you're being disingenuous here. They're just talking about automatic cache eviction, which wasn't possible/trivial with the previous version of Relay.

Re: Relay Modern: Simpler, faster, more extensible

#84
post #80

Seriously, your own homegrown garbage collection inside the js runtime? I looked at React the first time it came out and aside from the insanity of using xml mixed with javascript or some kind of pseudo js, it was waaaay too complex. I dont know but it seems crazy to me to write applications like that, it makes xaml look decently simple.

I still firmly believe riot.js ( http://riotjs.com/ ) is the best "react-like" tool even though it's almost entirely unknown (sadly) and its website/PR/general presentation is a bit janky. It's essentially a very very tiny, minimally opinionated structural layer that lets you build html components (called "tags") using almost entirely vanilla JS. It inverts the JSX paradigm: where JSX is "html in the middle of your c…

I also found Riot very practical, mostly because I got up and running very quickly. I had a well-structured Riot app done faster than grasping all that ReactJS boilerplate.

And this was possible even though the Riot documentation was sub-optimal in some places, to say the least - the holes in the documentation were compensated by the fact that most things are simple and straight forward.

I don't know how good this concept scales to huge applications, but I can confirm that writing a non-trivial SPA in Riot was a charme.

Neverthelss, I do miss some things the Riot for the overall architecture and information flow. But I learned that ReactJS doesn't have these either. As with React, Riot should be combined with Flux, or a lightweight alternative such as Redux.

Re: Relay Modern: Simpler, faster, more extensible

#85
post #84

Earlier quoted context omitted.

I still firmly believe riot.js ( http://riotjs.com/ ) is the best "react-like" tool even though it's almost entirely unknown (sadly) and its website/PR/general presentation is a bit janky. It's essentially a very very tiny, minimally opinionated structural layer that lets you build html components (called "tags") using almost entirely vanilla JS. It inverts the JSX paradigm: where JSX is "html in the middle of your c…

I also found Riot very practical, mostly because I got up and running very quickly. I had a well-structured Riot app done faster than grasping all that ReactJS boilerplate. And this was possible even though the Riot documentation was sub-optimal in some places, to say the least - the holes in the documentation were compensated by the fact that most things are simple and straight forward. I don't know how good this co…

>Neverthelss, I do miss some things the Riot for the overall architecture and information flow. But I learned that ReactJS doesn't have these either. As with React, Riot should be combined with Flux, or a lightweight alternative such as Redux.

As long as you remember that you're doing Model-View-Whatever, you can structure a riot (or react/vue for that matter) application fairly lucidly and without too much friction. You want the application state (~Model) to reside in a separate container, and the riot/react/whatever custom tags (~Views) should be fairly lean and strive only to display and trigger operations on the state (i.e. either call functions exposed by the state object, or trigger/listen to state events), while storing as little state as needed locally. If you're lazy like me, you can make the app state container a global - otherwise just pass a pointer to it to every tag (Flux).

Redux helps with the minimization of local state by emphasizing pure functions, and thus encourages the required minimal state to be passed in as function parameters when needed (and in the localest scope needed). That's really the genius of it, imho - functional purity keeps the state tidy.

Riot's (optional) solution is an "observable" functionality which can be attached to any object (e.g. the state container itself or a child thereof), and tags and other objects can then listen to events on those objects and update themselves accordingly (pretty classic pattern - but being minimal and "vanilla" is the point of Riot anyway), and so I find myself using this and not going with Redux, for the sake of productivity, even though it's a little bit sloppier than Redux.

Re: Relay Modern: Simpler, faster, more extensible

#86
post #82
post #80

Seriously, your own homegrown garbage collection inside the js runtime? I looked at React the first time it came out and aside from the insanity of using xml mixed with javascript or some kind of pseudo js, it was waaaay too complex. I dont know but it seems crazy to me to write applications like that, it makes xaml look decently simple.

FB employs one of the world's best C++ developers (Andrei Alexandrescu) to write custom string implementations and maintain/extend their homegrown PHP VM. Their development practices would be completely unsustainable for any company that has anything resembling economic accountability.

Ah, many companies have homegrown languages they use internally. You don't even have to be a big company to do so. Wasabi is an example of that.

Re: Relay Modern: Simpler, faster, more extensible

#87
post #82

Earlier quoted context omitted.

FB employs one of the world's best C++ developers (Andrei Alexandrescu) to write custom string implementations and maintain/extend their homegrown PHP VM. Their development practices would be completely unsustainable for any company that has anything resembling economic accountability.

Ah, many companies have homegrown languages they use internally. You don't even have to be a big company to do so. Wasabi is an example of that.

True; I just disagree with the general tendency to treat everything FB or Google does as the holy grail of best practices (or even good at all) for the average company.

Re: Relay Modern: Simpler, faster, more extensible

#88
post #34

Earlier quoted context omitted.

> the day when Facebook gives up on flow and adopts Typescript will be a glorious, glorious day. I foresee FB to skip TypeScript and go straight with ReasonML[0], as 25%[1] of the messenger code base supposedly is already converted to Reason. And I think that is even more glorious development then FB going with TypeScript. :) [0]: An easier to approach (for programmers coming from mainstream languages; like JS/C++/Ja…

Last time I looked at reason it was totally new and there was no tooling etc. I got little support from the gitter or whatever it was. Have things changed? It really interested me at the time.

It was a bit tough to get tooling set up and it doesn't work on Windows, but on Mac (and Linux I assume) it's amazing. Better Intellisense support in VSCode than Typescript!

It is very new though, and I haven't got a complete grip of JS FFI with Reason.

Re: Relay Modern: Simpler, faster, more extensible

#89

One of the things that I've noticed about the javascript community is that they're re-inventing stuff from previous technologies - sometimes badly - but almost always with a willful ignorance of what has gone before. While this doesn't look like a bad idea - what they've done is to re-invent stored procedures. Back in the original object orientated wars this turned out to be a mixed blessing. You could get quite shar…

I don't think this is what they have done. They've invented a client/server data model, schema definition and associated query language. Definitely wheel-reinventing, but imho a useful valid wheel which stored procedures were not. If it were like stored procedures the relay code would be running on the server. It runs in the client.

Re: Relay Modern: Simpler, faster, more extensible

#90
post #80

Seriously, your own homegrown garbage collection inside the js runtime? I looked at React the first time it came out and aside from the insanity of using xml mixed with javascript or some kind of pseudo js, it was waaaay too complex. I dont know but it seems crazy to me to write applications like that, it makes xaml look decently simple.

This isn't JS runtime object garbage collection. As others have said, it's cache eviction. Bad naming, perhaps.

But if React is too much for you (tiny API surface, can learn in an afternoon), Relay will be way too much. I wouldn't bother reading more about them.

Post reply on HN