- i remember listening to Adam in one of the podcast he was in (I think it was either the Hackers Inc, or the Art of Product, but could've been something else where he was a guest) - and I remember that he mentioned that idea that there are always a new wave of new developers that they can sell the product to.
I still think he was correct. I myself bought tailwindUI as an aspirational purchase, and i doubt people would pay for it as a subscription.
But I think a lot has changed in the last few years. There arent probably as many new developers given the market, and among those there are probably even less that are willing to pay $100+ for a UI library, not when there are competitions like shadcn or radix or many others as free alternative, or when you could just ask an LLM to generate them for you.
Tailwind Labs definitely need to explore new revenue streams, but i dont think UI components is the way to go. Without knowing their internal data, this is just a guess, but I doubt traffic to docs or pipeline to premium products is much of a factor in the decline.
- i bought Tailwind UI years ago and have barely used it outside of like a couple of abandoned side projects. I bought it knowing that is going to happen because it is a one-time payment, and the idea of supporting the project/Adam is prob a bigger factor that the product.
I definitely wont even consider it if its a subscription.
Selling UI components is a hard sell to begin with - i think they made the right decision with a one-time point payment at that higher price point. If it were a subscription, i probably would've cancelled it within 2 or 3 months.
- They hire a lot from Southeast Asia - I know a couple of people who went there to find work. Some were deceived with promise of "customer service" work, some went there willingly knowing whats going on due to lack of economic opportunities back home.
The operation varies from online gambling operation to investment scams, mostly targeting chinese citizens. I know many that operates from Cambodia, Myanmar, the Philippines, etc due to ease of "getting around" local law enforcement as well (and apparently, Dubai), and some even have "internal transfers" between these countries.
- I dont know if LiveView is easy to learn though, maybe easy to learn the happy path, but when things are outside the normal path, things can be hard to figure out/understand, even when they know the basic HTTP stuffs.
At least thats been my experience with it ~3months back. I was familiar enough with elixir/phoenix/channels to source dive and figure out whats happening, and today i know liveview well enough to avoid the weird interactions, but I imagine it can be a pretty miserable experience for beginners to start with.
- Had the similar experience, and as it happens, I was also looking to build something with Elixir/Phoenix backend..
Its nice that it comes with a proxy `fetch` implementation that you can use to make requests to your API backend from the svelekit "backend", but there are many leaky API surfaces around it, esp when dealing with cookies.
The docs is also rather lacking regarding the many callbacks that can run on both server/client, though it is somewhat understandable given everything is still very much in flux...
- battery is one.. Android phones in general, even the Pixels, are already less energy efficient compared to the iPhones.. it will be much harder to work around that restriction with a smaller phone...
I use a Galaxy S10e, which is a "flagship" compact phone from few years back, and it has been a great phone that I still use today, but even on the day I bought it, battery life has been much shorter than what I was used (an IP8) to I suspected I got a lemon...
- fwiw I enjoyed the article, i agreed with some of them, disagreed with the others, but overall I liked the perspectives presented in the article...
can you elaborate more on the "Don’t pipe into case statements" point though? Not entirely what you're saying with this one as there isn't any explanation why one might be better/worse than the other, other than aesthetic/personal preference. Needing to access the result from the previous pipe in the case maybe?
- Not that theres a particular limit, just that its unbearably slow. To the point of it being pretty much unusable if you spend significant time of your work in a terminal text editor.
This is an issue with tmux on macos to be clear, not with alacritty, but it kinda is related as alacritty doesn't come with any window management features so you kinda have to use tmux..
Just checked out the project repo, seems like the warning is still there on the faq[1], so I'm guessing it is still the same.
but what is it about Amp Code that makes it immune from doing that? from what i can tell, its another cli tool-calling client to an LLM? so fwict, i'd expect it to be subject to the indeterministic nature of LLM calling the tool i dont want it to call just like any others, no?