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).
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.
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.
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.).
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.
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.
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.
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?
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.
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.
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).