I like the design, it's fresh and have good visual hierarchy (cool be improved in place but overall very nice). The content is fine for a first iteration I suppose. The tone is a bit aggressive sometime, I get you want to give a NO-BS focused mindset but maybe a tad over doing it. Also visually I think you could make more use the monetization impact of the game decisions - maybe that would help with "focused" branding without having to resort a condescending tone in some places.
You probably will want a bit more nuance - businesses have multiple growth path and there isn't just once recipe for things but tradeoff are real and choices have impact - it is more important to understand the impacts of the tradeoff that to be locked in on some mantras.
But again, all these are improvements that you will probably navigate yourself :)
the service business that will get fast turn over repair for a business to pay the premium they pay to levono/ibm isn't that easy to do. But yeah, I am sure they could create an ecosystem of reparability that would increase their sales
My understanding is that Dell/Lenovo share a lot of parts to keep the third party repair business viable, because they sell a lot of next day replacement contracts.
I have seen people rewrite entire application from React to htmx.
It works. But the architecture required is a tad different. Also you need Alpine as a complementary library for the reactive parts. (I mean you could do a lot just with htmx but I find Alpine more convenient in many places when I need to work with json - since I don't control all backend and json isn't really a first class citizen of htmx)
The beauty of it is that you don't _need_ Alpine at all, Alpine just comes up because it's popular, it solves the problem of lightweight inline scripting, and it integrates relatively seamlessly with htmx.
If you don't want to use Alpine for whatever reason, you can just write your own javascript, you can use hyperscript, you can use some other inline scripting library.
> when I need to work with json - since I don't control all backend and json isn't really a first class citizen of htmx
yeah, if you can't make the backend return HTML, you're in a worse off place if you want to use htmx.
There's extensions [1][2] for receiving and rendering JSON responses with htmx (though I haven't used them), but I totally understand it starting to feel like a worse fit.
If you’re using Alpine already, then is there a good reason to use HTMX over alpine Ajax? They both look quite similar to me, but I don’t do enough front end work to tell the difference.
Htmx offers more flexibility than Alpine Ajax. Here's an example: htmx allows using relative selectors, which allow you to target elements relative to the triggering element in the DOM tree. This gives us a lot of power for swapping in pieces of UI without having to make up ids for lots of elements.
I have a blog post in the works for this feature, here's a small code sample I made to show the idea:
I have tried to use exclusively each of the libraries to better understand their limit, overtime I got to the following observations:
- htmx is more straightforward (because a lot of the magic basically happening in the backend) and helps a lot to keep some sanity.
- Alpine shines when you need more composition or reactivity in the frontend. But it gets verbose quickly. When you feel you are reimplementing the web, it means you went too far.
For pagination, page structure, big tables, confirmation after post etc. I usually go with htmx. Modals, complex form composition (especially when you need to populate dropdowns from differents APIs), fancy animations, I prefer Alpine. (I probably could do that with htmx and wrapping it in a backend - but often more flexible in the frontend directly.)
To me, the main reason why I use these libraries, is what I write today will still be valid in 5 years without having to re-write the whole thing, and it matters since I have to maintain most of what I write.
So, instead of using one JavaScript library with an entire ecosystem of tools that work together, you use two separate uncoordinated JavaScript libraries? Why do you think that's better?
Different libraries composing well together is the default assumption in most of software development. Only in Javascript have people given up on that and accepted that libraries don't work together unless they've been specifically designed, or at least given a compatibility layer, for the framework they're being used in.
Qt widgets don't work together with GTK widgets, and nobody considers this a crisis. I'm pretty sure you can't use Unreal engine stuff in Unity. GUIs require a lot of stuff to compose together seamlessly, and it's hard to do that in a universal way.
HTMX achieves its composability by declining to have opinions about the hard parts. React's ecosystem exists because it abstracts client-side state synchronization, and that inherent complexity doesn't just disappear. When you still have to handle the impedance mismatch between "replace this HTML fragment" and "keep track of what the user is doing", you haven't escaped the complexity. You've just moved it to your server, and you've traded a proven, opinionated framework's solution for a bespoke one that you have to maintain yourself.
If anything, the DOM being a shared substrate means JS frameworks are closer to interoperable than native GUI toolkits ever were. At least you can mount a React component and a Vue component in the same document. They're incompatible with each other because they're each managing local state, event handling, and rendering in an integrated way. However, you can still communicate between them using DOM events. An HTMX date picker may compose better, but that's just because it punts the integration to you.
Ecosystems have their downsides too. Just a small example, no htmx users were impacted by the React Flight Protocol vulnerabilities. Many htmx users have no-build setups: no npm, no package.json, nothing. We don't have to worry about the security vulnerability treadmill and packages and tools arbitrarily breaking and no longer building after some time passes. We just drive the entire webapp from the backend, and it just works.
One never uses just one JS lib :) The JS ecosystem always comes with lost of tools, and libs, and bells, and whistles.
I like Elm for this reason. Less choices. Zero runtime errors (I know it is possible in contrived examples, but I've seen and many teams have said the promise holds true after many years of using in production).
nice! I would love some insights how you identify the the meaningful clips (how to explain to the LLM what meaningful mean for a given content) - I have to build a similar tool internally and that's the question I am trying to find a good answer to right now.
Regarding your UI, it's nice. I would suggest adding some basic control for audio level in the player. Else. adding some search bar with auto complete or suggested query can make the interface more engaging for new users and more practical for returning users.
Then next level, you can try to make TikTok for audio with scrollable vertical view and animated audio waves (listening to audio while seeing something nice is a good way to hook people in) and generated subtitles. Viewing the text from what you're listening increases focus.
1. gemini has native audio understanding so I would recommend checking out uploading there and playing with the prompt to get it's output matching what you are after
2. for audio over 1-hour I found chucking it into 45min segments made it easier for Gemini to give back reliable timestamps
3. you do need to check the LLM outputs for valid timestamps - it can go off the rails
I'll add search with the existing vector embeddings used for recommendation system and audio waves to the feature list - great idea!
Yeah, same here. I’ve got to the stage where what I write is mostly just for myself as a reminder, or to share one-to-one with people I work with. It’s usually easier to put it in a blog post than spend an hour explaining it in a meeting anyway. Given the state of the internet these days, that’s probably all you can really expect from blogging.
nice! An api is something i'm interested in, but for now it makes more sense to provide a GUI for more precise control. My thinking is that an API call to translate images would not allow for enough precision over the end result. What kind of solutions were you exploring for this problem?
Pretty neat. I use Emacs a lot, and also do quite a bit of video trimming. For people wondering "why Emacs?", here’s the use case: trimming video is mostly about writing down start/end times, sometimes with a note. That’s all text.
If you can turn that text directly into clips without switching to a separate video editor, it’s surprisingly efficient. Of course, this only makes sense if you already live in Emacs, then it reduces context switching, helps to keep the flow. If you don’t, it just looks odd. But it’s not about making a meme out of "doing everything in Emacs" - it is just a small tool that fits the workflow of people who are already in that environment.
Love nyxt - I am just waiting for when I will be able to use sites like youtube with it (or other common site just not compatible yet with the web engine.) They have a road map to move to Blink/Chromium which would make the site compatible with today's modern web.
reply