I actually tried to shoehorn AI into https://code.movie/ as an experiment once, but it only got unpredictable and of course extremely slow. Hand-tweaked magic numbers plus escape hatches for manual intervention feel much more reliable.

The bigger ones do more out of the box! Most obviously, they include render functionality, which Ornament does not — you get to pick and choose your building blocks yourself.

My day job is all about doing presentations, so I obviously wrote my own slide software. It is a pure expression of my workflow, my requirements, and my idiosyncrasies and the way all of the above changed over ~10 years. It is a great performance booster if you can basically brain dump your thoughts straight into slides, and if you can just implement breaking changes (or choose to keep supporting an objectively bad feature for all eternity). I don't need to care about any other users, or the bus factor.

The only part of that software that ever became public was the animated syntax highlighter[0], but I don't believe any other part would help anyone else accomplish anything.

[0] https://code.movie/

Fortunately it is very easy to opt out of all of this. Nothing stops you from having a backed deliver HTML and then sprinkle some basic JS and CSS on top. In theory at least, in practice everybody's brain has been smashed to bits by repeatedly colliding with the hype train. But the old approaches still work, even better than in the old days (thanks to improvements to all the relevant standards).

Well yes, but people do write for resumes, not for anything else. For quality we would live in another world.

Yep. And there's also Phoenix, Rails, and Htmx.

The real problem in my experience is that people who consider themselves to be "real" developers don't care about CSS. I do a ton of code reviews and consulting for companies of all sizes and their JavaScript and TypeScript is almost always at least in a borderline defensible state? But CSS is always one giant file that has been growing since 2002 and is treated as an append-only log of !important. Nobody even tries to fix their CSS because nobody can imagine the concept of "well written CSS". It's like JavaScript in the early 2000s, where the language has (in the minds of developers) to be worked around with stuff like tailwind.

Css scoping has been fixed for ages already by css modules, styled components, or/and (native) support for nested css declarations. If those all fail there’s namespace conventions like BEM.

If your css is a mess in 2024 (2016 really) it is all on the developer and not the language.

Fixing scoping in userland, like with styled components or BEM, is definitely doable but not really the same as having native support for scoped styles in CSS.

There's nothing wrong with those solutions and I've used those and similar plenty, but they are fragile. Those are conventions that have to be maintained and stuck with, and often for scoped style solutions you're also left with a hard dependency on a build step (BEM is an exception there). That may not be a problem at all, if you're using react you almost certainly already have a build and bundle step, but not every project is that way.

You are not wrong. But my god, the tech debt in any slightly older web app's CSS is bonkers. Even with really well thought out templates you still end up with ~5000 line css files that have all sorts of state and magic in them. And like all tech debt, it's a triage.

What I'd really like is more intellisense for css so I could take a css file and get sensible code complete and class suggestions for elements.

you raise a very important point: the tooling around CSS is nothing like we have everywhere else. you can get class completion with Tailwind or CSS Modules (which I prefer), but even basic stuff like CSS Variables or SASS mixins are a black hole

I don’t know what tooling you use, but IntelliJ does all that for me, including autocomplete for variables, HTML elements in HTML files or components, and so on.

If you use the inspections, it can also make dead code removal really easy.

Often I only use CSS if I have no choice. I really do try to fix it but I still cant imagine "well written CSS". I look at the 2000 lines of necessities and know some of it isn't even used and other things could be simpler. The process consumes lots of time without much to show for it or worse.

CSS needs a compiler with warnings, dead-code removal, type safety, modularization, standard structuring and "design patterns" - then software engineers will take it seriously.

We do have tools for that though, how would a build tool fit into a language specification? Aren't those different concerns?

Dead CSS code should ideally be a warning on the web platform. This should be in the spec. Browser can probably emit a warning in the console log if there are CSS selectors that are not used. Authors can choose to explicitly mark with a `ignore-unused`, delete them or move such selectors to separate style-sheets that are loaded by the pages that actually use them. With HTTP/3 this makes more sense (CSS modularization) rather than one single massive CSS for the whole site that just keeps growing over time.

That'd definitely be a useful devtools feature! I don't see why it would need to go through the spec process though, browser vendors could build that independently and get it out much quicker.

Not true, member state's contributions are the largest "money maker": https://www.consilium.europa.eu/en/policies/financing-the-eu...

When you want to pass an object to a web component without going through JSON or some other stringification procedure.

How do you read it in the web component afterwards? Passing it via property sounds quite useful.

Web components are implemented using custom elements which are just plain JS classes that extend the HTMLElement class, so you would access the property the same way you would access a property in a normal JS class.

Thanks understood, that makes it quite simple and intuitive thinking about it.

The author of the thread is arguing against properties.

Yes, I know. I wasn't making a prescriptive comment about whether or not developers should use properties, I was just making a descriptive comment about how properties are accessed in a web component to answer the specific question politelemon asked.

Event listeners? Image data?

element.srcObject is very useful for <video> elements when the srcObject is a direct stream feed from the camera. I don’t even know how I would go about passing that as a string attribute.

https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaEl...

Building your own proprietary frontend framework still counts as a framework in my mind. Like how a custom tailored suit is still a suit, just one that is, well, tailored to spec. The whole "no framework" narrative is silly.

Well of course you need to make an standard way to achieve your goals in the frontend or else it's just asking for madness.

"Your own framework" may be a valid statement but at the same time the creation of the framework its just a side effect of applying sane software design.

Is that the point here?

I think the key point about using someone else's framework is that it's someone else's framework, not that it's someone else's framework.

RE decorators in TypeScript: it is true that TS code does not have to live in classes... in general. But some APIs (eg those for custom elements) _do_ require classes, so one may end up writing a whole bunch of classes anyway. And in this case, decorators are in fact quite useful.

Love me some decorators for defining web components in TS

Not really a "project", but TypeScript's own type definitions for the DOM are a great example. Eg. document.createElement returns different subtypes of HTMLElement depending on the string argument (HTML tag name) it gets called with.