hnedeotes

The pig age full speed ahead

Yeah, it's musk's flying sausage car that's amazing

This is mostly a self made and kept problem. I also worked in codebases where the current developer(s) didn't know why things were the way they were and would take days to dig into why some part wasn't working - but the issue was, instead of taking the time to write tests and document, even if only when doing these point in time fixes, they just did the ad-hoc thing and solved whatever issue there was at the time without any worry whatsoever.

At some point I was tasked with improving the queries/retrieval times and started converting parts of the code and not only was it possible to write tests that would convey the actual meaning of the code and crystallise it but I started finding bugs in the implementation that no-one realized were even bugs because they no longer knew what it should do when queries grew to certain complexity and the search space was in the hundreds of millions of rows that thinking through them just with napkin calcs wasn't cutting it (specially when the bugs were subtle and the results still allowed the program to work "mostly" correctly).

Does it really matter? Normal observation. This post itself is already on the way to disappear... Farms bots everywhere, fake reviews, fake posts, fake experiences. David Lynch was probably right, white fences, smiley families, but underneath a stench...

Like linux is some bastion of security or something... I'm everyday more convinced that the reason why linux was let to dominate the server side with no contestation was so that the USA spy network could be done without compromising american companies. This is just the follow up of the same plan.

I think that this is also a matter of organisation that people can get better at if they understand a bit of how things come into place. If you start by creating a stable theme, with the spacings you want, the colors you want, fonts, sizings, etc, even using an AI, then you can "customise" in full the look of a web-app.

The html there's not really many places to be creative, a navbar with 3 sections, 5 links, a text card, a hero image, etc, all those are the same across thousands of projects - they're structured, there's not really many ways you can be creative about it. So in part seeing that "middle ground" design is indeed a filter for the lowest of the low effort (or not understanding how to prompt properly, or how the final thing comes together).

If you just want to prompt models and have them come up with more diverse styles that's also quite, or more, lazy - it would help if you understood (not you in particular) how the look of a web page comes together, because then you can direct the model properly - and if needed tweak the lose ends because at some point it's just easier and faster to edit the output yourself but you need to know what needs change and how. If you know how an html page comes together into the thing you see in the browser you can spec the model properly.

Because that's not the point. Before you could waste, without kidding, hours in meetings discussing css alignments, flows that didn't make sense but the upper levels were pretty serious about it - "Our QA and test groups say this is of the utmost importance", even when the QA and test groups were the same, 3 or 4 people that insisted on it. I think most people, but at least I, could always deliver things inside schedules (not even set by myself) without a problem, even with those "adjustments" and changes of mind, and doubly so if I could just have the same leeway that now seems to be in place.

Nonetheless, if there's going to be a premium it has to be discernible in any particular way because software for business is always considered a cost. But what really shows this industry is half a joke, is that now there's no issue in giving 3rd party agents full access to inner code and logic, many times credentials too because these systems are being deployed in CIs. And because there's really no enforcement or punishment for leaks, or endangering users in most areas there's no reason for a premium. There's people pushing thousands of lines / min (and I think even the most professional people out there can't honestly keep up with it) although that isn't in itself meaning the overall security is worse than before, it just means that for the most part it's now un-auditable in any meaningful way.

Thanks for the `handleEvent` tip, that's useful for component wide events, but it creates some problems if you need to prevent the event at the input level, because some (specially those related to submit) will need to pass through the form to bubble to the component level and will trigger it, and preventing it at the component level wouldn't cut it if I'm not mistaken? It also doesn't cover events on the document, but that can be worked around and perhaps even clearer to have it separated (`set_global_events(boolean)`). it's a good option to be aware of but I also like segregating them in that way since it allows me to turn on/off from other parts of the component outside the lifecycle calls (or even from a parent component) - sometimes useful too.

You would also need to switch inside the handle event to deal with the different types plus the different targets that might be bound to those events inside the component so I think that for anything with a modicum of complexity it doesn't cut it, unless I'm misunderstanding how to apply them in those cases (pattern matching with multiple function heads would definitively make it read like a declarative model but is not really serviceable in JS even if you syntactic sugar it, you wouldn't be able to describe `target` html elements probably - like:

`handleEvent({type: "click", target: {TAG: "input", id: "some-id", type: "input"}) { ... }`

and then another

`handleEvent({type: "click", target: {TAG: "button", ...}) { ... }`

, etc).

