I think both Bill and Jon have discussed this at length and are both mutually respectful of what problems each are trying to solve, could be wrong. At the least, I think it's disingenuous to suggest that Odin is "mostly copied" from Jai just because they have a few similarities and share inspirations.
See [1] where Bill discusses the influences and where they've diverged longer-form.
I have had similar questions, and am still evaluating here. However, I've been increasingly frustrated with the sheer volume of anecdotal evidence from yay and naysayers of LLM-assisted coding. I have personally felt increased productivity at times with it, and frustrations at others.
In order to better research, I built (ironically, mostly vibe coded) a tool to run structured "self-experiments" on my own usage of AI. The idea is I've init a bunch of hypotheses I have around my own productivity/fulfillment/results with AI-assisted coding. The tool lets me establish those then run "blocks" where I test a particular strategy for a time period (default 2 weeks). So for example, I might have a "no AI" block followed by a "some AI" block followed by a "full agent all-in AI block".
The tool is there to make doing check-ins easier, basically a tiny CLI wrapper around journaling that stays out of my way. It also does some static analysis on commit frequency, code produced, etc. but I haven't fleshed out that part of it much and have been doing manual analysis at the end of blocks.
For me this kind of self-tracking has been more helpful than hearsay, since I can directly point to periods where it was working well and try to figure out why or what I was working on. It's not fool-proof, obviously, but for me the intentionality has helped me get clearer answers.
Whether those results translate beyond a single engineer isn't a question I'm interested in answering and feels like a variant of developer metrics-black-hole, but maybe we'll get more rigorous experiments in time.
How does their stewardship of a CSS library exempt them from being a valid company? The fact that the market is competitive alone isn't justification.
I agree that it's not obvious to me how or why Tailwind should turn a profit as a business, but there are examples of other similar companies turning profits, no?
I think of Motion (formerly framer motion) for example, which is primarily an animation library: https://motion.dev/
For your first question, IMO the purported advantage is mainly convention at scale. There's nothing inherently wrong with raw CSS in style tags or other authoring models (well, except CSS-in-JS at runtime...). Tailwind is one simple authoring model that works at scale without fuss and bikeshedding. Wrote up my experience with the advantages and disadvantages on this though a bit ago to be able to point to[1].
For the second question, depends on your definition of "meaningful" I guess. I doubt the original goal was to make money. There's OSS less prolific than Tailwind that makes money. Is it unreasonable for those projects to seek ways to compensate their projects?
A few days ago I was trying to unsubscribe to a service (notably an AI 3D modeling tool that I was curious about).
I spent 5 minutes trying to find a way to unsubscribe and couldn't. Finally, I found it buried in the plan page as one of those low-contrast ellipses on the plan card.
Instead of unsubscribing me or taking me to a form, it opened a convos with an AI chatbot with a preconfigured "unsubscribe" prompt. I have never felt more angry with a UI that I had to waste more time talking to a robot before it would render the unsubscribe button in the chat.
Why would we bring the most hated feature of automated phone calls to apps? As a frontend engineer I am horrified by these trends.
Feels like I'm working on a million things (between work, side contracts, and creative explorations). Recently a friend asked whether AI is helping or hurting my workflow.
And I realized I couldn't give a concrete answer. Lots of speculation, but I realized I didn't have hardly any real data. Inspired by Adam Grant's work on "rethinking", I'm _currently_ writing a tiny CLI to run self-experiments on my own productivity, auto-checking in / observing commits/code changes.
Goal at the end is to be able to test myself across different dimensions with "no AI", "moderate AI" (e.g. searching, inline assist), and "full AI" (agents, etc).
https://github.com/wellwright-labs/pulse
I've also been wanting to make Gleam my primary language (am generally a Typescript dev), and I have not had any issue with using it with LLMs (caveat, I'm obviously still new with it, so might just be ignorant).
In fact, I'd say most of the Gleam code that has been generated has been surprisingly reliable and easy to reason about. I suspect this has to do with the static typing, incredible language tooling, and small surface area of the language.
I literally just copy the docs from https://tour.gleam.run/everything/ into a local MD file and let it run. Packages are also well documented, and Claude has had no issue looping with tests/type checking.
In the past month I've built the following, all primarily with Claude writing the Gleam parts:
- A realtime holiday celebration app for my team where Gleam manages presence, cursor state, emojis, and guestbook writes (still rough): https://github.com/devdumpling/snowglobe
- A private autobattler game backend built for the web
While it's obviously not as well-trodden as building in typescript or Go or Rust, I've been really happy with the results as someone not super familiar with the BEAM/Erlang.
EDIT: Sorry I don't have demos up for these yet. Wasn't really ready to share them but felt relevant to this thread.
The project at a glance looks interesting, but it's difficult to tell what the target audience is. It doesn't help that the "About" link (which is actually a button) doesn't seem to take you anywhere.
As others have mentioned, would love a more thorough overview and/or a "who is this for".
You appeal to simplicity a lot, which is great! Contemporary frontend is way too complex. But a lot of what you're saying comes off as too black and white and rejects some of the learnings of the past decade.
Some examples:
- Inlining CSS is usually faster, but there are caveats to this. [1]
- You say, "the fastest page load is one that requires just a single request". This makes it sound like we should be avoiding the platform (the browser). Browsers can efficiently parallelize multiple requests. We shouldn't have the 200+ requests that many sites make, absolutely. But a rejection of requests entirely is not a goal. If you have a few interactive components that rarely change, having a few chunks that also rarely change means better caching too.
Point being there's no substitute to engineering and experimenting with what actually makes your site perform best for your users.
I resonate with much of what you've written in here. In particular, the cultural costs. I work on a "frontend platform" team at a mid-sized company and spend most of my day trying to get the React/Next ecosystem to play nice for our engineers. If I rearchitected it from scratch, it would not use Next, but I digress.
Some critiques:
1. As others have mentioned, lots of abstract in here, not so much data. That's a hard sell to engineers. You're going to get a lot of theory responses, which maybe is what you want at this stage, but it might help to make that clearer if so.
To avoid this, you might consider refocusing the narrative. I have personally found that while appealing to Developer Experience (DX) is the fad, debating DX is an uphill battle. IMO we should appeal to something more concrete: User Experience. The discussion has to start and end with users. DX is part of it, but often over-represented. If I can sit down with someone and show them X technology is failing our users because Y fundamental flaw, the conversation is no longer on frameworkism. It's instead on how you solve problems for your users effectively. See Alex Russell's discussions on this, as divisive as they might be [1].
2. The why is clear. The what and how are not. Clarify what you're doing that is different. For example, Astro is also standards-based. Astro also approaches the problem from progressive enhancement and fundamentals over frameworkism. It seems like your focus is on separation of concerns and design principles? While I disagree on the dogmatic approach re: separation (I personally like components and composition), it would help to highlight your diff.
* I mention Astro, but this is true of other newer approaches, e.g. 11ty, Qwik, Enhance.
3. In another comment you claim that [in Nue] 90% of your codebase becomes CSS. I get that this is coming from the reduction of JS to do what HTML and CSS should, but it feels... disingenuous? At scale, no frontend or fullstack engineer I work with is spending even close to the majority of their time on CSS, regardless of stack. The focus IME is on building features, parsing/integrating data, and everything tangential to the feature (architecture review, testing, docs, etc).
Just some thoughts! I'd be interested in hearing more in the future.
- https://wlls.dev - https://github.com/devdumpling - https://bsky.app/profile/wlls.dev