I'm really sorry to hear about the difficult time you've been having. I can see how that would make an already thankless job like maintaining an open source project even more frustrating.
During my time as a Lerna contributor I was careful NOT to abuse my power. The few times I merged PRs I checked with Henry first. I pinged you at the beginning, too, but stopped eventually when I didn't hear from you. Mostly what I did, though, was triage issues and work with other contributors to get PRs into shape. I spent a lot of time over the summer working on Lerna, and only a small part of that was the code I wrote myself.
Then, suddenly, you started deleting my comments and locking my issues. You removed me from the organization without any discussion. That seemed to me an abuse of YOUR power. It hurt.
Please re-read the first comment of mine that you deleted. It wasn't meant to be aggressive. It was a plea.
---
My inspiration here comes primarily from two sources:
1. Using Lerna every day and thinking about how it could be improved to make my life easier.
2. Listening to feedback from _other_ Lerna users about how it could be improved to make _their_ lives easier.
You're one of the original core team, and I don't want to alienate you. Your rewrite of Lerna put in place a foundation that has been a pleasure to work with. But lately maintenance and improvement has continued in your absence thanks to contributions from Lerna's fledgling user community. Do you plan to reassume this responsibility?
---
That was here [1], but you deleted it and then locked the issue. I hope as you read it now you can see why it was surprising and hurtful that this was your response.
For routing of URL paths to "page" objects we use Yahoo's `routr`.
We've tried to keep data store selection out of React Server core. There are so many good options in the React ecosystem that picking one seems limiting.
The data bindings that the framework cares about are at the http request level. We have a wrapper around `superagent` that manages transfer of response data from the server to the browser. So, when the client controller wakes up in the browser and tries to make the same requests that the server just made while _it_ was rendering the page, the data is already present and the requests are short-circuited.
I'm totally on board with the "contributions welcome" response from open source maintainers, but when it's the only response to questions about documentation it's pretty off-putting. This is your project, how could you expect a new contributor to add docs without your input? I get that good documentation is hard, and takes time, but if you want your project to succeed I think it's almost mandatory for you to write these docs (at least the initial version!) yourself.
I have to agree here. There's nobody better to explain how something really works than the person who wrote it. The rest of us are just fumbling around guessing.
As a dev and a creative person, I understand the desire to get something out there. But documentation and tutorials aren't just something that's nice to have. They are your marketing tool, your adoption driver, and the way to create educated advocates for your project. They are as valuable to your project's success as a splashy "getting started" web site is.
That process of you fumbling around and guessing is actually really extraordinarily helpful. The things a contributor might think to do or to try, and the things that a newcomer might think to do or to try, are completely different. No documentation survives its first encounter with a real newcomer. We can, and will, continue working on the onboarding experience, but we'll need real users to roll up their sleeves and wade into it, and the first few of them will have questions we didn't anticipate, and make assumptions we've never considered, and try use cases we've never thought of. Creating good documentation is something that newcomers and contributors need to collaborate on.
I completely agree. If you take a look at the closed prs with the label documentation (https://github.com/redfin/react-server/pulls?utf8=%E2%9C%93&...) I hope you get the sense that this is something that I'm thinking about a lot, and that if you look at the issues open with the same label (https://github.com/redfin/react-server/issues?q=is%3Aissue+i...), that it's something I'm working on actively. There are lots of ways to document a healthy project, from tests to tutorials to docs sites to good examples, and we've been working hard on markdown docs, tests and examples because they allow us to scale to having more contributors faster. Striking a balance between kinds of documentation is hard, and its even harder to strike a balance between the rest of the project's needs and documentation. This is a technology that we run in production, and so we have to make sure that it is fast and stable and reliable, and sometimes that means giving short-shrift to other priorities. I'm not trying to absolve us of any short-comings in our documentation -- we have a lot to do in the coming years to improve this project, and we need to spend time writing tutorials and user testing the on-boarding experience for new devs that want to start up their first React Server project -- but I do want you to understand where we're coming from when we say "contributions welcome." Its just pragmatic; we're working on it as hard and as fast as we can, its a priority I continue to focus on, and if you want it faster, the best way is to chip in.
OK, you definitely get it :) Love what you wrote below:
"No documentation survives its first encounter with a real newcomer."
I hope it didn't seem like I was accusing you of negligence – the docs you have are an awesome start, and I fully appreciate the difficulty of the problem. Best of luck with things going forward, looks like a really neat project.
gigabo's account has been rate limited, but he wants to say:
Oh, hey didn't mean to sound flippant there! We're definitely planning to make tutorials, and we're constantly trying to improve our docs. I guess my point is we want this to happen faster, but we're still a pretty small project with a small team of core contributors. So we're thrilled when we're able to bring in new contributors to help out!
I don't think that's true. It's certainly possible for somebody else to run with tutorial creation, especially if the project gets attention / exposure before the tutorials are ready.
If the response "Contributions welcome" is generic, it's because the complaint is as well.
"Contributions welcome" is often echoed, but I like to remind colleagues that it is not the proper mentality to foster a real community. You can't just dump code on GitHub and assume the world is going to start firing off PRs to do your dirty work. You have to assume that no one else cares about your project, but being open to changes in code and leadership will make your project more robust to other use cases.
The website itself is meant to serve as a demo. :)
When you land on the site the first page is rendered by the server. Then the client controller wakes up and subsequent page views ask the server for data, but render in the browser. That's what we mean by "seamless transitions".
"seamless transitions" in the web design world is often taken to mean "transitions" in the sense of CSS animations, i.e. instead of hard page refreshes elements smoothly morph into their positions in the next page state. See eg. Google's Material Design or Apple's iPhone UI. This is a big, largely-unsolved problem in HTML5, at least in making them pervasive, performant on mobile, and easy for developers. Advertising this may lead to some unwarranted excitement and subsequent disappointment, since the website doesn't really have transitions at all of this sort.
Oh, hadn't considered that interpretation. Our full project description on GitHub is "React framework with server render for blazing fast page load and seamless transitions between pages in the browser". The tag line on the website is shortened from that. I think the full version is a little less ambiguous, but it's a little too wordy in the context of the site.
Will have to think about a better tag line... Thanks!
I share nostrademons's interpretation. I'd expect the first page rendered on the server and the rest rendered on the client in any isomorphic framework. When I hear "transitions", I expect elements morphing between assets, ala neon-animated-pages:
All pages are rendered server-side by default. React Server sends each server-side rendered element as soon as it, and every element before it, are ready, up to a timeout, at which point it sends the late arrivals as they trail in. On the client side, React Server picks up where the server left off, to render client side code as the user interacts with the page.
are you asking to have a static site pre-built from React?
I'd assume when he says "first page" he means any first page but generally from there the rest becomes dynamic react. Depending on how you load your data it should be much quicker to render entirely in the browser once the page has loaded.
Well, I was thinking you could have all pages server-side rendered in the case of a low-power mobile device, and leave the hybrid approach for desktop browsers.
The user-agent string could be used to decide which approach to use.
> We're investigating reports of an issue with Google Drive. We will provide more information shortly.
https://www.google.com/appsstatus#hl=en&v=issue&sid=4&iid=c7...