I've been doing this for about three or four years. Clever idea, tricky in practice. I don't think I'd recommend this approach broadly. But it works for me.
It's definitely possible to take it too far. When most tags in your HTML are custom elements, it creates new readability problems. You can't immediately guess what's inline, what's block, etc. And it's just a lot of overhead for new people to learn.
I've arrived at a more balanced approach. It goes something like this:
If there's a native tag, like <header> or <article>, always use that first.
If it's a component-like thing, like an <x-card> or <x-hero>, then go ahead and use the custom tag. Even if it's CSS only, without JS.
If the component-like thing has sub-components, declare the pieces using slot attributes. There will be a great temptation to use additional custom tags for this, like <x-hero-blurb> inside <x-hero>. In my experience, a <div slot="hero-blurb"> is a lot more readable. The nice thing about this pattern is that you can put slot attributes on any tag, custom or otherwise. And yes, I abuse the slot attribute even when I'm only using CSS, without JS.
Why bother with all of this? I like to limit my classes to alteration, customization. When I see a <div slot="card-content" class="extra-padding-for-xyz">, it's easy to see where it belongs and what makes it unique.
Some of you will likely barf. I accept it. But this has worked well for me.
I'm highly interested in approaches that utilize web grain in a balanced practical way. Do you have a framework/toolbelt or example sites to share? Would love to see.
It utlizes custom elements, has autohooks for granular DOM updates, uses native JS template literal syntax for interpolation, imposes ordered component structure:
AI's superpower is doing mediocre work at high speed. That's okay. Great, even. There's lots of mediocre work to do. And mediocre still clears below average.
But! There's still room for expertise. And this is where I disagree about swimming with the tide. There will be those who are uninterested in using the AI. They will struggle. They will hone their craft. They will have muscle memory for the tasks everyone else forgot how to do. And they will be able to perform work that the AI users cannot.
My ongoing concern is that most of us probably got to being able to do good work via several years of doing mediocre work. We put in the hours and along the way learned what good looks like, and various patterns that allow us to see the path to solving a given problem.
What does the next generation do when we’ve automated away that work? How do they learn to recognise what good looks like, and when their LLM has got stuck on a dead end and is just spewing out nonsense?
If the gamification is fully disclosed, I don't see the problem. People should be able to agree to game themselves, if it helps them complete a task they otherwise wouldn't finish.
But consent is key. Maybe we need regulation that compels companies to disclose these manipulative techniques in digital services. Give people the chance to opt in or out.
People should be allowed to game themselves. But this isn't language learners setting up little games for themselves to learn more. This is 1 version of gamification pushed on all of it's users, whether or not it would work for them (or at all).
Server-side JS is fine, and actually very nice in some contexts. The language and runtime(s) have come a long way.
But anyone who tries it without really understanding JS is eventually going to have a bad time. It’s important to know how to work with the event loop, how to properly use promises, etc. Server-side JS is a lot more unforgiving than front-end JS when it comes to these concepts.
RISC-V is the ISA, which is a solid first step. What you need is a production-ready fully open source whole device, so that someone who wants to fork it only has to change the parts they need to be different instead of having to also re-engineer the missing components.
"Innovation" in this context does not mean cutting-edge technology. It just means changing processes to deliver better results. The tech is often the easy part, and there's plenty of room for boring software.
The hard part is navigating the bureaucracy and building consensus toward a change. This management-craft is where the clever thinking and emergent solutions are found and deployed.
I would probably spend an hour or two just writing something like that. On the surface, I'd agree.
With that said, in my experience, many stand-up formats devolve into some version of "the two most talkative people have a conversation for 30 minutes while everyone else listens". I'd probably get more value out of doing a write-up than sitting through a meeting like that.
It really depends on the health of the stand-ups on the team.
Yeah, I would also generally agree. But what they are showing is the 'Basecamp workflow', where instead of monopolizing a meeting or posting walls of text on slack or sending an email, you surface the issues on the project management level, where everyone can find it. It's their thing.
This is how I started my collegiate journey. I made enough money at my minimum wage job to pay for my entire community college's quarter's fees up front. It really helped me figure out how and where I wanted to pursue higher education.
Did my first two years there to get an associate's and then transferred to an in-state school where the tuition was a bit more expensive but much less than the average college student's.
I took an intro to philosophy course in community college where the professor was passionate about teaching it, and would happily play with ideas with students. We had 15 students in our course, and he'd sit us down and discuss our papers on the books and readings assigned for the course, and generally loved it. He had to - he wasn't being paid a lot for teaching at the community college, so it had to be a passion.
I had to take another intro to philosophy course at the university. There were 90 people in the course in a small lecture hall. We were assigned many of the same books and readings, but they weren't discussed in any detail or with any insight, our papers weren't carefully marked, and it felt like not even the professor cared as this was a course that checked a humanities requirement everyone had to take. The professor was tenured, and had to teach at least one course in addition to whatever else he did for the school (which wasn't clear to use as students).
I learned more for less at community college, and some of the readings and discussions we had still float into my mind sometimes. The only thing I remember about my university philosophy professor is that he'd sometimes pace at the front of the lecture hall with a baseball bat and when he made a point he thought was good he'd pretend he was hitting a home run with the bat.
It's really clear to me. (And I did account for the subsequent README commits since your comment). But that's probably because I already know Web Components well. I'm in the market.
In the following line...
> Hyphen - A custom element base class for great developer ergonomics.
...I would recommend adding a link on "custom element" that points to a definition somewhere. This might make it easier for skimmers to parse the meaning of this opening line.
It's definitely possible to take it too far. When most tags in your HTML are custom elements, it creates new readability problems. You can't immediately guess what's inline, what's block, etc. And it's just a lot of overhead for new people to learn.
I've arrived at a more balanced approach. It goes something like this:
If there's a native tag, like <header> or <article>, always use that first.
If it's a component-like thing, like an <x-card> or <x-hero>, then go ahead and use the custom tag. Even if it's CSS only, without JS.
If the component-like thing has sub-components, declare the pieces using slot attributes. There will be a great temptation to use additional custom tags for this, like <x-hero-blurb> inside <x-hero>. In my experience, a <div slot="hero-blurb"> is a lot more readable. The nice thing about this pattern is that you can put slot attributes on any tag, custom or otherwise. And yes, I abuse the slot attribute even when I'm only using CSS, without JS.
Why bother with all of this? I like to limit my classes to alteration, customization. When I see a <div slot="card-content" class="extra-padding-for-xyz">, it's easy to see where it belongs and what makes it unique.
Some of you will likely barf. I accept it. But this has worked well for me.