The importNode I think there was some issues with some properties not being copied outside of clone? I can't recall why I defaulted to `cloneNode`, could also be I just missed the `importNode` altogether or misread it at the time, but it has worked fine since then so I didn't look for ways to do that better.

Regarding batching, I basically have been using the same class extension since I've started working with webcomponents and it works, it uses a timestamp to control if we're inside the batch window for the inner working and then the "apply/build" part of each component has to compare those and decide - this is the part I would rather not have to code and have it handled natively (some events might actually run a single pointed update while others run the "full" apply/build function). It's nonetheless a bit more wiring and someone that never seen it might have the same reaction as some people here, even though they're fine in importing 50 libs, or 20 lines of useMemo with useState and useWhatever but heavens forbid they might need to read a 50loc class module. At some point many components need to ditch the `attribute` change handles as parsing the attributes into json/objects can get expensive, and you need to start doing parent->child direct data transmission and this is the only real bottleneck I've experienced when using attributes and requires an overhaul to how data is passed into the children (either from parent orchestration from top level attribute parsing that is fairly less taxing when done once only, but at a certain point can still stall the main loop just the same, at which point you need to parent-level requests, websockets, SSR that then you can pass directly to the child child_component._set_whatever_data_function(data) or setting the prop directly if it's workable in the particular case).

The thing with being able to load html fragments (or, even if whole html docs would be what we settle into) and having it be available would be that you could separate them into cacheable requests - so if you have `/essential-templates.html` , `/signed-in-templates.html`, `/special-page-templates.html` they could be cached, which means they would only need to be refetched if they changed or TTL expired. But with no way of declaring dependencies it can (will) also introduce bugs - if there were we could probably do some cool (as in useful) things too. I guess this is what many frameworks end up doing when they need code splitting, modules, and to create the initialization tree of a page/component, but then need to be re-implemented from scratch by each and leave vanilla webc out of an inbuilt system for it.

Here I might just be lacking some knowledge, and perhaps with TS it would be possible to, but the same way you write `static get observedAttributes() { return ["data-flux"]; }` would be great to have a `prop` like system, say `observedProps` that specified the `required` props when the node is to be attached to the DOM (not before, since `createElement` doesn't take options right? for the constructor or otherwise) for the cases you're adding elements from inside another component, that don't derive their inner state/data from attributes due to parsing cost and require directly setting those props.

Shadow dom is not something I use very much because I'm not creating widgets for third parties, or having to have locked components, but I do understand their existence and think it makes sense to have that mode too.

I imagine this is a complex topic altogether to push forward in the context of wrangling so many disparate interests (companies with lots of power and the only real players when it comes to browsers) but nonetheless not having them forces everyone and the webplatform to be way more spaghetti and troublesome than it needs to be. And I think that at a certain level, these issues go beyond the implementation and RFCs into the way browsers actually work, their engines and choices made before, that don't seem to be reasonable in hindsight when looking at from where we landed but asking for a new model will have 0 traction (of the type that matters) since there's too much at stake for what I imagine are "other" reasons.

Thankfully there wasn't mistagging, we could have ended with workjackass.

Yeah, the dialog thing is extremely annoying... I use them, and I always have to have a work-around for when morphdom replaces the dom nodes of a dialog because it will just make it disappear ... `non-programmatic-open=true` would solve it - yes, it can have edge cases but then it's a matter of me programming correctly, instead of programming work-arounds every time I need it.

Not to piss on your experience, I use WebComponents for almost everything and they have a lot of issues (mostly they're not really integrated into a coherent model with the remaining things that always exist in their presence, the browser, DOM, lifecycles, requests, etc) but being slow can only be an issue of your implementation to be honest, it's an imperative model for the most part - in fact the reason why I've started using them was because it was much easier to make things fast easily - there's no way updating/replacing dom elements surgically is faster with any other framework.

I think that comes from the way they can "learn" the game. I don't think more modern models rely on the knowledge of how many pieces there are in the game, probably they model it as given these pieces in this grid table, and rules for each piece and player actions, how do you reduce the state of the table to one where the opposing player has 0 kings (the rules probably can just be the engine replying invalid move don't even need to be stipulated, would be my guess). Then you could generalize it to any sized grid, with how many pieces you wanted, even 2 or more kings per side. At least that's how I imagine it to go or how I would try to do it.

To be honest haven't played chess for years - I did MtG for a while even as I got older but then it just annoyed me and haven't played in years - it was when I started working on my own take on tcg's