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.
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.
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.
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.
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 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.
100th birthday celebration for Sarod master and Bay Area Treasure Ali Akbar Khansahib.
Sidenote: I'm very impressed that in 2022 the community chose to put some creative energy into a website. It feels so much more personalized than the typical page on a ticket/event service and/or Facebook.
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).