React Cosmos – Build UIs at Scale(reactcosmos.org)
reactcosmos.org
React Cosmos – Build UIs at Scale
https://reactcosmos.org/
54 comments
Unfortunately, anything on HN even remotely related to Javascript seems to be scrutinized much more severely than other projects. Oh, your website uses animations? Huge problem. Emojis in the README? Worthless project. I think people come into these threads just looking to air their grievances.
Cosmos looks awesome. Thank you for all your hard work. I've been using Storybook for a while, but I'll give Cosmos a try on my next project.
Cosmos looks awesome. Thank you for all your hard work. I've been using Storybook for a while, but I'll give Cosmos a try on my next project.
I think its because everyone has so much JS fatigue
As someone who is currently learning React coming from a Rails background, the communities and their sensibilities couldn't be more different:
Rails: readability, simplicity, stability, "convention over configuration"
JS: the opposite
As someone who is currently learning React coming from a Rails background, the communities and their sensibilities couldn't be more different:
Rails: readability, simplicity, stability, "convention over configuration"
JS: the opposite
Thanks for writing this comment - indeed I feel like if I ever do make something open source, because of HN I would NEVER want anyone to actually use it - it might get posted.
Emojis in READMEs are awesome.
JS is a horrible kludge that malignantly outgrew its original purpose. Incidentally, it's also the programming language sites happen to use to become unusable and abuse the user, but we'd be in the same boat if they used Python or whatever else, so the hate for JS that comes out of that is unfair.
JS is a horrible kludge that malignantly outgrew its original purpose. Incidentally, it's also the programming language sites happen to use to become unusable and abuse the user, but we'd be in the same boat if they used Python or whatever else, so the hate for JS that comes out of that is unfair.
Its far better than it was 10 years ago - JS hate is wielded here by people who haven't used it in years. Unlike C++ the language has changed (definitely for the better). I don't even particularly care much for it but the people who will sit here and lambast it while staunchly writing C++ as if that language isn't in an even worse mess is pretty silly.
I know your take is balanced but others in HN loveeee to hate JS just because they think its what they are supposed to do.
I know your take is balanced but others in HN loveeee to hate JS just because they think its what they are supposed to do.
It's interesting that you chose C++ as your counter-example. It's a language that has also massively changed over the last 10 years. C++11 and later standards were a huge shift and most people would argue it's a much better language than 10 years ago.
I don't have a horse in this race though. I don't use Javascript or C++ in any meaningful capacity these days.
I don't have a horse in this race though. I don't use Javascript or C++ in any meaningful capacity these days.
If you form your understanding of programming languages from HN comments, Javascript is literally Hitler.
That's internet for you, in general its easier to criticize then to build so take it as a good sign that you are actually making something.
This looks useful - thank you for your hard work.
I do find some of the documentation/presentation à little bit confusing. I gather that when it says "fixture" - that means scaffolding to render a given component. When it says "visual tdd" - it does not mean to imply repeatable, automated red-green tests, but rather that it provides a sort of wysiwyg - or rather - wyciwys (what you code is what you see).
It's a band aid on the fact that we should be able to just draw widgets in a rich editor, but are stuck using text (code) to implement them?
(I don't mean band aid in a bad way for the project - it's just were we're at with web ux/ui. It's a bit like having postscript, but no wysiwyg dtp program to go with it).
I do find some of the documentation/presentation à little bit confusing. I gather that when it says "fixture" - that means scaffolding to render a given component. When it says "visual tdd" - it does not mean to imply repeatable, automated red-green tests, but rather that it provides a sort of wysiwyg - or rather - wyciwys (what you code is what you see).
It's a band aid on the fact that we should be able to just draw widgets in a rich editor, but are stuck using text (code) to implement them?
(I don't mean band aid in a bad way for the project - it's just were we're at with web ux/ui. It's a bit like having postscript, but no wysiwyg dtp program to go with it).
The homepage here would be much improved by explaining what the heck this project does in simple terms without making me scroll a ton and wait for fade-in animations. I'm not going to use a project that cares more about "hype" than about delivering value. Even the title tagline sounds like buzzword noise. ¯\_(ツ)_/¯
> I'm not going to use a project that cares more about "hype" than about delivering value
I can assure you I care a lot more about delivering value than hype. I spent countless hours (from my personal time) over the last 6 years on making React Cosmos easy to use and compatible with as many codebase configurations as possible, and maybe two weeks on the website.
The project README explains what the project does and what it doesn't: https://github.com/react-cosmos/react-cosmos/blob/main/READM...
There is an open thread about website feedback, and I agree I could've done a better job and there is still room for improvement: https://github.com/react-cosmos/react-cosmos/issues/1111
I can assure you I care a lot more about delivering value than hype. I spent countless hours (from my personal time) over the last 6 years on making React Cosmos easy to use and compatible with as many codebase configurations as possible, and maybe two weeks on the website.
The project README explains what the project does and what it doesn't: https://github.com/react-cosmos/react-cosmos/blob/main/READM...
There is an open thread about website feedback, and I agree I could've done a better job and there is still room for improvement: https://github.com/react-cosmos/react-cosmos/issues/1111
Hey - thanks for putting your sweat and tears into this over so many years... OSS work is vital.
Us HN folks can appear a bit grumpy at times ;)
I've got some ideas how your website could be improved... I'll have a look at the open thread.
Us HN folks can appear a bit grumpy at times ;)
I've got some ideas how your website could be improved... I'll have a look at the open thread.
Sorry for the excessive negativity. These kinds of product page for software a big pet peeve of many - light on details, heavy on marketing does not endear anyone to the grumpy HN crowd.
I think the biggest single improvement you should make is adding a paragraph above the fold that describes in as plain terms as possible what your project does, and the problems it solves. Most of your bullet points on the website describe your project as being different or better than something - but the reader has no reference for what that baseline something is.
For example, “Don’t settle for localhost:3000” - this doesn’t give me any information about what the project does, or why it’s better.
Your README is much better than the website! Here’s how I’d summarize the bullet points at the top of the README into a paragraph you can put above the fold on your site:
React Cosmos is a component development, test, and preview environment separate from your application. Iterate on individual components in isolation. Build a library of test component props & states that you can run visual regression tests against. Cosmos is flexible enough for use with different bundlers and build systems.
I think the biggest single improvement you should make is adding a paragraph above the fold that describes in as plain terms as possible what your project does, and the problems it solves. Most of your bullet points on the website describe your project as being different or better than something - but the reader has no reference for what that baseline something is.
For example, “Don’t settle for localhost:3000” - this doesn’t give me any information about what the project does, or why it’s better.
Your README is much better than the website! Here’s how I’d summarize the bullet points at the top of the README into a paragraph you can put above the fold on your site:
React Cosmos is a component development, test, and preview environment separate from your application. Iterate on individual components in isolation. Build a library of test component props & states that you can run visual regression tests against. Cosmos is flexible enough for use with different bundlers and build systems.
Conversely, cosmos is targeted at me and the lander made good sense. I understand the frustration with “inside” comments like “Don’t settle for localhost:3000”, but I appreciated it and it implied fairly heavily that this tool disrupts a very slow and tedious workflow.
I do agree that some things are buried. The docs didn’t lead me to the information I needed as quickly as I think they could have for example.
Overall I’m excited to give this a shot. It seems like a great tool.
I do agree that some things are buried. The docs didn’t lead me to the information I needed as quickly as I think they could have for example.
Overall I’m excited to give this a shot. It seems like a great tool.
I think I’m also in the target area - I work on localhost:3000 every day building Notion, which is a big React app. But why does changing the port change my workflow? What is the “default” state of the service on port :3000? How am I settling? What workflow are you referring to when you say “this tools disrupts a [...] workflow”
This is my take on it, but I realize now that it’s going to vary a lot from person to person.
The workflow is all the jank that comes with HMR, or worse, reloading entire pages to see changes.
The port number isn’t a specific thing so much as an allusion to the workflow most people use. You’re focused on a single component quite often, but working with it in an entire page served through your entire app server. It’s overkill and slower than necessary, and sometimes comes with all kinds of state frustrations outside of the scope of your component.
Changing the port doesn’t inherently change the workflow, it’s just calling out which port most of us use for that workflow and suggesting to investigate what could be better than that workflow.
They’ve made some changes to the page now, so hopefully this isn’t a source of confusion anymore.
The workflow is all the jank that comes with HMR, or worse, reloading entire pages to see changes.
The port number isn’t a specific thing so much as an allusion to the workflow most people use. You’re focused on a single component quite often, but working with it in an entire page served through your entire app server. It’s overkill and slower than necessary, and sometimes comes with all kinds of state frustrations outside of the scope of your component.
Changing the port doesn’t inherently change the workflow, it’s just calling out which port most of us use for that workflow and suggesting to investigate what could be better than that workflow.
They’ve made some changes to the page now, so hopefully this isn’t a source of confusion anymore.
Couldn't have said it better myself, thank you!
In agreement, several aspects of this website immediately made me brush off the project and whoever created it.
- GitHub star count in huge text at the top, seeking validation?
- Doesn't explain what the heck the project does, but "React Cosmos 5 in 21 tweets" ... I have to read a thread of tweets to understand what this is for?
- "Don't settle for localhost:3000" okay, demean the way that tons of us develop web based applications currently
- GitHub star count in huge text at the top, seeking validation?
- Doesn't explain what the heck the project does, but "React Cosmos 5 in 21 tweets" ... I have to read a thread of tweets to understand what this is for?
- "Don't settle for localhost:3000" okay, demean the way that tons of us develop web based applications currently
> "Don't settle for localhost:3000" okay, demean the way that tons of us develop web based applications currently
The docs tell you to open it on port 5000, which is a higher number, so it's obviously better.
Jokes aside, it did take me a long time to figure out what the product was, and I'm still not sure I fully understand. At the moment I just feel a bit overwhelmed by buzzwords, and I don't see how this would benefit my development experience.
No offense to the product creator though, I'm sure it's a great tool.
The docs tell you to open it on port 5000, which is a higher number, so it's obviously better.
Jokes aside, it did take me a long time to figure out what the product was, and I'm still not sure I fully understand. At the moment I just feel a bit overwhelmed by buzzwords, and I don't see how this would benefit my development experience.
No offense to the product creator though, I'm sure it's a great tool.
I don’t find it demeaning at all. It’s just offering something better.
i thought i was the only one ;-)
[deleted]
I'm curious why you consider animations to be nuisance.
Game UIs are completely riddled with animations that you have to "wait for" and yet I feel like UI design should aim towards that direction.
I love Cosmos! We used to use storybook a few years back but it required ongoing maintenance whenever we made changes to our build configs which meant it would slowly fall behind the rest of our application over time. The brilliance of Cosmos is that it relies on your existing configs to build the components, so it's just a "set it and forget it" setup. Being able to produce static builds is also great and we rely on this to generate component previews in our CI so that QA can review component appearance and behavior before we even merge them into development. The Cosmos UI hooks are also a clever use of hooks that allow the fixtures to be tested by non-technical people in a manner that aligns with the logical boundaries of the component's design from an engineering perspective. The approach to designating a fixture file using the .fixture extension is also low effort meaning engineers actually do it. It's awesome, I highly recommend it if you work on a complex react front-end with many individual components.
I struggled to work out what this was until I found a link to these explainer tweets: https://twitter.com/ReactCosmos/status/1189127279533793281
Even that wasn't high level enough but their twitter headline is: "A tool for ambitious UI developers"
So piecing it all together I'd guess that it's an online IDE that combines some clever stuff with components :shrug:
Even that wasn't high level enough but their twitter headline is: "A tool for ambitious UI developers"
So piecing it all together I'd guess that it's an online IDE that combines some clever stuff with components :shrug:
It’s a component sandboxing tool which allows you to test your components and pages in isolation. Storybook is similar. You’d pick one or the other based on preference, mostly.
Updated the project description roughly to this. You're part of the Cosmos story now – Cheers! :)
They should put your first sentence as the main text on the page!
Great explanation thanks
Great explanation thanks
I read the Getting Started and it seems like this creates a webpage that you can use to speed up iteration on your components? Should there be a screenshot of that on your landing page? The live demo doesn't really work on mobile. What else does this do? What problem does it solve? How does it solve that? Saying it solves "Reusable components" is pretty generic, could use some expansion on how it actually helps in this regard.
Your landing page is beautiful, but it does a poor job explaining itself.
Your landing page is beautiful, but it does a poor job explaining itself.
> it seems like this creates a webpage that you can use to speed up iteration on your components?
Pretty accurate. Cosmos is an isolated component environment. You can load components separately for regular development, as well as for automated visual regression testing.
> What else does this do? What problem does it solve? How does it solve that? Saying it solves "Reusable components" is pretty generic, could use some expansion on how it actually helps in this regard.
I get that it's confusing, but the landing page literally addresses this:
- "Develop one component at a time. Isolate the UI you're working on and iterate quickly. Reloading your whole app on every change is slowing you down!"
- "Bookmark component states, from blank states to edge cases. Your component library keeps you organized and provides a solid foundation of test cases."
Scroll down and it goes into more detail in 6 concise paragraphs.
> The live demo doesn't really work on mobile
That's true. But you can't really develop React apps on mobile either. React Cosmos is desktop dev tool that you run locally as part of your codebase.
Right next to the demo, however, there's a link to a 21-tweet thread with specific functionality, code examples and visuals included: https://twitter.com/ReactCosmos/status/1189127279533793281
Pretty accurate. Cosmos is an isolated component environment. You can load components separately for regular development, as well as for automated visual regression testing.
> What else does this do? What problem does it solve? How does it solve that? Saying it solves "Reusable components" is pretty generic, could use some expansion on how it actually helps in this regard.
I get that it's confusing, but the landing page literally addresses this:
- "Develop one component at a time. Isolate the UI you're working on and iterate quickly. Reloading your whole app on every change is slowing you down!"
- "Bookmark component states, from blank states to edge cases. Your component library keeps you organized and provides a solid foundation of test cases."
Scroll down and it goes into more detail in 6 concise paragraphs.
> The live demo doesn't really work on mobile
That's true. But you can't really develop React apps on mobile either. React Cosmos is desktop dev tool that you run locally as part of your codebase.
Right next to the demo, however, there's a link to a 21-tweet thread with specific functionality, code examples and visuals included: https://twitter.com/ReactCosmos/status/1189127279533793281
> Right next to the demo, however, there's a link to a 21-tweet thread with specific functionality, code examples and visuals included: https://twitter.com/ReactCosmos/status/1189127279533793281
I will 100% be trying out cosmos the next time I need to develop a React component, but Twitter is an awful way of sharing large amounts of info and if I have to leave your website to go to twitter to find out what your product is and how to use it, something isn't right.
Either way, I understand it's OSS and your time is valuable, so thanks for this!
I will 100% be trying out cosmos the next time I need to develop a React component, but Twitter is an awful way of sharing large amounts of info and if I have to leave your website to go to twitter to find out what your product is and how to use it, something isn't right.
Either way, I understand it's OSS and your time is valuable, so thanks for this!
This looks great! I think a similar framework Storybook should also be noted.
I definitely see a future where the IDE has much more awareness of your development environment, this is a step in that direction at least for React.
Game developers get a lot of these benefits from their IDE typically having more tools than webdevs with a text editor. Hoping to see more of this in the future!
I definitely see a future where the IDE has much more awareness of your development environment, this is a step in that direction at least for React.
Game developers get a lot of these benefits from their IDE typically having more tools than webdevs with a text editor. Hoping to see more of this in the future!
I was thinking the same re: Storybook. Though I was trying to figure out what benefit Cosmos may have over storybook?
I'm using Storybook with React-Native, and it does feel like I'm developing web components, and then trying to use them in an app later, but that's my only real complaint with Storybook.
I'm using Storybook with React-Native, and it does feel like I'm developing web components, and then trying to use them in an app later, but that's my only real complaint with Storybook.
Ive strung up spas within storybook so I have the component and the page its going into. Essentially you import the <App> and provide a store. It helps single responsibility principalize your code, and you are always focused on having well define components for your storybook library/dictionary.
Do you have any examples you can share where you've customized Storybook in this manner?
If I understand correctly, as opposed to loading your components in isolation in Storybook, you're providing them with a context similar to the actual app they're going to exist in?
If I understand correctly, as opposed to loading your components in isolation in Storybook, you're providing them with a context similar to the actual app they're going to exist in?
Not OP, but i suppose you can use custom decorator to wrap components and globalTypes for some customization, like theme selector
https://storybook.js.org/docs/react/essentials/toolbars-and-...
https://storybook.js.org/docs/react/essentials/toolbars-and-...
This sounds like a good use case for Playroom too
https://github.com/seek-oss/playroom
https://github.com/seek-oss/playroom
How does this compare to storybook? I've used storybook for ages and it's a great tool but is there a good reason to consider cosmos over it?
I find it more reliable for React Native projects. We moved from Storybook to Cosmos and it's been a lot smoother. But, to be fair, this was awhile ago so Storybook might be more stable in React Native by now.
Could you clarify what you mean by "more reliable"? What problems were you having with Storybook?
> You're doing important work. Keep rocking.
> Dan Abramov
Is this just a general quote from Dan, or is it about this product specifically?
> Dan Abramov
Is this just a general quote from Dan, or is it about this product specifically?
It's about React Cosmos specifically.
https://twitter.com/dan_abramov/status/600354123372965888
https://twitter.com/dan_abramov/status/600354123372965888
We recently moved from Storybook to Cosmos for our React Native app and love it a lot more!
Perhaps also similar to ClojureScript "devcards": https://github.com/bhauman/devcards
We replaced storybook with cosmos and it works much better for us. It's light and focused, I enjoy using it much more. Thank you for your work!
We've recently torn Storybook out of our app (in short, excessive bloat) and will definitely be giving this a try!
Neat idea, but the website is very overwhelming with all the weird transitions and fades. Just show the content.
Some interesting ideas, resonates with frustrations with poor dev workflows I have suffered from at times
This tool looks really cool but I still don't know what "UI at scale" means.
Yes, Cosmos is very similar to Storybook. It's also older, and I'm only saying this because I'm tired of getting asked how does it differ. Both projects provide an isolated component environment to help tackle complexity in single page apps. The difference boils down to setup compatibility and personal taste.
I'm not gonna lie, some of the comments are tough to process, but what can you do. I still appreciate all feedback and as usual I'll try to incorporate it as best as I can.