What is Storybook and what are its top alternatives?
Top Alternatives to Storybook
You just load your UI components into the React Storybook and start developing them. This functionality allows you to develop UI components rapidly without worrying about the app. It will improve your team’s collaboration and feedback loop. ...
It is open source tool that helps you easily publish and manage reusable components. It help teams scale shared components to hundreds and even thousands of components, while eliminating the overhead around this process. ...
It helps you and your team build thoughtful, pattern-driven user interfaces using atomic design principles. ...
Figma is the first interface design tool with real-time collaboration. It keeps everyone on the same page. Focus on the work instead of fighting your tools. ...
MUI (formerly Material-UI) is the React UI library you always wanted. Follow your own design system, or start with Material Design. ...
Cypress is a front end automated testing application created for the modern web. Cypress is built on a new architecture and runs in the same run-loop as the application being tested. As a result Cypress provides better, faster, and more reliable testing for anything that runs in a browser. Cypress works on any front-end framework or website. ...
React Router is a complete routing solution designed specifically for React.js. It painlessly synchronizes the components of your application with the URL, with first-class support for nesting, transitions, and server side rendering. ...
Storybook alternatives & related posts
related React Sketch.app posts
- Hard dependency to Babel loader2
related React Storybook posts
related Bit posts
related Pattern Lab posts
- Web-based application12
- Intuitive interface and perfect collaboration8
- Works on both Mac and Windows7
- Free software6
- Works on multiple OS's5
- Great plugins, easy to extend4
- Large community, tutorials, documentation4
- Imports Sketch files4
- Hands done the best design tool for collaboration!4
- Interactive, event-based prototypes4
- Highly Collaborative4
- Prototyping, design files and comments all in one place2
- No more syncing between Sketch and InVision2
- Limited Export options5
related Figma posts
The tool we use for editing UI is React Storybook. It is the perfect place to make sure your work aligns with designs to the pixel across breakpoints. You get fast hot module reloading and a couple checkboxes to enable/disable browser features like Flexbox.
The only tricks I apply to Storybook are loading the stories with the mock data we’ve extracted from the API. If your mock data really covers all the various various possible states for your UI, you are good to go. Beyond that, if you have alternative states you want to account for, perhaps loading or error states, you can add them in manually.
This is the crux of the matter for Storybook. This file is entirely generated from Yeoman (discussed below), and it delivers the examples from the Alps Journey by default. getSectionsFromJourney() just filters the sections.
One other hack you’ll notice is that I added a pair of divs to bookend my component vertically, since Storybook renders with whitespace around the component. That is fine for buttons or UI with borders, but it’s hard to tell precisely where your component starts and ends, so I hacked them in there.
Since we are talking about how all these fabulous tools work so well together to help you be productive, can I just say what a delight it is to work on UI with Zeplin or Figma side by side with Storybook. Digging into UI in this abstract way takes all the chaos of this madcap world away one breakpoint at a time, and in that quiet realm, you are good down to the pixel every time.
To supply Storybook and our unit tests with realistic mock data, we want to extract the mock data directly from our Shared Development Environment. As with codegen, even a small change in a query fragment should also trigger many small changes in mock data. And here, similarly, the hard part is tackled entirely by Apollo CLI, and you can stitch it together with your own code in no time.
Coming back to Zeplin and Figma briefly, they're both built to allow engineers to extract content directly to facilitate product development.
Extracting the copy for an entire paragraph is as simple as selecting the content in Zeplin and clicking the “copy” icon in the Content section of the sidebar. In the case of Zeplin, images can be extracted by selecting and clicking the “download” icon in the Assets section of the sidebar.ReactDesignStack #StorybookStack #StorybookDesignStack
We chose Figma because of the collaboration aspect of it. We are able to work as a team to create designs for web apps, mobile apps, and alike. After creating our designs in Figma we start exporting the assets and designs over to Webflow and Supernova.
- Material Design76
- Ui components48
- CSS framework25
- Looks great12
- Good documentation10
- Open source7
- Code examples6
- Ui component5
- Supports old browsers out of the box3
- Very accessible3
- Designed for Server Side Rendering2
- Easy to work with1
- Barev Arman1
- Hard to learn. Bad documentation27
- Hard to customize22
- Hard to understand Docs18
- Bad performance6
- Extra library needed for date/time pickers5
- For editable table component need to use material-table5
- Long Code5
related Material-UI posts
I picked up an idea to develop and it was no brainer I had to go with React for the frontend. I was faced with challenges when it came to what component framework to use. I had worked extensively with Material-UI but I needed something different that would offer me wider range of well customized components (I became pretty slow at styling). I brought in Evergreen after several sampling and reads online but again, after several prototype development against Evergreen—since I was using TypeScript and I had to import custom Type, it felt exhaustive. After I validated Evergreen with the designs of the idea I was developing, I also noticed I might have to do a lot of styling. I later stumbled on Material Kit, the one specifically made for React . It was promising with beautifully crafted components, most of which fits into the designs pages I had on ground.
A major problem of Material Kit for me is it isn't written in TypeScript and there isn't any plans to support its TypeScript version. I rolled up my sleeve and started converting their components to TypeScript and if you'll ask me, I am still on it.
In summary, I used the Create React App with TypeScript support and I am spending some time converting Material Kit to TypeScript before I start developing against it. All of these components are going to be hosted on Bit.
If you feel I am crazy or I have gotten something wrong, I'll be willing to listen to your opinion. Also, if you want to have a share of whatever TypeScript version of Material Kit I end up coming up with, let me know.
My React website is a simple 5-pager that attaches to a database to store and display registrations and other data. The user (small user base) can change any form elements, but I don't need theme-ing, though that would be fun for the user. reactstrap/react-bootstrap built on Bootstrap 4 sounds dated. I am familiar with reactstrap, but a friend said to try Material-UI. The thought of learning it is interesting, but somehow I think it might be overkill. So... reactstrap, react-bootstrap, or Material UI, which should I use?
- Open source25
- Great documentation18
- Simple usage16
- Cross Browser testing10
- Easy us with CI9
- Npm install cypress only4
- Good for beginner automation engineers1
- Cypress is weak at cross-browser testing19
- Switch tabs : Cypress can'nt support12
- No iFrame support11
- No file upload support8
- No xPath support8
- No multiple domain support8
- No page object support8
- Re-run failed tests retries not supported yet7
- Cypress doesn't support native app7
- No support for multiple tab control7
- No support for multiple browser control6
- No support for Safari6
- $20/user/thread for reports4
- Not freeware4
- No 'WD wire protocol' support3
- Using a non-standard automation protocol3
related Cypress posts
We are in the process of adopting Next.js as our React framework and using Storybook to help build our React components in isolation. This new part of our frontend is written in TypeScript, and we use Emotion for CSS/styling. For delivering data, we use GraphQL and Apollo. Jest, Percy, and Cypress are used for testing.
- Because there's not alternative12
related React Router posts
ReactQL is written in TypeScript to provide full types/Intellisense, and pick up hard-to-diagnose goofs that might later show up at runtime. React makes heavy use of Webpack 4 to handle transforming your code to an optimised client-side bundle, and in throws back just enough code needed for the initial render, while seamlessly handling
import statements asynchronously as needed, making the payload your user downloads ultimately much smaller than trying to do it by hand.
React Helmet was chosen to handle
<head> content, because it works universally, making it easy to throw back the correct
<title> and other tags on the initial render, as well as inject new tags for subsequent client-side views.
<style> tags when using #StyledComponents.
React Router handles routing, because it works both on the server and in the client. ReactQL customises it further by capturing non-200 responses on the server, redirecting or throwing back custom 404 pages as needed.
Koa is the web server that handles all incoming HTTP requests, because it's fast (TTFB < 5ms, even after fully rendering React), and its natively #async, making it easy to async/await inside routes and middleware.
I'm creating a website with React in my free time, and this is my first time doing this. So far, I've worked with React and React Router, but migrating to Next.js or Gatsby would cover Routing and SEO, which I currently cannot work with. Most things I read say that Next.js is the best solution, but I am trying to decide whether it is worth the time and effort to recreate the site for SEO and speed purposes. Does anyone have suggestions?