sir_pepe

It does not count as "easy" if the features don't stay disabled.

Why not learn from past failures? Then everybody gets a great user experience, not only those of us who know how to set up a pi-hole. Everybody wins! Apart from the framework-industrial complex, that is.

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).

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.

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.

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.

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.

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.

To try and limit one's use of operations on types, as suggested in the article, is not really great advice in my opinion. Sure, you would not want to actually implement and use a VM in types, but distilling rules about a program into types and then deriving the actual interfaces and signatures from those rules with operations on types? That's quite powerful.

TypeScript's type annotations are really a DSL embedded into JavaScript. And they can, and, depending on the problem at hand, should be treated as such.

Not quite! If you have an attribute "onclick" and set the DOM property "onclick", the attribute value stays unchanged, but if you click, the function set by the property gets called. Set the attribute an both the attribute value and the DOM property change - the latter to a function as described in the original article.

Think of the actual function that gets called as residing in an internal slot on the element. Both the attribute and the property can set the slot's value, and setting and the DOM propertie's getter accesses the slot directly. Sort of, if i remember correctly.

The real fun comes when you consider the interactions between setting an event HTML attribute and the DOM property. If memory serves, setting the DOM property for eg. "onclick" to some JS function overrides (but does not change) the HTML attribute "onclick", while setting the HTML attribute replaces an existing property value. Took me quite some time to reverse-engineer this behavior for use in custom elements. Check out this library if you want/need html event attibutes for custom events on your web components: https://github.com/SirPepe/OnEventMixin

Oh, any by the way, HTML attributes work with event bubbling. Add "onsubmit" to some div tag and it will catch submit events originating from any of the div's children. This is why there is support for eg. "onlick" on stuff like h1.

If just being self-employed counts and raising the bottom line counts as "take off": I should have made my services much more expensive much sooner.

I less than 40% percent of potential customers balk at your rate, it's time to give yourself a raise.

After many years of following the JavaScript ecosystem, there's one thing I learned: most of the "many things" out there don't stay relevant for long. I personally make a conscious point of not diving into the hot new thing of the week when it first pops up on my radar. But maybe when it pops up for the eighth time, maybe only when it keeps popping up consistently over months and years. There is, for a developer, little to no first-mover advantage when it comes to the JS features or frameworks. And even if there was any point in trying to stay "on top of things": expecting yourself to know your way around every mayor JavaScript tool and library is as unreasonable as trying to become an expert in every programming language.

Truth be told, even though I live and breathe even keep a list of things (JS frameworks and APIs) that I've _explicitly_ decided to never take a closer look at, just for mental memory management purposes. No one can be an expert on anything in any field.

getElementsByClassName and getElementsByTagName return live HTMLCollection objects that update when the DOM changes (or rather get re-computed when you access their contents following a DOM change). Depending on what you do with them, you may end up with worse performance compared to the NodeLists returned by querySelectorAll.

As someone who wrote their last lines oh PHP in something like PHP 5, this list tickles my desire to take PHP for a spin again. Not only does the language appear to be much improved, but also the frameworks look so appealing! I'm seriously over dealing with all the low-level plumbing that comes with building Node/REST SPAs just for what's essentially a bunch of forms.

I'm working on Warhol [1], which performe tests on web design based on pattern libraries right inside your dev tools. Think reverse DOM diffing on the CSSOM. Sounds way WAY easier than it is, but that's sort of true for web development in general I suppose :) Currently working on rolling out tests for interactive styles (hover and friends).

[1] https://warhol.io/