Hacker Newsnew | past | comments | ask | show | jobs | submit | devalexwells's commentslogin

As far as I understand D* only uses id (which is a pretty normal HTML attribute?) to key morphs in SSE. I only use one id for fat morphs on the body, and even if I needed more I'm not sure I'd find that any less ergonomic than other web standard attributes (class for example I have to use religiously in my day job with tailwind, etc).

Can you elaborate on the "too complicated" part? It seems a lot simpler to me given the slim surface area of the APIs?


Just wanted to say thank you for this. In particular, the part where often it seems the "Founder mode" icons some evangelize (seem to) neglect their children and/or effectively put childrearing entirely on their partner.

I wish I had a good term (or some other concise way) to reject/criticize this aspect of tech culture.

I say founders above but I see it happen in lots of my peers who are simply workaholics. The closest saying I have (which I repeat often) is:

"The only people who will remember you worked late are your kids."


> "The only people who will remember you worked late are your kids."

I really need to kick my engrossing tech hobbies. :(

And yes to the wider point. There are many people more capable people than me, but sometimes it's about priorities, and top achievers in fields will usually be sacrificing something else.


What is the strong argument exactly? Odin coexists happily with Zig, Rust, C3, nim already, no?


Odin is different enough from those languages, where coexistence and what is offered should not be so much of a problem. Unless, out of sheer competitive or corporate spitefulness against others (the less, the better thinking) and for higher rankings, they feel compelled to reduce user choice.

Jai, on the other hand, arguably appeals to the same groups and circles as those that are or might be attracted to Odin. That even appears to go for their creators, where similar demographics of fans would likely choose Jonathan Blow.


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.

[1]: https://github.com/odin-lang/Odin/wiki/Odin-vs-Jai


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.

The tool open source here (may be bugs, only been using it a few weeks): https://github.com/wellwright-labs/devex


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?

[1] https://wlls.dev/blog/on-tailwind


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.


For me, no. I hate writing applications, but not sure automating all of it is beneficial to either party. Applying sucks, I get it, but...

As an applicant, I often discover reasons for or against applying for a company during the application process.

As an interviewer, it's not a dealbreaker, but it definitely stands out when someone puts in the effort to write a clear, thoughtful application.

So it would depend heavily on what the "savings" are here. Where does "20+ hours" come from?


That’s fair, and I actually agree with a lot of this. I don’t think everything should be automated, especially the parts where thinking and intent matter.

The “20+ hours” is mostly coming from the mechanical stuff: re-entering the same work history, dates, education, addresses, citizenship questions, etc. over and over across different ATSs. Not the cover letter, not the custom questions.

Ideally, the goal would be to reduce fatigue so people can put more effort into the thoughtful parts, not less.


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


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: