Yeah, I was expecting something having to do with book writing, or user stories. Honestly, I don't understand when/why UI became a 'story'. I get storybook because storybooks have pictures, so it's more about the picture than the words on the page.
However, the tool does look nice, if the 'hook' for the site isn't that explanatory. I might like to try it on svelte, I wonder how hard it'd be to integrate with laravel+livewire+alpine stack, because there's nothing like this for that. Probably a big value too.
I also thought it was going to be for publishing writings online. They're reusing the lingo from storybook, which is going to be familiar to a lot of people in the frontend space these days.
It does look like a great tool, I would definitely give it a try first before going to storybook.
> With the release of Vue 3, a Storybook alternative named Histoire has gained some traction. In this blog post, we’ll explore how to create interactive documentation of UI components for Vue 3 projects. As with Storybook, Histoire is designed for making your life much easier to create living style-guides and component showcases.
>”Histoire is a tool to generate stories applications (or "books").”
What a clever naming scheme! Nobody reads stories or books anymore, so when they see the word “story” they’ll automatically assume you mean UX Story! This isn’t ridiculously confusing at all.
this is unfairly negative, Storybook started calling it stories and before them, PMs and UX researchers, to the point that it was an industry understood term long before Histoire came along. the overloading is unfortunate but happens all the time - we don't complain about "bug" or "fork".
"Bug" and "fork" are industry standard terms, "stories" are not. Plenty of frontend developers exist who don't know the term.
Overloading is fine. Ambiguous use of an overloaded term is not. What is one to think of when they see words like "write", "stories", and God forbid, "book"?
Just because you got confused by a headline doesn’t mean the copy on the website itself isn’t relevant to their target audience. I’m a front end dev and understood it immediately (you can infer the meaning/context from “powered by Vite”).
At most you can critique the HN headline drawing in randoms, which is a legitimate complaint, but I don’t see a problem with their copy especially for a brand new OSS project. Marketing sites are usually an after thought that improve after the first year.
Unless, you know, you think this new volunteer project should be selling you on using well documented component libraries or something.
I'm a frontend dev who is familiar with Storybook and I didn't realize this wasn't about publishing an actual book, even after clicking around to a couple pages, until I came back here. So yea it's pretty valid feedback.
I actually have to agree with the parent. They were right to take me to task. After all, Vite and Storybook are ubiquitous tools of the trade in front-end development, which is a domain of programming famous for its rock solid stable tooling and methodologies.
Sarcasm aside, I actually do like Vite quite a bit. And I still think my main point stands that a framework that exists to document components co-opting the word “book” is ridiculous.
Put an example in the home page. I went to GitHub and I found some ts code in the examples directories but I could not find any story, if these stories are what books are made of. If they are something else I might have seen one without realizing it.
Because if it's not powered by the same build tool as your project, you'll have fun duplicating your entire build config and finding compatible plugins for both platforms.
So I submitted without realizing that the landing page doesn't provide very much context, especially if you're not exposed to frontend stuff. Keep in mind that Histoire hasn't seen a 1.0 release yet.
In short: The "stories" here are frontend components that are being rendered in isolation, with the ability to play with their params. It's also a nice way to document custom components in a project (this would be the "book" I guess). Storybook¹ is the mature project in this area.
As for Vite it's an alternative to Webpack which has gained rapid popularity - I've enjoyed using for its relatively light configuration and very fast live reloading support.
Even as a frontend developer (mostly Vue, some React) it didn't make much sense to me. I've never heard of Storybook. I've never wanted to share UI components that I have made with the world.
I do like Vite a lot, but I don't really see the relevance of the "powered by Vite" unless the whole thing is basically a sales pitch for Vite.
For me it's more about documenting your components for my team/myself. I guess you can think of it as a framework for creating doc pages with interactive demos of components, as shown in this demo: https://vue3.examples.histoire.dev/story/src-components-base...
Setting aside the “why stories?” part (plenty of people use UX stories — I do, though I am ambivalent about them), the powered by Vite line does have some content to it:
1. If you’re already using Vite, you know it will integrate easily
2. If you’re not using Vite, if you know what Vite is, you at least know it’s fast and easy to configure
3. The fact that it’s made by a Vue core dev means it’s likely very good. There are a number of such “powered by Vite” tools with good reputations
It has to build the same stuff as the product because the examples are interactive. So being able to use your existing build config without doing anything special is great.
You should consider Storybook. It has really changed my team's thought around frontend components -- they think in much more of an atomic design mentality now, build little stories out of their atoms, and then assemble those onto our existing pages. The APIs they're building are cleaner and less ad-hoc, which contributes to building more reusable, understandable and refactorable code.
I'm mainly saying this because I had a similar mentality to you -- I didn't see the point -- but I now use it even on personal projects. It's nice to be able to easily see my various widgets isolated, on their own and tweakable without needing to navigate five layers deep into my application to alter them.
Yeah, agreed. I find when some tech embraces a metaphor too enthusiastically it can just become exhausting. SaltStack was like that, full of its "pillars" (pillars of salt? get it? some biblical reference) and "grains" etc etc. Or Homebrew with its "taps" and "kegs".
I'm fine with just the standard most appropriate generic word, whether it be module, component, database, etc.
It comes from a desire to turn something simple - a dedicated place in your project to try and document your reusable components - into a product. Then, much like Twitter has tweets, Codepen has pens, Reddit has subreddits etc, so Storybook has stories.
It should probably never have been so productized, because it is way more complex than it needs to be. Again, it’s a very simple idea, and in my experience, many teams use only the most basic setup, and have never really considered why they took on a VC-funded dependency just to render some components.
That's a shame. You can find documentation at https://bradfrost.com/blog/post/atomic-web-design/ on the methodology -- it's pretty lightweight, and is really just a vocabulary for discussing different groups of UI elements. When you have to build a consistent style for your application, this kind of tool is really useful -- it helps you build more reusable components and keep them documented somewhere.
I'm not at all knowledgeable about Vue and its libraries, community, etc., so with a grain of salt, why does it seem that Vue makes Vue versions of various libraries, like Vite (Webpack), Vitest (Jest), and now Histoire (Storybook, also an annoying thing to type)? This is not to say that there shouldn't be new tools that compete with existing ones, since generally the more tools the better the ecosystem as a whole is, but it's confusing to me that Vue somehow has this NIH syndrome and new tools crop up specifically for it.
Part of the answer is surely that the tools you’re talking about are dramatic improvements on the originals, speaking as a longtime Webpack and Jest user who now uses Vite and Vitest. Neither is Vue-specific, by the way — I use them with React. (It looks like Histoire doesn’t have a React adapter yet, but I’m sure it will soon.)
It seems to me — as someone who uses these tools but has no inside knowledge of the Vue community — that this community just has a really well-developed engineering culture and is producing tools in line with that culture that are all really good and integrate well together. It’s hard to understand why you wouldn’t want that if you could get it!
I've used Histoire a good bit ago (just after it was first released), and my experience has been great! It's what I wanted Storybook to be, especially regarding performance. Kudos to the devs for finally creating an alternative that can stand on its own!
50 comments
[ 4.5 ms ] story [ 106 ms ] threadI always check for committed and professional open source devs before I consider a project. The devs behind this one are experienced Vue folks.
Looking forward to giving it a try.
Seeking input from experts: how long until that day? Or is this that tool…?
However, the tool does look nice, if the 'hook' for the site isn't that explanatory. I might like to try it on svelte, I wonder how hard it'd be to integrate with laravel+livewire+alpine stack, because there's nothing like this for that. Probably a big value too.
It does look like a great tool, I would definitely give it a try first before going to storybook.
> With the release of Vue 3, a Storybook alternative named Histoire has gained some traction. In this blog post, we’ll explore how to create interactive documentation of UI components for Vue 3 projects. As with Storybook, Histoire is designed for making your life much easier to create living style-guides and component showcases.
> Write stories to showcase and document your components.
Until having used it, I was having similar questions about the domain of Storybook.
But this sentence (first paragraph below the header and menu) sums it up clearly for every frontend developer IMO.
Also this is linked and goes into more detail about what a "story" is:
https://histoire.dev/guide/
Then I thought it was a tool for writing books.
Then finally I discovered that it's a Storybook alternative. I think.
What a clever naming scheme! Nobody reads stories or books anymore, so when they see the word “story” they’ll automatically assume you mean UX Story! This isn’t ridiculously confusing at all.
And to be clear when I say write I mean like a novel or blog post. Like with the English language.
Overloading is fine. Ambiguous use of an overloaded term is not. What is one to think of when they see words like "write", "stories", and God forbid, "book"?
Storybook stories, of course.
Even the use of french. Why French? Because it's really so exotic?
At most you can critique the HN headline drawing in randoms, which is a legitimate complaint, but I don’t see a problem with their copy especially for a brand new OSS project. Marketing sites are usually an after thought that improve after the first year.
Unless, you know, you think this new volunteer project should be selling you on using well documented component libraries or something.
Sarcasm aside, I actually do like Vite quite a bit. And I still think my main point stands that a framework that exists to document components co-opting the word “book” is ridiculous.
- the project is Vite forward
- looks like React and Solid (and Angular) are in the roadmap
In short: The "stories" here are frontend components that are being rendered in isolation, with the ability to play with their params. It's also a nice way to document custom components in a project (this would be the "book" I guess). Storybook¹ is the mature project in this area.
As for Vite it's an alternative to Webpack which has gained rapid popularity - I've enjoyed using for its relatively light configuration and very fast live reloading support.
⸺
¹https://storybook.js.org/ (much better landing page)
I do like Vite a lot, but I don't really see the relevance of the "powered by Vite" unless the whole thing is basically a sales pitch for Vite.
1. If you’re already using Vite, you know it will integrate easily
2. If you’re not using Vite, if you know what Vite is, you at least know it’s fast and easy to configure
3. The fact that it’s made by a Vue core dev means it’s likely very good. There are a number of such “powered by Vite” tools with good reputations
I'm mainly saying this because I had a similar mentality to you -- I didn't see the point -- but I now use it even on personal projects. It's nice to be able to easily see my various widgets isolated, on their own and tweakable without needing to navigate five layers deep into my application to alter them.
I'm fine with just the standard most appropriate generic word, whether it be module, component, database, etc.
It should probably never have been so productized, because it is way more complex than it needs to be. Again, it’s a very simple idea, and in my experience, many teams use only the most basic setup, and have never really considered why they took on a VC-funded dependency just to render some components.
Is this considered a story? https://vue3.examples.histoire.dev/story/tailwind?variantId=...
It seems to me — as someone who uses these tools but has no inside knowledge of the Vue community — that this community just has a really well-developed engineering culture and is producing tools in line with that culture that are all really good and integrate well together. It’s hard to understand why you wouldn’t want that if you could get it!