I did an image search for “holy delicious orange chicken”. Nothing to my liking came up, with a few biblical off images results. Then I tried “chicken jesus”, and whamo!
It’s only useful if the AI was trained on similar prompts. A lot of the anime style ones work best with lists of tags, while the realistic ones work best with descriptions like above.
Prompts are just the reverse of image recognition AI tagging stuff.
Alt text is exactly the kind of tedious work that AI would be good at doing, but everyone in the fediverse seems to have a huge hate boner for ANYTHING AI…
Fediverse: write a fucking essay every time you post an image… But make sure you waste time doing it manually, instead of using AI tools!!!
Happens to some SE Asians in North America too, because the edible straw mushroom from SE Asia resembles one here called “death cap”. Amanita phalloides. What’s fucked up is right before it kills you your symptoms actually improve, so people get discharged from the hospital and think they are going to be ok. I forage mushrooms but I stay away from white gilled mushrooms completely.
Yeah I had my yard full of destroying angels last summer, when they first showed up I was all “sweet! Mushrooms!” Because they look real similar to agaricus. But then I saw the white gills, and was all :(.
And I made sure to tell my kids not to mess with them and why.
The part that always gets me is when people choose Js for the backend. Like I get that it’s the default thing that works on the frontend, so there’s some rationale why you might not want to transpile to it from another language. On the backend though, there are so many far better option, why would you willingly go with Js, especially given that you’re now forced to do all your IO async.
No I meant having to do async as opposed to having threads like you would in Java for example. In vast majority of cases a thread pool will work just fine, and it makes your code far simpler. Typically, Java web servers will have a single thread that receives the request and then dispatches it to the pool of workers. The JVM is then responsible for doing the scheduling between the threads and ensuring each one gets to do work. You can do async too, but I’ve found threads scale to huge loads in practice.
I moved from primarily ASP.Net Core backends, which is a hell of a great backend framework btw, to NestJS. Not my choice. I do what the people who sign my paychecks ask for.
I cannot begin to fathom why anyone would willingly choose JavaScript for backend. TypeScript helps a lot but there are still so many drawbacks and poor design decisions that make the developer experience incredibly frustrating. Features that are standard in ASP.Net Core, Django, or other common backend frameworks just don’t exist.
Also, don’t get me started on GraphQL. Sure, it has performance advantages for websites of a certain size and scale. But 99% of the websites out there don’t have the challenges that Facebook has. The added complexity and development cost over REST is just not worth it.
Yeah, gql in particular is a problem looking for a solution in most cases. It makes sense for facebook because they have people building frontend apps for their marketplace, and those apps need all kinds of weird combinations of data. However, this isn’t the situation for most apps where you have a fairly well defined set of calls you’re doing.
Server side rendering looks like it could be useful. I imagine SSR could be used for graceful degradation, so what would normally be a single page application could work without Javascript. Though, I’ve never tried SSR, and nobody seems to care about graceful degradation anymore.
No one cares about graceful degradation anymore. But you can sell management on SEO. Page performance is a key aspect of search engine rankings and server-side rendered pages will almost always have a much faster initial load than client-side rendered.
Most pages tend be just documents and fairly simple forms. Making SPAs and then having to worry about SSR is just making a Rube Goldberg machine in most cases. I think something like HTMX is a much better approach in most cases. You keep all your business logic server side, send regular HTML to the client, and you just have a little bit of Js on the frontend that knows how to patch in chunks of HTML in the DOM as needed. Unless you have a highly interactive frontend, this is a much better approach than making a frontend with something like React and adding all the complexity that goes with it.
lemmy.ml
Active