While the observations might be true, I’m not sure going closed source is going to help here. If optimizing docs for AI makes you less visible, guess what else makes you less visible : not even being accessible.
Just because AI is "taking advantage" of projects being open source doesn’t mean the solution is direct closed source. Going with the most direct solution to a problem is an indication you might not have spent time thinking deeper about the problem
This is an example of when Daniel Kahneman said that people don’t believe in something because there are arguments but believe the arguments because they believe in something. Here’s why I think so:
> syncing plans and priorities for the current day
Most of the work developers do require syncing multiple times a day, either by slack messages, GitHub comments or pair programming, etc. Waiting for the daily to sync is not realistic and would waste tons of time.
> signaling blockers early so the team can help
If you have a blocker and you wait until the daily to mention it, you have a bigger problem. Blockers should be notified right away and most teams do this over slack or other messaging platforms they use.
> encouraging collaboration and knowledge sharing
Teams are usually small, and if you don’t already know what someone is doing, you wouldn’t care what they have to say during the daily, and if you care what they have to say, you already know what they are doing.
> building a sense of team ownership and support.
Just go for a coffee break.
If you believe daily standups are useful, chances are you’re actually part of the problem.
> If you have a blocker and you wait until the daily to say it, you have a bigger problem. Blockers should be notified right away and most team do this over slack or other messaging platforms they use.
They should but it doesn’t always happen. Having a stand up makes sure you can get that information into the open.
This holds for literally everything. You shouldn’t hold back conversations for your 1-on-1 but, if you don’t have them, you’ll find there’s a load of conversations you miss out on that you needed to have.
Having a daily standup might be encouraging people to wait until the daily to mention blockers, which could be harming your team all while you think it’s working
Not a fan (andersmurphy actually is better at explaining than me). However! I've been working with Micah from the Turbo.js team on idiomorph ideas. We are already multiples of v0.7.3 right now and getting faster each day. Together we can solve the core ideas even if we disagree on the top level API.
So I've used Turbo 8 to make a multiplayer app using a non rails backend. It was a struggle, the docs are incomplete. I mostly pieced things together from what others have done and written about. Which, is ironic considering your point about having a massive community behind it. The nice thing about Turbo 8 is morph (it uses idiomorph like datastar). It's also got a pretty simple refresh model.
However, you quickly realise the limitation. You can even see this in the Turbo 8 demo (see this issue https://github.com/basecamp/turbo-8-morphing-demo/issues/9). You can try to fix this with `data-turbo-permanent` but you'll now run into another issue that you can't clear that field without resorting to JavaScript. Which, brings me to the next thing, I found I was still writing quite a bit of JavaScript with turbo. Like HTMX pushes you to use alpin.js/hypercript turbo pushes you to use Stimulus.js.
Turbo.js is not push based it's mostly polling based. Even when you push a refresh event, it pushes the client to re-fetch the data. Sure this is elegant in in that you re-use your regular handlers but it's a performance nightmare as you stampede your own server. It also prohibits you from doing render sharing between clients (which is what opens up some of the really cool stuff you can do with datastar).
I was using turbo.js with SSE so no complaints there. But, most turbo implementations use websockets (which if you have any experience with websockets is just a bad time: messages can be dropped, no auto reconnect, not regular http, proxy and firewalls can block it etc).
Finally, according to the docs Turbo Native doesn't let you use stream events (which is what gives you access to refresh and other multiplayer features).
I like turbo, I'd use it over react if I was using Rails. I use it for my static blog to make the navigation feel snappy (turbo drive). It gives you a lot without you having to do anything. But, the minute you start working on day 2 problems and you are not using rails the shine fades pretty quickly. There are 3 ways to do things, frames, streams and morph. None of them are enough to stop you having to import stimulus or alpine and honestly it's just a bit of a mess.
I think he's also got a book on turbo he's releasing soon (if you go with turbo it's probably worth getting).
Those posts helped me grok Torbo 8 morph and ultimately what sold me on datastar. Morph, signals and SSE is all you need.
As for mobile I'll just wrap it in a webview (as an X native mobile dev I can tell you it will lead to a lower maintenance app than native or react native).
TLDR: datastar solves all the problems I ran into with turbo and more. It's faster, smaller, simpler, more examples, better docs and easier.
Regarding Turbo being push based and the approach of using refresh event to reload page. Would pushing Turbo Stream fragments using a SSE connection overcome the issues mentioned?
Is this the same as the Datastar approach?
Alhambra comes from the Moroccan Arabic word "Alhamra" which means The Red, it shares many engineering similarities with what was practiced at the time in what is today considered Morocco, some examples include:
- The Kasbah of Moulay Ismail in Meknes, a parallel to the Alhambra’s engineering sophistication, particularly in its hydraulic systems.
- Khettara Networks: Underground water channels designed to transport water down slopes without active pumping with gravity-fed systems that tap into aquifers, there are extensive networks of these particularly around Marrakech and southern regions.
I think a lot of comments are missing the point : it’s not about page size.
Today, most book writers are following a template of about 300-pages imposed by their editor, this (non justified) rule sold as a sweet spot is being (blindly?) applied by most authors and seems to be producing books that are unfocused.
What should be understood from the blog article is not that 100-pages books are inherently better, but that books should be written in a more focused way, without the unnecessary ceremony/anecdotes mostly added for the sole purpose of filling the void necessary to reach the « imposed » 300 pages recommendation.
It varies by book genre, but there are clearly page number requirements for each sub genre.
A history book will not be best selling if its not a giant doorstop of a book. A narrative non-fiction book will be shorter and snappier because different expectations hold.
A fantasy book should be a tome, etc etc.
For non-fiction, editors very much do enforce these limits. A short history book won't be taken seriously, unless its repackaged as a different type of book.
So basically the author is feeling lonely. That’s the primary message sugar coated in a long blog post, but when you have constructed your social life around drinking, it’s no surprise. The majority of people in the west actually construct their social lives around drinking, which is why it feels lonely not to drink, so it’s more of a societal problem than anything else.
She has another post where she talks about being an introvert and how difficult it is to make friendships when you are an adult. I have observed this myself. I suspect—-and this jives with her observations—-that as adults we tend to feel like social time must also be productive. Like we need to be DOING something. Alcohol is the social lubricant that finally allows us to chill out and not “do” things.
Children do not have this problem, I suspect, because there are no expectations of “doing.” They just are who they are, especially at young ages. I wonder if the author tried instead to engage in a pursuit that she liked for itself (eg, for us hackers here, a makerspace) that she might make more friends. Because the pressure of “doing” something and “trying” to be friends would be off. All of my best friends from adulthood were made this way—-we bonded over a shared passion without actually trying to be friends.
Using a programming language that you enjoy or you feel strong about is a much better choice, in that it will actually make you more productive simply because you’ll be programming more often.
> Using a programming language that you enjoy or you feel strong about is a much better choice
I enjoyed every single programming language I encountered and decided, or was compelled, to learn. Starting with BASIC, then Pascal, Assembler, C, VB, C#, F#, Java, Javascript, that followed by the plethora of "script" langs — Coffeescript, Typescript, Livescript, IcedCoffeescript, GorillaScript, etc. After that came Python and Haskell. Almost every book promised unbelievable riches and magic with this new (to me, at the time) language. Sooner or later, though, the long honeymoon would come to an end. At some point, while dealing with yet another clusterfuck of a project, I began to feel that I was simply not a good programmer and that I would never become one. Then I discovered Lisp. Somehow, inexplicably, things started making sense. Shit that confused me about Haskell and Prolog, I for whatever reason have started to grok, or at least I felt like it. For the things I build today, I use Clojure(script), Fennel, Elisp and CL. Even when I'm required to produce code in a different language, I still first prototype it in a Clojure. Not because I'm obsessed or blindly in love with one specific programming language, but because for the applications I'm building today, it makes sense — for me. I wouldn't argue that it would make sense for everyone, no. But for me, it does make sense. Today. Tomorrow that may change. Any given programming language is very unlikely to make you ten times more productive or accurate, yet it may provide you with even greater satisfaction. How? By allowing you to build something you love with it. Build something. Anything. And keep building more. And if you don't love it, rebuild it in a different language until you do.
Just because AI is "taking advantage" of projects being open source doesn’t mean the solution is direct closed source. Going with the most direct solution to a problem is an indication you might not have spent time thinking deeper about the problem
reply