People are just hoping they can skip from "hobby project" all the way to a project that funds a couple salaries just by overcharging for subscriptions. Apps that are meant to cater towards unorganized people are the worst for this because they know you won't stick with it. A week trial is just short of how long you'll likely use it before you forget or realize it's not working for you.
You can overcome shyness to some extend. Not getting invited anymore can also be a sign that the shy person has to change something about their behavior, instead of all others just accepting that.
Tailwind's default sizes add constraints, which makes Tailwind a bit of a design system. Also, Tailwind's default colors are just very pleasant to work with. Even on projects where I don't use Tailwind, I look up the color table in the docs.
Same, I really have nothing bad to say about the Tailwind design system.
I suspect there is a lot of halo effect going on, where if people were asked to judge the pure code aspect of Tailwind vs the design system separately, they'd be much more negative on the code aspect of it, but because the two are conflated and one is very good, Tailwind as a whole is judged to be much better than I personally think it deserved to be. It doesn't help either that forming an opinion on an architecture of code is difficult, and forming an opinion on a designed web page in front of you is easy.
My personal poison is just defining the Tailwind color system and a very basic system of sizes in CSS variables and then using that all over the place. It leaves an escape hatch in place of just using 5px when you really need to, but most of the time we use var(--col-grey-200) and var(--u-4) or var(--u-8)
When you aren’t using framework like components state restoration is a single function that runs only on page load. There is no state explosion and on localhost the SPA fully renders and finishes state restoration in about 105ms from http request.
Mate, if you are proud and happy to code this way, congratulations. That code is an absolute nightmare tho. Your eyes are trained on it so you think this is as good as an ergonomic framework.
It is arranged in objects defined as TypeScript interfaces. It can be easily broken down into numerous smaller files and be equally organized, but then the code would be in multiple places without any benefits except that there would be fewer lines in one file.
I get the impression that people who are only used to seeing front end code as JSX don't have any idea how to proceed when its just JavaScript. If they aren't also writing code outside the browser they are likely never exposed to application code in any real form because all they see is template abstractions. The reality is that it is just JavaScript which is no different in the browser compared to in Node, except for calling a different API. If this is the case then anything that isn't JSX is cause for an anxiety attack, most especially if its more than 120 lines of code.
If you are not capable of reading code then no matter of alternate guidance will matter.
> I get the impression that people who are only used to seeing front end code as JSX don't have any idea how to proceed when its just JavaScript.
I knew anything I said your answer would be something in this line. You think what you wrote is amazing but it is just verbose bad abstraction. If you think the difference between 4k lines of code and separated logical modules is just a matter of fewer lines (which might not even be the case), there is nothing I can say to you but it is funny that you use this terrible code as an example. You literally wrote all DOM manipulation repetitively and inefficiently by hand. But it makes you proud! Congratulations, I guess.
I couldn't care less about JSX tho you made too many assumptions about someone that thinks the example code sucks.
It is not abstracted at all. It isn't awesome. It is organized according to the TypeScript definitions in the project. The rest of your opinion is challenging to infer because there isn't anything of substance. Really your opinion can be reduced to: I don't like it. That's fine, but it isn't helpful. Its also why I am forced to make assumptions.
It isn't about being proud, or awesome, or some silly vanity. Its about being fast, almost 100ms fast, and organized well enough for quick maintenance.
Thanks, but this is a server-side thing and has nothing to do with client-side DOM manipulation?! Sure, you can put stuff on the server and do HTTP over the wire. It's oftentimes the better solution. But there are apps/tools that are rightfully an SPA (like tldraw or excalidraw for example) and can run local-first and offline in a browser. You build the entire app in JS and you'd need a bit more than vanilla Web components for that if you want to avoid client-side state explosion.
First off, thanks for sharing this, because I've seen a lot of your comments on these sorts of threads about web development, and it's helpful to see what your approach looks like in practice.
There are a bunch of amber flags that immediately stand out, like this being an almost 4k line file with a commit history by only one person, and an idiosyncratic approach to naming and formatting. None of that is necessarily bad on its own, but this feels like code that is written by the author for themselves, rather than for any other potential readers of the code. It's a lot easier to write code if you're the only reader, because you can keep a lot of the code's context in your head, and you don't need to write it down in the same way.
I skimmed through the start of the file and then jumped up the bottom looking for an entry point. From there, the table state jumped out to me as a thread I could follow, so I started exploring that.
The first thing that jumped out at me was how much defensive programming you are doing. There are lots of "if state X is not null" or "if event is not null" sections where it's not clear from the types or the logic that these values can ever be null. This makes me a bit nervous, because if you don't know whether something can be null or not, the reader is going to find it even harder to tell.
The next thing I noticed was how difficult it is to follow state changes around. Part of this is state being set in multiple places at once (e.g. `state.tables` and as data attributes on elements), but also because you use both `.dataset.xyz` and `"data-xyz"` fairly interchangeably, which makes it difficult to jump to the usages of some bit of state if that uses a different syntax.
This got me (finally) to some of the DOM manipulation code, which is what I was just eager to see in the first place. I landed in the tables.populate function, and the most surprising thing that jumped out to me here is that every table seems to be special-cased with a bunch if-else statements, partly for the rendering of each row, and also for updating the payload. Searching through this code, it seems like this mechanism of switching on the type of each module/table is all over the place, and that updating one part of the code is going to have massive knock-on effects on other parts of the code as well.
I'm going to stop here because I need to get on and do other things. I agree with you that you have largely managed to avoid building your own framework, but I think this is very much to the code's detriment: a small amount of abstraction would go a long way here in terms of, e.g. isolating the different tables from each other, or managing state effectively.
I can fully believe that you find it easy to write and maintain this code, but I suspect that has a lot more to do with you being the sole maintainer of this code than it does the clarity of the code. I see people confuse these two ideas a lot, but it's important to separate them.
Like I said at the start, I'm grateful for the chance to see your approach, and if it works for you then my opinion if it doesn't really matter. But it unfortunately does not convince me of your claims about the benefits of this style of development.
Web components are an implementation detail. They don't bring anything framework-like to the table. The most important being: reactivity. You have to write DOM manipulations imperatively like you did 15 years ago with jQuery. If you don't want that, you gotta bring a wrapper or another reactivity library/framework.
For many use cases, there's not much difference between writing a Web component or an IIFE (Immediately Invoked Function Expression) that attaches your JS functionality to a div somewhere like we wrote JS without jQuery 15 years ago, although Web components are more elegant. But still, they are mostly packaging.
I say this as someone who likes Web components and who created several ones that are used in production. But just yesterday, when I added a new attribute to one of my Web components and wondered for a moment why the new attribute wouldn't get rendered, I realized that I forgot to add the code that imperatively tells the DOM how to update itself. Which is okay, because this is just a small component and it's pretty lightweight. I'd never use a framework for stuff that can be achieved without much effort in vanilla JS.
My point is: selling Web components as a way out of this trap is disingenuous. They don't offer anything at all that is important for modern frontend dev.
> If you don't want that, you gotta bring a wrapper or another reactivity library/framework.
Being able to use a different library with a component, instead of the component being tied to React, is the whole point.
React isn't 100x more popular because its reactivity system or any other feature is 100x better. Half the reason it's popular is network effects – too many frontend components / libraries are made React-only even though they don't need to be React-specific.
Those network effects are the trap, not the reactivity system that's as good as any other for the purpose of writing a Web Component. If you don't want to use simple and small tools like Lit.js, that's fine, but that's your choice, not a limitation of Web Components.
The point of Web Components is not to provide a blessed state management or virtual DOM implementation that will have to stay in JS stdlib forever, it's to make the components you author compatible with most / all UI libraries. For that goal, I don't know of a better solution.
I get your point. I'm fully with you that it makes no sense to use React and write React apps if you can achieve the same without React. I hate the fact that many great frontend components only work with React, especially considering that React didn't properly support Web components for ages, whereas almost every other framework had no problems with them.
However, out of the box, Web components don't come with almost anything. Comparing React to Web components is comparing apples to oranges.
Lit is great, but Lit is a framework. Now you're comparing React with Lit. Different story than React vs. vanilla Web components.
Lit is not a framework. Lit only helps you make standard web components that you can use anywhere *because they are web components*.
You could take a Lit-based web components a rip Lit out and you would still have the same component that you can still use anywhere. Lit is just an implementation detail.
Lit is a framework, that's the whole point of it. Lit is a framework that happens to generate web components, but the goal of Lit is to provide the rendering and state management necessary to actually write those components. That's the framework bit.
If you take a Lit-based web component and rip Lit out, you have dead code that won't work because it's dependent on a framework that you have removed.
You could take a Lit-based web component and replace it with a non-Lit-based web component and that would be fine, because Lit uses web components as its core interface, but Lit itself is still a framework.
> Comparing React to Web components is comparing apples to oranges.
I mean, yes, but you're the one making this comparison, saying that WCs lack reactivity etc.
Web Components are an extension of the DOM – a low level browser API. They are similarly low level. That's expected. I don't need or expect them to be something more.
I am happy that I can use any reactivity system I want to implement a Web Component. That's a feature, not a bug. Having implemented a reactivity system myself, I know that there isn't a perfect one, the design is full of tradeoffs, and I'd rather not have a blessed implementation in the browser, because it will inevitably turn out to be flawed, yet we won't be able to retire it because "we can't break the web". A blessed implementation like that would benefit from network effects just like React does, and would have all the same problems as React, plus the inability to rapidly innovate due to the browser's unique backwards compatibility concerns. I'd rather ship an extra 3KB and avoid all those problems.
Fair enough. I agree with you. It occured to me that the comment I originally replied to that claimed "Web components are the way out of this trap" doesn't mean that you can't add helpers for reactivity.
Except the problem with compatibility is almost always the reactivity element, right? Getting, say, Vue's reactivity system to compose properly with Svelte's, or React's with Angular's. And that's not going to work well when Vue is using signals to decide when to rerender a component, React is using its props and state, and Svelte isn't even rerendering components in the first place.
This is especially difficult when you start running into complicated issues like render props in JSX-based frameworks, context for passing state deeply into a component, or slots/children that mean reactivity needs to be threaded through different frameworks.
The offer a way to build custom components that you can use everywhere, on every frontend framework, or plain html page. That's something that can't be achieved with any other tool. Also, if you use the Lit framework to build web components, @property and @state are reactive. The DOM part that uses those variables updates by itself.
Web components are the opposite of what you say: they are the component interface and specifically not the implementation. You can implement them however you want.
What they offer is interoperability and the ability to use components outside of a framework or with a framework.
And that's why they help solve the ecosystem trap.
React made reactivity popular. Web components don’t give you reactivity. You still tell the UI how to update based on state changes imperatively and that is annoying as hell.
If you want reactivity in web components, you need a wrapper or another framework/small library.
So, this story is from people who heard things? I can guarantee you that regulators have zero time for proactively looking for MISSING cookie banners. If they had time, they'd crack down proactively on the cookie consent management systems used by thousands of websites that do not comply with the regulation, because they implement the reject option as a dark pattern. Furthermore, this weird fantasy request you just described can easily be dismissed by the website operators with a single sentence: We don't use cookies, hence no cookie banner.
Individuals and other businesses have to complain to regulators about others not complying with the GDPR.
I love YouTube, so many things to learn. But their recent push to just ignore people capable of speaking two or more languages with their auto-translated bullshit and no way to turn it off makes me use YouTube way less.
It’s a bummer that nobody there seems to realize this. They only see a very dumb metric. Probably something like "did this German dude watch at least one Spanish videos, because we auto-translate titles and voice". It feels disrespectful.
"to just ignore people capable of speaking two or more languages"
I'm terribly annoyed by this, and even more so with their latest push to translate the titles, so now you have to click and listen in on the video in order to know which the original language is.
I speak 3 languages, and I want the title and voice to be in the original language. And I won't bother nor would settle with watching an AI translated video even if it is translated from a language which I do not understand. Then I simply do not want to see that video.
Me too. I hate the auto-translation feature. Both on YouTube and other websites that force it on you, such as the new Reddit (I'll just stop using Reddit when they turn off Old Reddit).
Likewise. Reddit just took the preference for old UI away on mobile for my account (seems to be some sort of testing they are doing maybe?). The new UI is jarring an not useful to me. And "old*" always seems to have a broken failure mode, that some links within reddit default to new.
I strongly advise any 3rd party app (I use Relay for Reddit) and it costs me $3/mo for decently heavy usage. About half of that goes to API fees and half to the developer. I consider that fair given the excellent features and lack of ads
And if paying for reddit is unacceptable, it's easy to get it for free.
Either use one of the still-supported third party apps with an accessibility exemption (RedReader for Android or Dystopia for iOS), or use any of the classic 3rd party apps with your own API keys - which you can get for free, if you mod your own subreddit. Takes 5 minutes to set up.
It isn't a feature, at least not for users. I strongly suspect youtube's autotranslate has more to do with regulatory compliance and content moderation. Rather than having people who speak X/Y/Z languages, they want each every video to be translated into English by default so they can be feed more easily into the the system that vets content. Having translated and non-translated copies floating around is probably seen as a needless complication.
Once a monopoly has been established, the next step is to actively make the product worse in order to either reduce costs or push users towards premium features.
I speak at least 3 languages at a native level.
Google's autotranslate 80% of the time selects a language I'm not just unfamiliar with, but can't even read due to the writing system difference (i.e. sudden arabic appears).
Considering I'm using it with an account that is about 20 years old now, that gave Google all of the permissions in the world and has all the possible data one might need to make the conclusions on which language I prefer, it is absolutely absurd that it cannot make a solid guess.
As another multilingual person, I keep getting reminded how bad software "features" can be for us. First, from early computers up to at least the Windows XP era, things sucked due to code pages and all that, but that was understandable, technical limitations after all. Now things suck due to what's supposed to be convenient UX.
Google Chrome broke Ctrl-F functionality for my native language ages ago and it's still broken because the breakage is apparently by design.
The Amazon website for my country appears to mostly auto-translate the English product pages into the local language. Product titles sometimes mean totally ridiculous things because of course the translation is poor.
Nobody cares about the Accept-Language header. Way too many websites like to use GeoIP and switch to the local language. Sometimes the geolocation is wrong, sometimes their location-language mappings are, and even when everything is working "correctly" it's a pain if I'm traveling. I have my browser set up with a correct Accept-Language list, but during travel I definitely see websites switch to a language I can't read.
Then of course there's the huge problem, related to autodetection, that you cannot deduce a user's language from their residence. Countries don't have a surjective mapping onto languages.
Because it ignores diacritics. Searching for ā will find a, searching for š will highlight s. This may make sense for some languages where diacritics are used sparingly to indicate an aspect of pronunciation, but in my language and many others diacritics are used for entirely different letters. The letter ā is not a. Treating them as equivalent makes as little sense as treating e and o as equivalent would in English.
If I'm trying to find kāzas (wedding) in a page, I will get hits for kazas (goats). If I'm looking for šauš, a letter sequence that words about shooting begin with, I will also get hits in šausmas (horror) or sauss (dry). It's nonsense. Windows 3.1 notepad.exe could find the actual word I entered in a text file (though the input required setup), the dominant browser in 2025 cannot do that and finds entirely unrelated words because an English speaker has decided they're visually similar.
Go into your Google account settings, under General, then add any languages that you watch YouTube videos in. I did this for Spanish and all my Spanish videos stopped getting dubs and translated titles.
They still track you? Is there much of a difference? Get an account you only use for YT, I can't imagine the difference in data leaking will be that much greater if they track you just by IP/other fingerprinting vs a session?
Thanks, I went there and added spanish since google and youtube were auto translating some stuff for me lately out of nowhere and I saw that there was a language already added for me by google, Uzbek. WTF?
It's especially annoying when you're searching for things that are done very differently in different parts of the world. No, I don't want to learn how to build walls or wire up electricity from e.g. Americans.
Watching any dubbed video is a big no for me. You lose ALL original expression, this was already the case with TV dubbing and it's far worse with anything auto generated. People with accents get translated poorly at best, resulting in garbadge.
The excuse is "most people want it so we force it", hooray for the dictatorship of the masses (by assumption, I've seen no research papers on the matter published by any platform).
It unfortunately could be true. I mean I hear people in my own family listen to the always same sounding auto generated narrator voices on YouTube and it has me thinking: "Oh my god why do you even listen to this crap???" and the portrayed ideology that comes along with such content is very questionable as well. Usually some low effort (a)social drama shit. It has zero worth. No, it is net negative! But apparently people watch or listen to that crap.
And so we see it playing out over and over again. Dumb masses creating market incentives for bullshit products and product decisions, ruining everything. If you want it with a pinch of capitalism critique: Oh right capitalism makes it so that we get the best products!!! lol
I was so confused by this when it first happened to me....
Watching quite some youtube content, and more than willing to pay any content provider for a worthy dose of content... I refuse to hand youtube any money and will happily play the adblocker cat and mouse and use clunky scripts to remove shorts. Starting to archive the most interesting channels myself. Thanks yt-dlp.
so many websites do this. ebay is another offender, where if you buy international items and speak english, it just gets in the way and introduces mistakes, which is especially bad if you're about to pay money for something. And of course, no way to turn it off.
If I click I’m not interested on every short presented to me and I’ve never watched a short, why can’t YouTube get the point? At least give us the option to remove them. I don’t deal with the translation issue but not giving you the option is what is beyond frustrating for me.
If you're using ublock, you can remove elements on webpages, including the area where shorts are on the YT pages. It's what I did on my mobile to stop watching them.
if your on firefox or one of its clones, firefox can auto run javascript scripts to remove shorts with the extension Greasemonkey, scripts can be found at 'the greasy fork'. there is also a decent youtube abdroid app called litube which can be found on f-droid which has a built in option to remove shorts (among other great options)
It took a little while but YouTube has stopped recommending shorts after doing exactly this. They still appear in my subscription feed but it’s less bothersome because they’re from channels I actually watch.
No, you don't understand! Being interested in anything works only in one direction, and that is the direction of getting you to engage with content that brings ad money!
This feature is so annoying. YouTube is always trying new stupid features that I wonder who they make sense to. The hype thing now, the games, I wonder for who are these things useful and if it's relevant in any sort of metric. I use unkook on desktop and Newpipe or my phone for a more minimal watching experience now
What's even more bullshit is that this is easily fixable on their side without impacting the goal of the feature. They just need to take into account all the languages of the user, not just the first one.
A similar case: for those who haven't seen it, Jimmy Kimmel's "Unnecessary Censorship" videos are regular videos with added bleeps to make it sound as if the person is talking about something censorship-worthy.
YouTube auto-translates these videos, with the end result being a random toss between the original uncensored speech, the modified speech with some sex term added in there (and unbleeped!), and random nonsense - all of it read in a robotic monotone voice.
The end result is completely unwatchable, except perhaps as a dadaist experiment. I can't understand how someone hasn't noticed it yet.
I currently dislike and comment every video that has out dubbing enabled.
I hate this approach but it is the only way to somehow make this awful feature more visible.
Yeah this is infuriating. I read 4 languages and now I'm left trying to reverse-engineer/guess what the title I'm reading was supposed to mean.
Add on top of that googles persistent (14 years and counting) inability to decide which of the three countries I've lived in they attribute my account to (sometimes it still opens maps centered on Stockholm 12 years after I left) and I understand why I watch way less video these days...
reply