Yes, exactly: I'm not saying everyone loves to paint or cook or whatever, but that a lot of people do, and it's weird and bad for the response to this kind of article, in which someone shares that they are losing something they enjoyed, to be some form of "well, not everyone enjoys that."
To some people this is a gain, to some people this is a loss. Objectively it is changing things, and I can agree on having empathy for those who it changes something for negatively.
I feel like we are in a period of low empathy, understanding and caring for others as an aside from just this piece.
That's the premise behind Lit (using the custom elements api)! I've been using it to build out a project recently and it's quite good, simpler to reason about than the current state of React imo.
I just evaluated Lit for work and while we didn't go with it, it was very nice. I love the base custom elements API regardless of using Lit or not, turns out that's all you really need to make intricate UIs that feel seamless.
Something about Lit/web components that's not written clearly on the label is the hoops you have to jump through to style elements. If you're using tailwind in the whole app, you just want to pull it into your custom elements without much boilerplate. My main app compiles a single minified app.css, it felt not so modular to now include that in every single component. The alternative is create a subclass that injects tailwind into Lit components. It'd be perfect it just had a switch to inherit everything the page already has.
By default, Lit renders into shadow DOM. This carries benefits like encapsulation (including the style encapsulation you mention). If you prefer global styles, you can render into light DOM instead with that one-line switch.
However, shadow DOM is required for slotting (composing) components, so typically what I'd recommend for theming is leveraging the array option of each component's styles:
static styles = [themeStyles, componentStyles]
Then you define your shared styles in `themeStyles`, which is shared across all components you wish to have the same theme.
oh nice! I didn't know that you can just make it use light dom.
protected createRenderRoot() {
return this;
}
And that's what it takes! I like using tailwind/utility classes so for the styles I'd need to have layers of compiled css files rather than one giant one.
The major downside of using light DOM is that elements cannot compose neatly since there's no delineating between what the component itself rendered and child content.
When you need to re-render your component, how does the component know not to replace the child content you rendered, Vs the child content it rendered into the light DOM. That's why the shadow DOM and slots were necessary, because then there's no intermingling of your content Vs the component's
This may not be a problem if you don't intend to compose your components. But if you do you will hit limits quickly
While you can easily turn rendering to shadow DOM off on a per-component basis, that removes the ability to use slots. It only really works for leaf nodes.
Pulling a stylesheet into every component is actually not bad though. Adopted stylesheets allow you to share the same stylesheet instance across all shadow roots, so it's quite fast.
Interesting, I'd be curious to know why you all decided not to go with it if you're open to sharing! Minimally to know if I should look at any other promising frameworks.
I see a good case for my company to use Lit for creating complex components such as highly interactive panels/widgets to be shared between React/Angular apps in our large ecosystem. However the decision was: 1. Prefer sharing plain JS/TS over framework code so try that first and 2. if the component is so complex and tricky to get right, it probably needs to be re-implemented in each framework anyways (or some sort of wrapper)
My secondary concern with Lit is the additional complexity of using shadow and light DOM together in long lived React/Angular apps. Adding a new paradigm for 75+ contributors to consider has a high bar for acceptance.
Ah yeah, definitely a much different equation when introducing this across many apps as a shared component library. Mixing different DOM abstractions together could get tricky for sure.
And yes attempting to add a new paradigm for that many people is I am sure quite the task. More political than technical in many ways as well.
I have never once said "Go build feature x" and let it run off. Not saying you do, but I feel like this is how a lot of people interact with these tools. I have a very conversational style of building with these tools, and I'm very blunt with them when I think they're wrong, since I'm fairly experienced and I can smell when something is seemingly wrong with the model's thinking.
I typically have a discussion about how I want the architecture to be and my exact desired end state. I make the model repeat back to me what I want and have it produce the plan to the degree I am happy with. I typically do not have it work in building large amorphous systems, I work with and have it plan subsystems of the overall system I'm building.
A lot of my discussion with the model is tradeoffs on the structure I'm imagining and methods it might know. My favorite sentence to send Claude right now "Is go google this." because I almost never take its first suggested response at face value.
I also watch every change and cancel and redirect ones I do not like. I read code very fast and like the oversight, because even small stupidities stack up.
The workflow is highly iterative and I make changes frequently, my non AI workflow was like this too. Write, compile, test, tweak and repeat.
I like this workflow a lot because I feel I am able to express my designs succinctly and get to a place I'm happy with with much less writing than a lot of the actual code itself which in many cases is not an interesting problem, but work that needs to happen for a working system at all.
I do wind up taking over, but feel less than I used to, in edges where its clear there is not a lot of training data or I'm working on something fairly novel or lower level.
I work in Python, Rust and Typescript (Rust by far most often) and the majority of my work is technically challenging but at the systems design level maybe not low level systems programming challenging. Think high concurrency systems and data processing, training models, and some web dev.
To add to this, I find talking to it about code quality or architecture issues can work quite well. Just treating it like another developer. Saying, “I’m not happy with the way the project is going because of X, and Y” and then making a plan for how to get things back on track. Maybe putting a complete rewrite on the table, or maybe just having it record the agreed code style principles in CLAUDE.md, etc
This bit a community discord server of mine where I am a mod last night since we have a large oceanic contingent, somehow NZ got swept up in it too and we scrambled a bit to change our onboarding and other general policies.
That solution will not work as well when the interfaces have not been standardized in a way that makes it so easy to import them into a script as a library.
Coding against every subtly different REST API is as annoying with agents as it is for humans. And it is good to force vendors to define which parts of the interface are actually important and clean them up. Or provide higher level tasks. Why would we ask every client to repeat that work?
There are also plenty of environments where having agents dynamically write and execute scripts is neither prudent nor efficient. Local MCP servers strike a governance balance in that scenario, and remote ones eliminate the need entirely.
It's not particularly hard for current models to wire up a http client based on the docs and every major company has well documented APIs for how to do so either with their SDKs or curl.
I don't know that I really agree its as annoying for agents since they don't have the concept of annoyance and can trundle along infinitely fine.
While I appreciate the standardization I've often felt MCPs are a poor solution to a real problem that coincided with a need for good marketing and a desire to own mindspace here from Anthropic.
I've written a lot of agents now and when I've used MCP it has only made them more complicated for not an apparent benefit.
MCP's value lies in the social alignment of people agreeing to use it, it's technical merits seem dubious to me while its community merits seem high.
I can accept the latter and use it because of that while thinking there were other paths we probably should have chosen that make better use of 35 years of existing standards.
Well if everyone was already using Swagger then yes it would be a moot point. It seems you do in fact agree that the standardized manifest is important.
If everyone had a clear spec with high signal to noise and good documentation that explains in an agent-friendly way how to use all the endpoints while still being parsimonious with tokens and not polluting the context, then yes we wouldn't need MCP...
Instructing people how to do that amounts to a standard in any case. Might as well specify the request format and authentication while you're at it.
I don’t get your point. Obviously some spec is needed but why does it have to be MCP?
if I want my api to work with an llm id create a spec with swagger. But why do I have to go with mcp? What is it adding additionally that didn’t exist in other spec?
You can ask an AI agent that question and get a very comprehensive answer. It would describe things like the benefits of adding a wire protocol, having persistent connections with SSE, not being coupled to HTTP, dynamic discovery and lazy loading, a simplified schema, less context window consumption, etc.
Yep. And those that did implement the standard did so for a different set of consumers with different needs.
I'm also willing to make an appeal to authority here (or at least competitive markets). If Anthropic was able to get Google and others on board with this thing, it probably does have merit beyond what else is available.
Well reading comprehension tells us they were surprised that most monero folks run their own nodes and that they were unable to find supporting information.
No, reading comprehension tells us that Claude Opus output the "unable to find supporting information" claim, which abecedarius faithfully relayed to us. There's no evidence in the text that suggests abecedarius attempted to find supporting information.
It was a form of "huh, interesting. I tried to quickly find some more evidence for this but failed."
If Claude as search engine were able to link to some backing (maybe like "we estimate around n nodes regularly joining the network, which roughly matches the order of magnitude of estimated users" ) -- that'd be great! I'd have said I was surprised but look what I found.
Instead:
- it couldn't dig up anything supporting, except that Monero sites encourage users to run their own node;
- one point it raised against was confirmed by another reply to my comment ("apps like CakeWallet, where their node is used and assumed as trustworthy"). (Claude listed the same and a couple more wallets it called "popular" with similar trust dependence.)
I agree with GP that just relaying a chatbot is rude. That's why I didn't do that.
Okay and if they had said Google we wouldn't be doing this dance, people just hate AI and its obnoxious to see comments about it on HN all the time. On a crypto post no less.
We get it you guys don't like AI, next!
It is equally obnoxious to people who talk about AI for everything as if it is a savior, it's a tool use it or don't.
I don't think there's an objective assessment of good code. I've been writing code for over 20 years at this point and most times I've seen what people describe as their own good code I disagree with various decisions.
Experience CAN remove pitfalls, though developers even disagree about those sometimes.
Organization, chosen abstractions, naming etc are basically personal thinking and have differed on every team I've ever been on.
When it's been good is when it's been consistent and that's taken a strong personality the team trusted to have authority.
Good code is subjective, especially once you start wandering into the territory of more esoteric approaches such as functional programming, domain-specific languages, code-generation, etc.
Bad code is one of those things that we can almost all agree on, often even the person writing it.
Alternatively: I don't know how to make a good movie, but I can recognise a really bad one, and you'll almost certainly agree with that opinion. You and I however will almost certainly not agree on what our favourite movie of all time is. The nuances and personal tastes become more important at the last few percentage points approaching 100% "like".
I think we can agree on a version of bad code, specifically extremely bad code.
Just as we might agree on universally panned bad movies, but disagree on cult followings or one of us for a particular reason can't stand a popular movie.
That is to say we can all agree on extremes, but just because something isn't extremely bad doesn't make it good in everyone's eyes and that's where the contention is.
I used to obsess about code, but over time I came to dread coming into a new codebase and finding layers upon layers of pointless mini-architecture. There would be a controller calling into a separate package where the actual implementation is, then that would call into a layer where service calls are, then all that would be abstracted just in case and built into a separate jar, and so on. And there would still be cross-dependencies. I think what happens there is a kind of purity spiral effect and developers have to go through the motions of following the best practices du jour instead of just calling the damn method.
I feel like its just a reflection of people's minds. People organize their thoughts very different from one another and people often don't organize their thoughts at all when under certain constraints such as needing to ship NOW.
Especially with enterprise code you're hammering your thoughts into a shape roughly compatible with someone else's so its no wonder overtime with the constant revolving door of people that without careful shaping things can get nuts.
This is mostly the financial sector generating revenue and shipping/receiving. There's not really a lot of actual production going on since that's what really backs the funny money you referred to as "generating GDP."
My family eats out at a nice steak restaurant every Christmas no one wants to cook. None of us like to cook.
reply