| ▲ | Why don't more developers "use the platform"?(nolanlawson.com) |
| 88 points by vinhnx 3 hours ago | 48 comments |
| |
|
| ▲ | jchw 3 hours ago | parent | next [-] |
| For one thing, I just genuinely think WebComponents are a badly designed API that is weird and hard to use (how many people are using WebComponents without at least Lit, if not something much bigger?), and React is a relatively well-designed library that isn't really that bloated. There's not really much of a point in trying to argue since this is inherently subjective and people with different values are going to irreconcilably disagree. But, if you don't respect that some people hold this position, we're not going to make any progress towards a consensus. On the note of <dialog>, I recently tried to use <dialog> in a (React) application, and it did work pretty well, but I also found that in Firefox it is only practically possible to do a fade-in animation, not a fade-out one. That isn't really a critical issue for me, it is just an animation after all, but I find it unfortunate. I also find <dialog> to be a weirdly shaped API too: I don't really hate it, but I don't love it either. It feels awkward. I find this implicit view that developers that, for example, prefer React over WebComponents are making a suboptimal choice to be rather condescending and not really in the spirit of trying to see things from the other side. Wouldn't you want to focus on the strongest arguments and not the weakest ones? Maybe you've literally never heard anyone complain about WebComponents or Shadow DOM, but if so, I find that surprising. Certainly here on HN, I've seen a fair bit of WebComponents hate. I do, FWIW, realize that I've particularly focused on WebComponents, which this article doesn't actually name directly. But, I assume we're not talking about ditching React to implement our own component framework on top of the traditional DOM APIs, because that's what React already does... |
| |
| ▲ | josephg 2 hours ago | parent | next [-] | | > React is a relatively well-designed library that isn't really that bloated. I am one of the people who irreconcilably disagree. I think svelte and solidjs are - obviously - technically superior. But it leaves the question of why react is still so popular. I think the biggest reason is all the non-technical aspects of react: - They have excellent documentation. And have, from day 1. - They produced videos, sample projects, and all sorts of "getting started" documentation. - They ran react conferences, teaching everyone who would listen about "1 way data flows" and pretending like they invented FP. The amount of hype around it made it really feel like the next big thing. Between the very well funded react team and the outside developer community, there was real momentum. People learned it in droves. Taught students. Built websites with it. When react's poor design choices caused issues (and there were a lot of issues), then you were blamed for holding it wrong. (Component classes, state, CSS, hooks, webpack and babel taking ages, big bundle sizes, slow re-renders, and so on.) By the time the next generation of JS frameworks broke onto the scene, there was a collective moan from the community. "Oh no, not again - we just relearned how to make websites." React was the wave, and in its wake we all had Framework fatigue. Software doesn't get popular without a lot of work by dedicated people. I really admire the work standards bodies do. But they rarely bother to take the time to produce documentation, videos, tutorials, starter projects, blogs and podcasts and all the rest of that work. | | |
| ▲ | jchw 2 hours ago | parent [-] | | > I am one of the people who irreconcilably disagree. I think svelte and solidjs are - obviously - technically superior. I don't really think that React is necessarily the best possible library, but there is certainly more to a UI library than simply compiling out the need for diffing. For one thing, I find JSX to be a relatively unobtrusive addition to the language. It is implemented by a variety of things and is a pretty simple transform as far as things go; basically pure sugar, it's possible to avoid it if you want. It could be better designed than it is, but I think it's at least sufficiently general - it is feasible to say, use an alternate library with JSX, like Preact. Svelte on the other hand by its nature just simply requires a more complicated compiler step to work and deliver on its promises. That's a trade-off. Whether you think it's worth it is up to you, but presenting it as an objectively technically superior design is disingenuous. Superior how? Runtime costs? Sure, but it does beg the question how much. Will a well-optimized Svelte app feel much better than a well-optimized React app? > The amount of hype around it made it really feel like the next big thing. We are a really long way away from the hype of React. I would argue that hype stopped carrying React a long time ago. Momentum? Sure, but if something was truly dramatically better, then I think it would have a fair shake at beating out React. The problem is that the web isn't microbenchmarks and developer experience does matter to some degree, so the trade-offs that seem so good on paper don't always pan out. I'm not a hater of Svelte. On paper, it is a very elegant idea. However, when I actually tried to use it, I genuinely came out feeling that it was simply not for me, and the benefits it has are not enticing enough for me to continue experimenting. My React apps are not particularly slow or bad at handling huge amounts of data. (One of my apps has no problem handling a file grid of over 1 million items, and in fact, I run into issues with browsers not being able to handle a large enough scroll area long before performance of my React code is a problem. That is good enough for me.) |
| |
| ▲ | JimDabell 2 hours ago | parent | prev | next [-] | | > I just genuinely think WebComponents are a badly designed API that is weird and hard to use This was exactly what sprang to mind as soon as I saw the title. I’ve been writing front-end code for over 25 years now, and exactly two things in that entire time have made me miserable enough to think about stopping: Internet Explorer 6 and web components. Every time I try to just “use the platform” it makes me miserable and I end up demotivated and stop working on whatever side project I chose to try again with. And I otherwise like the web platform! I’ve been building with it since there was nothing but the web platform. But web components kill my enthusiasm for it stone dead. Even now in the age of agentic development, AI trips over all the same footguns in web components that humans do. It just seems like everybody involved has been adding to the standards with “yes, and…” without ever thinking about how it will be used by web developers in practice. | |
| ▲ | mg an hour ago | parent | prev | next [-] | | What do you not like about WebComponents? Say we want to make an icon that when clicked shows how often it was clicked. The webcomponent code seens quite sane to me: class HelloIcon extends HTMLElement {
connectedCallback() {
this.clickCount = 0;
this.innerHTML = `
<button class="icon">:)</button>
<dialog>
<p>Hello, I was clicked 0 times</p>
<button class="close">Close</button>
</dialog>
`;
const icon = this.querySelector('.icon');
const dialog = this.querySelector('dialog');
const closeBtn = this.querySelector('.close');
const dialogText = this.querySelector('p');
icon.addEventListener('click', () => {
this.clickCount++;
dialogText.textContent = `Hello, I was clicked ${this.clickCount} times`;
dialog.showModal();
});
closeBtn.addEventListener('click', () => dialog.close());
}
}
Try it here:https://plnkr.co/edit/0XUOLyM52xfFiIBu?open=index.html&previ... | | |
| ▲ | Too 31 minutes ago | parent | next [-] | | I don't know if that's idiomatic webcomponent or not but that looks unmaintainable, even for such a minimal component, imagine once it grows. It's not separating presentation from state and logic. querySelector need to match classes and elements in the markdown. Mutating textContent is going to run out of sync as soon as you have more than one event source doing the same. Those are all problems that React solve by separating state and only rendering in one path. | |
| ▲ | kaoD 42 minutes ago | parent | prev | next [-] | | That's the best case scenario and already looks like crap. If that looks sane to you, I don't know what to say. Make it have an initial count via attributes, sync it with the DOM so if the attribute changes the count resets, and make the JS property always match the attribute (and vice-versa) so it behaves sanely. You're in for a world of pain even for something as simple as this. Plus they're not declarative: you will only make me use innerText-based updates by threatening me and my family. Plus they only work with JS enabled, while I can use JSX in SSR. I've worked extensively with Web Components. They suck. | |
| ▲ | pwdisswordfishq 38 minutes ago | parent | prev | next [-] | | For starters, that it introduces weird special cases to DOM parsing and structure, thereby breaking .isEqualNode whenever <template> elements are present. | |
| ▲ | JimDabell 36 minutes ago | parent | prev | next [-] | | Why are your component styles global not encapsulated within the component? | |
| ▲ | jchw 27 minutes ago | parent | prev [-] | | Well for one thing, I don't find that to be particularly succinct or nice example. There's a lot going on there: - HTML in a string. No syntax checks. If you interpolate it, you have to escape manually or you could create trivial XSS vulnerabilities. Your editor will probably not syntax highlight it, making it harder to tell when you break it. - Manually formatted update logic that is redundant with the string. Not so bad here, but try formulating a practical large component. - Completely ad-hoc state management, no reconciliation. Again, fine for Hello World, not fine after that. Using raw WebComponents, your application has to care about all of this on its own and more. You can use templates and slots (which you should) but that makes this even messier IMO and brings back the split that React became famous for getting rid of. We left manual DOM reconciliation, ad-hoc data flow and non-reactive components that manually call a render routine at arbitrary points for a reason: it sucked. It made for buggier, harder to maintain code. It can be done, but usually any decent app will wind up encapsulating patterns into utilities that get reused. And... That's precisely why we want a good library. That's what I want, a library that packages up good reusable patterns for constructing UIs effectively. And that's exactly my point, which is WebComponents or not, the solution is still basically the same, use libraries. Which begs the question: if I have to use Lit, what is the point of "using the platform"? What is WebComponents doing for me here that React wouldn't be? And in my case, I struggle to see it. Interoperability? The old way of embedding external components works quite fine. Switching APIs where you pass a DOM node for something to mount into and get back an object with an API to one where you instantiate a component and communicate via properties and events feels like a strictly lateral move. I can't think of a condition where this would be particularly more convenient, but I can think of some where it is actually less. Next. Isolation? Yes, WebComponents does add tools to provide better isolation between components. For some use cases this is a genuinely useful feature, although it also isn't without tradeoffs (I mean, the flexibility of having things be not isolated comes in clutch sometimes, it's hard to argue this.) But I use React primarily to construct components in an application, where I find this property more undesirable than desirable. The one thing I thought could be cool with WebComponents is if you could build them in pure HTML when you only needed basic templating, but no: the design they went with always requires subclassing in JS AFAIK. I could go on and get more specific, but I feel like people will pick everything I just said apart quite enough. I hope I'm at least able to make the case that: - I do in fact, get the general gist of WebComponents. - I still don't like it despite that. |
| |
| ▲ | spankalee an hour ago | parent | prev | next [-] | | What about the web components APIs are bad, and how could they be done differently given the reality of the existing platform? | |
| ▲ | al_borland 2 hours ago | parent | prev | next [-] | | I have stubbornly avoided React. When native WebComponents became a thing, I figured I'd try them out on a small internal site I maintain. It was very slow. In an effort to reduce a bit of duplicate code, my site when from loading instantly to having a noticeable load time. Having to employ tricks to try and optimize and speed up the most basic implementation of a built-in feature seemed like the wrong move, so I ditched them all together and reverted back to my old structure. | |
| ▲ | pjmlp 2 hours ago | parent | prev [-] | | Only if you mean React before they went crazy with hooks and "use whatever" magic strings. I put up with it, because plenty SaaS products favour Next.js and React as their only extension SDK. I would never pick it up freely, all side projects with Web are VanilaJS, coupled with what is available on Java, .NET and PHP. |
|
|
| ▲ | usernomdeguerre 2 hours ago | parent | prev | next [-] |
| As far as I know there are still some things "the platform" actually won't deliver; for instance I'm fairly certain there's no searchable combobox that's fully accessible. One ~must leave the platform to give users the experience the expect. That means "the platform" itself is actually teaching people to work "off platform" and arguably will always have gaps as functionality and expectations evolve. Admittedly, the habit really ought to be 'I need to make a combobox -> does the platform have what I need? -> Research, evaluate, test -> Otherwise, make it' but I don't begrudge people for skipping the middle steps. |
|
| ▲ | flippingheck 26 minutes ago | parent | prev | next [-] |
| When a technology becomes popular enough, it develops a community that solidifies that choice: conferences, books, extensions, a generation of engineers that see things in terms of React. A technology needs to be a lot better to overcome that aspect. Sometimes I visit a subreddit for a tech and see them all discussing strategies/techniques that are ultimately workarounds for what an alternative technology has fundamentally solved, but...
the original tech has an army of volunteers able to help newbies workaround it, which is often an easier onboard experience than the alternative tech that just works, but doesn't have any advocating solutions/blog posts because there are no blog posts to be written. |
| |
| ▲ | jchw 8 minutes ago | parent [-] | | Counterpoint: the problem was solved by an alternative, but was it solved without any tradeoffs? If the solution comes with no real tradeoffs, then that begs the question why React wouldn't simply adopt the solution... And I think this is not a theoretical nitpick, either: Angular actually has, to my knowledge, basically done this more than once. And React certainly doesn't seem afraid to make big or breaking changes, from fibers to suspense to hooks to context, so I don't think it is resistance to change at play here. I think when you consider that the solutions sometimes may come with tradeoffs that cause problems that people like less than simply working around the first problem, it makes a lot more sense. I don't think conferences, hype, corporate backing explain the continued success of React; they help but it's just not the full story. I don't think they explain the continued success of anything else, either; I find this to be a shallow and lazy dismissal in most cases. It's easy enough to find counter examples where none of these things, not conferences, hype, corporate backing, or whatever else you could think of, were enough to make something work. While these things definitely help keep something relevant, they can't do it alone. In fact, in attempting to rationalize the success of React without acknowledging its strengths, I believe people have fundamentally reversed cause and effect. I think a lot of the continued success of React comes from people continuing to choose its set of tradeoffs over others even when they could tolerate risk. I think that conferences continue to be organized and books continue to be written because of its continued success. The tech community on the Internet has largely matured enough to acknowledge why PHP was and is successful; yes, there are many objective issues with it even today, but it also has many strengths beyond just having existed for a long time, too. Do I think you should choose PHP for new projects, the way I might say for React? Well, no, not really, if I'm being honest. But, I think it was nice to see people grow up and acknowledge that actually, there were and are a lot of redeeming qualities to PHP, and what it did for a lot of people was pretty cool, fractals of bad design be damned. It'd be a shame to see this repeated again more for stuff like React and say, Go, just because it's not the dog in the race we wanted to see win. (And I would understand that position, because I fully understand why people like Svelte, or Rust. I just don't think there is a conspiracy, it's just that there isn't a free lunch here.) |
|
|
| ▲ | simon84 35 minutes ago | parent | prev | next [-] |
| From other comments that are focused on the code part of the subject, I think there are 2 big forgotten points here: time and hype. Time: since platforms are big machines, their timeline and backlog is huge, and the self-taught geek does not consider (care) that. So when there is an obvious little hiccup somewhere, they create a bug report that asks for details, proof, reproduceability,... and finally get pushed back to eons because there are more pressing concerns to attend to at the platform level.
Meanwhile, it takes about 1h (without AI) to code a workaround and feel like a hero because "I've fixed something that took them 3 years to triage". Hype: yes documentation and code quality and all matter, but it matters even more when it comes from Google or Meta! We all feel little compared to giants and when they open their internal secret tooling framework (with big marketing budget) then we all feel like there is a secret to grasp and a key success factor to wield.
So it is not so much whether a npm library some nobody created exists, but whether the main contributor works at a big brand name. It does not prevent smaller anonymous projects from emerging but lets face it, it is much more appealing when it is how Cloudflare handles it at 1e20 scale (because we all feel we face the same challenges of course). |
|
| ▲ | butz 15 minutes ago | parent | prev | next [-] |
| Some developers are locked in to using some in house UI solution that is slow to implement any new features from evergreen browsers and even is still shipping hacks for IE11, although it was depreceted company wide years ago. |
|
| ▲ | nonethewiser 3 hours ago | parent | prev | next [-] |
| An aside: This name an logo are incredible. https://bevacqua.github.io/dragula/ |
| |
| ▲ | eptcyka 27 minutes ago | parent | next [-] | | An aside: drag and drop doesn’t work on iOS Safari well at all - dragging also pans the viewport. | |
| ▲ | sodapopcan 3 hours ago | parent | prev [-] | | I actually still use Dragula. I can't quite put my finger on it, but it just feels better than Sortable. I may be imagining it, but I also don't care because, you know, it's just a JS library. |
|
|
| ▲ | markbao 5 minutes ago | parent | prev | next [-] |
| People will just use the best tool for the job, putting aside some time it takes for practices to propagate. Native date pickers suck, are ugly, and have no customizability, and look inconsistent between user agents. They don’t even really conform to the OS either (other than iOS). Everyone uses JS. Chrome’s native date picker shipped with a monospaced input font, for crying out loud. Position sticky is amazing and the behavior is better than what JS can give you. A lot of people use it. Not much UI to make consistent between user agents. Make the platform actually good and consistent and people will use it. Native APIs are always the better choice if they accomplish your need. |
|
| ▲ | kangalioo 5 minutes ago | parent | prev | next [-] |
| This article misses the most crucial point. Developers don't "use the platform" because all the building blocks for any component you can think of are already there. When "the platform" adds yet another set of not particularly pretty and badly configurable components, why would we use them? When there's tons of mature, deeply thought out, battle tested, cleanly abstracted components out there - especially when _those_ components are made of divs and layouting and CSS and are therefore malleable to the pixel instead of being made of magic browser pixie dust? |
|
| ▲ | ibash 3 hours ago | parent | prev | next [-] |
| I feel like it’s a historical accident. In the past the platform couldn’t do it all, and if you wanted a dialog you had to use a library. Developers were trained to reach for libraries when they needed something like a dialog. Then react came along and all developed learning web development after react had little to no knowledge of the platform. They were taught that touching the DOM was a bad thing to do. That’s about it. Even now when I advocate for vanilla css I get the side eye and “tailwind and shadcn should be the default”. I get it, it’s what most people are familiar with, even if it’s worse than the platform. |
| |
| ▲ | corgi192 3 hours ago | parent [-] | | How is tailwind and shadcn worse than platform? It speeds up development by orders of magnitude. | | |
| ▲ | WuxiFingerHold 2 hours ago | parent [-] | | Depends on the criteria, e.g. if dev speed has highest prio, a full blown component lib like Material UI would be superior to shadcn. CSS can obviously do things that tailwind can't, so it is more powerful. | | |
| ▲ | tancop 39 minutes ago | parent [-] | | The point of shadcn is you can pull in a component and modify it any way you want. It's always going to be bare bones at the start. Something like MUI locks you into a layout and style that's coupled with the API, and you need to rewrite big chunks of your app if you want to add your own branding. For me the best middle ground is Headless UI or Bits for Svelte, unstyled and composable but you don't need to vendor code into your repo like shadcn. | | |
|
|
|
|
| ▲ | qurren 3 hours ago | parent | prev | next [-] |
| Because the platform sucks. I want a rounded button with a certain radius and a certain font, that feels squishy and satisfying when you press it, especially on mobile. |
|
| ▲ | eviks 39 minutes ago | parent | prev | next [-] |
| > The argument is simple: why build something yourself, in JavaScript, when the browser can do it for you? And when it becomes real, you've got yourself an argument |
|
| ▲ | techaqua 2 hours ago | parent | prev | next [-] |
| can the title be changed to "Why don't more developers use browser native features?" |
|
| ▲ | djmashko2 an hour ago | parent | prev | next [-] |
| There’s only one “the platform” but there were tons of competing libraries to do things like css, components, etc. The competitive landscape just produced better results. For me, Tailwind is nicer to use than regular CSS, and React is nicer to use than web components. |
|
| ▲ | JSR_FDED 3 hours ago | parent | prev | next [-] |
| It’s funny, the article proceeds to answer the question in great detail: familiarity, level of abstraction, documentation, etc. I agree with his point that learning to do it yourself can be fun and lead to a flywheel of improvement where the next time you’re faster and the next time faster still. In the past that was the recipe for success as a developer, nowadays with AI many feel that’s no longer the case. |
| |
| ▲ | sodapopcan 3 hours ago | parent [-] | | Extreme apathy towards "learn to do it yourself" is exactly why "AI" is so popular right in programming right now. |
|
|
| ▲ | satvikpendem 2 hours ago | parent | prev | next [-] |
| It's because frankly the platform has been historically shit. Web components comes to mind as someone else here has mentioned, as it's just not a good API and needs wrapping to make it usable, same as IndexedDB which the author readily admits as a creator of such tooling. It seems like the ones who determine the platform aren't actually developers day in and day out and thus don't dogfood their own products while the rest of us do, leading us to reinvent the wheel. Here is a great comment and discussion (scroll down) by Ian Hickson who wrote the HTML5 spec on how the platform has essentially failed on its promises causing everyone to write everything in JS or even other paradigms like Flutter and other WASM or canvas based frameworks that eschew the web entirely: https://news.ycombinator.com/item?id=34612696 |
|
| ▲ | onion2k 3 hours ago | parent | prev | next [-] |
| The last couple of websites I've made have been largely the output of Claude with some instructions to keep to WCAG AAA accessibility standards and to optimize for loading and rendering times, and it's done a pretty decent job. If you're insistent about page weight it will avoid adding JS and React and use to browser-native elements, CSS, and vanilla JS where it can. I think the problem is that you have to ask, and to know the language to get the result you're after. If you just ask for a pretty website you're getting 800KB of React libraries to render something, and all in AI Beige with Inter as your font choice. |
| |
| ▲ | user43928 25 minutes ago | parent [-] | | Do you really need to know the language or is it enough to bother asking about improving the loading time or customizing the look? |
|
|
| ▲ | charcircuit 3 hours ago | parent | prev | next [-] |
| Because the platform is too hard. The average person does not want to spend time figuring out how to get stuff to work. All the browser documentation is 1000 times nerdier than the average person wants. They want all this low level stuff abstracted away from them. Even if you want to do it the nerdy way and bust out a text editor and start writing some HTML tags it all looks ugly out of the box. Browsers pushed everything for making websites onto 3rd party devs, so they shouldn't be surprised when they want to use 3rd party dev's stuff over the bad and confusing 1st party ones. The browser developers are in an ivory tower building a product that doesn't really care about web developers and their needs. |
|
| ▲ | arules an hour ago | parent | prev | next [-] |
| I must say it was worth reading , thanks for sharing your insights !! |
|
| ▲ | zatkin 2 hours ago | parent | prev | next [-] |
| Is it just me or does it feel like Anthropic and OpenAI (and probably others) are pumping harness engineering and the like to try and convince engineering organizations, or even entire companies, to "use the platform", and not meddle with software anymore? |
|
| ▲ | slopinthebag 3 hours ago | parent | prev [-] |
| since the author brought up the native <dialog>, developers chose custom implementations of dialogs because they want better accessibility, better focus management, better mobile and touch screen reader support, and more flexibility. adobe's implementation is far more robust and flexible compared to the native dialog, and it's hard to justify "use the platform" when it results in a strictly worse end result. |
| |
| ▲ | uhoh-itsmaciek 3 hours ago | parent [-] | | Yeah, that was kind of ignored in the article and it's definitely an issue for some platform features. Date pickers are another one where it's easy to outgrow the native implementation. | | |
| ▲ | DangitBobby 3 hours ago | parent [-] | | I was excited about the native date picker and tried to use it once, only to discover that you couldn't (can't still, I assume) disable dates other than by setting min and max. Every native browser widget I've tried to use doesn't implement the features my clients expect, so I don't use them. People want a better web platform and the only way to get it is JavaScript. | | |
| ▲ | JimDabell 2 hours ago | parent | next [-] | | Yep. “We need a date picker to schedule a visit.” “Okay, use `<input type=date>`” “It needs to be a date in the future.” “No problem, add a `min="2026-10-05"` attribute.” “And we’re only available on weekdays.” “Okay, throw the native date picker away completely and build one yourself from scratch.” Did nobody involved ever bother to ask what the requirements were for a date picker? Excluding dates is one of the most common requirements there is! | | |
| ▲ | wvbdmp a minute ago | parent | next [-] | | Once upon a time, there was a golden age for devex, when “the platform”, i.e. Windows, was on-prem and Microsoft wanted everyone to be able to develop software for it and have it easy to set up and run. Thus, we got very nice toys like .NET and SQL Server, which is still the easiest, most batteries-included and hands-off database to this day. As much hate as Microsoft deservedly got and still gets, it’s hard to overstate what a miracle this alignment was. A corporation’s real, intrinsic, not just stated in marketing, but legitimate goals were to actually empower customers. When does that ever happen? Of course, this had its own misaligned incentives: Microsoft didn’t own the web, so they were only interested in improving it strictly on Windows, so they put proprietary shit in their browser. Everybody saw that this was bad and a big long struggle ensued and finally Firefox came out on top. But with the balance shifting in favor of the web, new incentive perversions arose. To sell cloud bullshit and lock people into their platforms, web companies obviously don’t want you to have a good time developing or hosting competing products, even just for yourself, so complexity exploded and any focus on developer and operations experience went out the window. They also don’t want anyone to be able to turn of Javascript or otherwise have much control via their “user agent”, so not only do they not care about advancing “progressive enhancement”, they’d probably prefer to get rid of it. As quickly as Firefox saved the day, one of these companies came out with their own browser, and everybody saw that this was going to be a bad idea, but they ran TV ads, so everybody switched regardless. Actually, developers were the first ones to switch, because they were promised cool new toys, lmao. We should have rejected clouds and we should have rejected Chrome and with some luck we could this day be living in a paradise of on-prem toys and be the princes of our orgs. Well, probably not, but still. | |
| ▲ | pwdisswordfishq 31 minutes ago | parent | prev [-] | | Does onchange → setCustomValidity not do the job? | | |
| ▲ | JimDabell 12 minutes ago | parent [-] | | That lets you bring up the picker, let the user pick any date, and then show an error message if they picked an unavailable one. It doesn’t let you show dates as unavailable in the picker or prevent the user from picking them. |
|
| |
| ▲ | otherme123 an hour ago | parent | prev [-] | | But also custom date pickers are the most broken thing you can find everywhere. Browse with a combination of browser/phone the developer didn't test, and you can't pick even the most basic single date. The most blatant are the fancy range pickers, instead of two date picker boxes: I have been pushed to a desktop browser because the mobile renders half of it off-screen, or don't hold open after tapping the start date, or works by dragging but breaks on single taps... |
|
|
|
