Hacker News Reader

Comment by radus | Hacker News Reader

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.

⸺

¹https://storybook.js.org/ (much better landing page)

View on HN

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

I'm surprised the integrating part matters. Does it matter if your internal documentation uses the same stack as your product?

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.

This nomenclature is so cringey to me. Building "stories" out of "atoms". It's like a mishmash of random childlike words appropriated together.

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.

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.

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.

Reply on news.ycombinator.com