Side question: It looks interesting but what's with the trend of open source projects providing such bloated installs? The recommended getting started with docker (which first recommends cloning a 350mb repo) seems to assume you need to scale to 100s+ users. At a glance, in their default docker compose I counted no less than 12 containers including nginx, redis and minio. I can't imagine any of these are necessary to run an app on a single localhost machine.
I understand they're trying to attract enterprisy customers, but even some of those are probably going to want to try it out first. Would be nice to have an easy minimal install option that doesn't require a deep dive into the project to figure out.
We should definitely update the Local guide to reflect the ^, thanks for pointing that out.
For the container footprint - pretty much all of them are necessary to run locally. We hope that just a large # of containers shouldn't be a problem, as long as they are all lightweight (e.g. total resource utilization is low). We of course could bundle them together into a single "mega container", but that seems against the best practices of Docker.
On a related note, we are looking to have a version that doesn't require the vector database (the heaviest part of the system in terms of resource utilization). Our goal is to have a deployment mode with less than 1gb of RAM required.
Hey, the bottom line is the project looks promising and I'm sure it's a lot of hard work. That said, because time is limited, for now I'll have to pass on spinning it up for the reasons mentioned. I took a look at the shell script, and it just seems like a helpful wrapper (with cleanup) over a manual install. I didn't mean to say it's about the amount of containers. All of those services take up a lot of resources, especially compared to the alternatives.
For example, Openwebui can be run with just a sqlite database and a backend. Why is nginx needed, or Minio on a single machine with a nice local file system? But I also understand it takes more work to support multiple service configurations so please accept the criticism as constructive (and it's more a general observation of what I've noticed over the past few years).
I'm a seasoned Front End Engineer (Full Stack Typescript/Javascript) with 20 years of professional experience in a variety of industries. My specialty is front end and React although I'm also skilled in back end web technologies. Currently I'm seeking a long-term 3/4 time position.
The evidence is tell me how many tech companies, especially startups, have a large ratio of over 40s? If age discrimination were better enforced, the OP might have a very different (and more fair) market to try your experiment. Until that happens, the OPs observation that they are under compensated vs. other workers of a similar skill set would be where I'd put my money.
Just finishing up a Storybook based on the v8 beta and was pleasantly surprised how far it's come along since I last tried it a few years ago. The auto docs (with the help of react-docgen) while still a bit rough on the edges and buggy in the new release is amazing. I wish the documentation was a bit better in some areas (the examples are usually repeated simple use cases from their demo content like a button) but I was able to achieve most of what I needed and then some.
For those wondering what the use case is, you must not have tried it. It does take work to set up (with each version that's less), but it can be very nice to test in isolation esp in cases where a component is under a login, the 4th page of a 10 page form, etc. Also obviously if you're working on a component library that ships without an app, Storybook can be your development and/or demo app.
> For those wondering what the use case is, you must not have tried it. It does take work to set up (with each version that's less), but it can be very nice to test in isolation esp in cases where a component is under a login, the 4th page of a 10 page form, etc. Also obviously if you're working on a component library that ships without an app, Storybook can be your development and/or demo app.
I have worked with storybook extensively over the past couple of years and my team is moving away from it in favour of MSW (https://mswjs.io).
For "4th page of a 10 page form" during the development there's hot reloading which is really stable nowadays and haven't failed me, although I understand that some setups are old and it might be easier to configure Storybook than good hot reloading.
I'm not entirely sure about the testing part of it and I'd be grateful if you could elaborate. I haven't felt the need for some special setup with SB because for unit tests, I can test a deeply nested component separately with react-testing-library. For E2E tests, I usually test the whole form anyway.
I agree on the component library part, this is probably the only use case where Storybook is 100% justified, but I'm unconvinced about the usual SPA use case
Haven't used MSW, but don't people use it for mocking APIs? Isn't that apples and oranges? If your stories need data, you can always still use MSW. But otherwise when it comes to testing (in the app vs. Stories) I'd agree. Not exactly testing, but the play feature beats E2E if you want to show a smooth demo for clients/fellow devs.
As far as live reload, you're right but only once you've achieved the state. If you're firing up storybook or moving between components, you can already have any state ready to go (or quickly set with the controls). If you're in the actual app and don't have something like Redux Dev Tools, you have to manually go through the steps.... which can be a pain.
That said, so far I'm only using Storybook for the "component library" use case. And for that it's a big improvement from the previous DIY app I had.
> Haven't used MSW, but don't people use it for mocking APIs? Isn't that apples and oranges?
At first, I was confused by what OP meant, too, but I think the point is that if you can mock your data easily, then getting your app into the desired state is straightforward enough that Storybook becomes unnecessary. At least, that's how I interpreted it.
Thanks. Need to try MSW, but right now it's not clear to me how it can be used more than a fake HTTP endpoint. With Storybook, I can create links with any set of props I want for each component (or change with the controls). A lot of state doesn't rely on a back end (client side history or user prefs stored in local state, etc.).
The Storybook use case and the MSW use case is fairly similar to me: develop your SPA in separation from the backend and this is how Storybook was pitched to me and is usually pitched. Both allow me to hook up the backend after a component has been developed.
> the play feature beats E2E if you want to show a smooth demo for clients/fellow devs
We actually haven't used this at all, but it's a neat feature.
The tradeoffs we evaluated were:
- Storybook allows to develop components in isolation, but requires to structure your components in a very specific way that is detrimental to how React works (see my other comment with the Oxide in the thread).
- MSW allows to develop your whole app in isolation but it lacks all of the bells and whistles that Storybook has (e.g. testing, various plugins, demo, discoverability of the components).
But in general, our use case is developing an internal SPA using Tailwind, so we don't exactly have a component library that we need to develop in isolation. I can see the value of Storybook if that's the case for your team. Many other companies maintain their homegrown UI library that could benefit from all of the features of Storybook, so it makes sense for them.
Thanks for the explanation, but I still don't understand how MSW and Storybook are comparable. As you said, MSW can be used to isolate a "backend". But Storybook really mainly to isolate the "frontend" parts. I see the point of both. On that note, while pretty happy with my current mocking solutions I've been meaning to take a closer look at MSW!
How does SB require a certain component structure? I didn't have to touch mine. They have a "sub component" feature for documenting nested components that work together, although I didn't even use it. Just used either decorators or render functions in my stories where needed (which did require a little wiring up to update the args).
I don't use Tailwind (yuck, sorry!), but how is choice of styling a factor?
The auto docs have some weird glitches and did force me to adjust my TS types a bit is my complaint (and react-docgen-typescript wasn't working for me at all).
I agree that SB is probably not worth the effort for everyone though.
> which did require a little wiring up to update the args
> The auto docs have some weird glitches and did force me to adjust my TS types a bit is my complaint
This, to me, is the biggest downside of Storybook. Storybook might provide reasonable defaults but if you want to configure how exactly things are supposed to look & behave, and want type support, you are in for a world of pain, arcane magic, and glitches. My team recently convinced me to give Storybook another shot in our current project and I regret it already and now remember again why I always disliked it. We are indeed developing a component library and in hindsight I would have preferred to write a simple Vue app showcasing our components, and adding any component controls myself.
This is such an interesting attitude. I hope I don't inherit any of your projects. I have the opposite take... that the world needs him more than ever. Tailwind is the pump and dump of web development. I can definitely see the allure when it comes to hammering up the fastest possible prototypes with minimal knowledge required, but in reality it's 1 step forward and 10 steps back.
It's legacy is going to be more of bummer than a lot of folks realize I'm afraid. What are you going to do when the Product Manager comes in with the new design comps after you've hard coded all that html with the disparate output of ChatGPT and/or various pasted in snippets from libraries like Shadcn?
Just wondering, do you think it would have helped your situation if it were the cultural norm to "try before you buy" for both parties? Obviously it takes time to get up to speed and productivity, but it seems better and more productive for you not to have an unhappy employee in the long-term.
I get that any kind of turnover is tough to manage especially if you're a small team. But if we all (employers, employees, customers/clients/users) were to became a little more prepared for a certain amount (within a short period of time after hiring), it would simply become the expectation. As it stands, companies are now afraid to hire and employees are afraid to seek due to the ever more byzantine hiring process.
It may not exactly seem intuitive, but I believe if either firing or quitting (at least within some type of trial period) became a little less stigmatized on both sides, we would all live in less fear and end up much more productive in the longer term.
Exactly and IMO we would all be better served if F/T employees were treated more as "temp to hire". Contractors would still be contractors in terms of taxes, benefits, expectation of where/how services are rendered, etc.
If you're so against hearing any kind of rationalization or nuance about the drawbacks of unchecked population growth, please buy a ticket from Elon and turn some other planet into your Coruscant. Because some of us like this one, and we humans are destroying it with that kind of selfish thinking.
It's as if some people can't see that there might be middle ground between say an evil Eugenics master plan and a little bit better family planning for a few generations.
Absolutely. And what gets lost so often is that the population is still set to approach 10 billion over the next century and either flatten or gradually decrease back to levels still above where we are now by 2200. There is currently no projection that I’m aware of that has the population of the earth actually declining from current levels in the next 200 years. And that is without even taking into account any improvements in the health of older people leading to longer, healthier lives.
Lol. Judging from the last rocket I think there could be some nose bleeds for cheap. I humbly ask though instead of mars, go colonize somewhere in a galaxy far far away. Otherwise, you'd be much too close for comfort for us Earthlings.
As a designer-turned-developer, I find this topic and the comments amusing. I don't think there's much question that the agency in question treated the client terribly, and should have been fired post haste and early.
That said, you couldn't pay me enough to get involved with design again in any way shape or form. The reason, as reflected by the comments and experience, is greatly increased customer expectations of the design process, number of expected mockups/choices, iterations, content changes, scope creep, etc. Even for small projects like the OPs, it's has ballooned to such an extent that many times it's practically impossible to know if something is going to take weeks or even years.
10 years ago when I last did design, if this author approached me I'm confident that I could have delivered a significantly better end result in far less time and at a cost similar to the original estimate. However, I would have be up front at the start (and in the contract) about maximum iterations and time spent before triggering the hourly rate. This most of the time anyway, worked pretty well to set the client's expectation to what I needed to match their estimate. I do understand that this wouldn't be palatable to most businesses anymore because it means having to be more trusting and flexible about the end result. Yet in almost all cases, I was able to please the companies I worked with and do it mostly on time/budget. Indeed, they sometimes had to compromise a bit but the end result as measured by revenue and traffic was almost never disappointing to them.
I'm a big believer of listening carefully and delivering not what "I" want, but what my customer wants. That said, I also believe business should be open to the advice of design (and other) professionals, because that is what they spend all their time doing. If you're fighting stuff like color/font/design choices with your designer to the extent that you have to go through a million changes, you've either picked the wrong designer or you might also consider the possibility that you might not be effectively communicating your opinions and/or that they might not make sense.
I don't think the example compares. In languages like JS, double, triple or even further nested ternaries are possible. But terser isn't always better because human readability is important. I can easily understood your SASS example because I know SASS, but I'd never write it like that. If I really wanted to add a decedent selector from a body class to .class1, I'd start a new nest on the body tag.
The problem with Tailwind is there's nothing you can do to avoid the much more difficult to scan and understand syntax described above. I personally don't understand why people are drinking this koolaide. I really think this is a fad a lot of people are going to come to regret when they go back to maintain older projects based on it.
> If I really wanted to add a decedent selector from a body class to .class1, I'd start a new nest on the body tag.
a) maybe you don't really know how far up the chain that tag gets called from.
b) it creates new selectors for class1 and class1.class2, as well as class1.class2's hover
c) creates a hyper specificity
now, I'm not advocating this usage of SASS - but it can be a handy hatchet when you need to support multiple themes with minimal changes/effort, much to the chagrin of specificity and maintainability
The point I was trying to make was just because Tailwind doesn't happen to be expressive enough to get you into that particular kind of mess isn't a reason to use it. True, its fair to say you can write bad CSS or SASS, but that's the same for all programming languages. If your main goal is something foot gun free and safe for the inexperienced, might as well go all the way and recommend low/no code or even Squarespace.
I think the reason a lot of ppl think they need tailwind, is because a) they aren't familiar enough with more current CSS techniques like CSS modules and linting which can limit stuff like nested descendant selectors and/or b) they're tricked into thinking they won't have to learn as much about CSS (a dangerous fallacy unless you're sticking to the most basic of prototypes!).
I understand they're trying to attract enterprisy customers, but even some of those are probably going to want to try it out first. Would be nice to have an easy minimal install option that doesn't require a deep dive into the project to figure out.