Wow, author of Cosmos here. For the record I didn't post this. So thanks to OP and everyone who upvoted. It's cool that Cosmos still generates new interest after so many years.
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.
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.
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.
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.
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 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).
> 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.
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'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.
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.
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 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.
I generally avoid defaults exports as well but didn't realize some codebases disable them completely.
What do you mean by "non-default-exporting" TSX files, can you provide a link?
> Perhaps adding shim files that import the component and re-export as default?
Definitely, you could add a transform to the Cosmos build pipeline that renames some named export to default. If you're willing to write the transform I'll gladly help you integrate it.
In general each export is named with what it is, so SearchWidget.tsx, which contains a search widget, would explicitly "export { SearchWidget }".
Both tslint and eslint support no-default-export rules, so its clearly at least a semi common approach.
I can't speak to why others use the pattern but I can say enabling no-default-export gets rid of the "do I import * as foo from, import foo from, or import { foo } from" conundrum and enables the linter or transpiler to detect when there is code that accidentally tries to import Football from "baseball" because import { Football } from "baseball" (when baseball.tsx doesn't export Football) generates a clearer and more targeted error message than some noise message about invalid props or wrong number of children under <Football> because it picked up some bogus default export from baseball.tsx. (Definitely not trying to start a language war here, engineering is always about trade offs, and different people and projects make them differently without invalidating each other's choices.)
I'm guessing there is a way to make a generic transformer but it's not a type of TypeScript language fu I've messed with.
Totally agree, like I said I also avoid defaults exports (for the same reasons). But I'm fine with default exports in fixtures because you never import them by hand, they are picked up automatically by React Cosmos. And you can customize no-default-export rules to ignore fixture files.
The first version did! But I removed it because I didn't want Blizzard to take me down for copyright infringement, haha. And to be honest it was getting annnoying while I was working on the app cause I heard it dozens of times a day.
But Heartstone? Ha! Go back in time another 12 years.
I used to play Warcraft III in highschool and that sound stuck with me for sure.
No shame in admitting this. I still struggle with it. Computers are very effective at messing up our sleep function.
Happy to hear you're giving Jobs Done a try. Note that you can customize the steps, set phrase and suggested activities by cloning the repo, editing data.js, building and publishing the static build with a service like https://zeit.co/now or https://surge.sh (free).
