`appearance` has a lot of caveats on MDN about testing it thoroughly if you're going to use it—even `appearance: none`. This may matter less if you only have to support new browsers, but keep in mind that old versions of Safari stay in circulation longer than you might think.

`datalist` does nothing on Firefox Android. It just shows to me as an input box with no functionality at all (not even the suggestions over the keyboard that others report in Chrome Android).

The color picker is neat, but extremely nonstandard, which is a dealbreaker for most businesses not just because the designers will complain but because customer support will find it harder to help people. Chromium provides the functionality to pick on a page and pick literally any color, but Firefox Android only gives me the rainbow, a gray, and black and white.

The article itself acknowledges the inconsistencies with `details` and `dialog`.

I hope we eventually get to a place where browsers that don't support these features (and support them consistently with each other) are no longer used, but in the meantime these elements will only find their way into my side projects, where I have full control of which browsers I support.

When I press the button on my iPhone it brings up the actual system native color picker. It’s the same control that appears in dozens of apps because it’s provided by the OS.

I much prefer that over some bespoke thing.

The color picker control is the antithesis of this consistency: not only does it look different across platforms (making it harder for CS to walk customers through something over the phone), it provides different features depending on the platform. Some users will be able to pick an arbitrary hex code, some will be able to pick colors off the page, and still others will be given a tiny set of fixed choices.

HN's audience might prefer that because they know the platforms they use extremely well, but the average caller to a customer support desk doesn't know their own device that well. If we instead write a bespoke control, you (being technical) will be able to figure it out, and the people who call in to customer support for help will all be seeing essentially the same thing.

EDIT: And note that when I say "companies don't", I'm not even just talking about the SaaS vendor. Oftentimes the customer is also a business that has an internal support desk that prefers consistency.

Tell me you've never worked in tech support without telling me you've never worked in tech support.

My experience in a tech support center for a software company is that, for the kind of person who calls in to customer support, them having made a Google search first is not something that should ever be assumed. And usually whole offices were chronic customer support users or none of them were—peer support, when present, is already sufficient, and in the offices where everyone is clueless having a system-native color picker isn't going to fix it.

> On top of that docs/knowledge would be more standardised.

If everyone started using the native widgets at once, then maybe external docs would be more helpful, but until that happens your software-specific documentation becomes much harder.

How do you take screenshots of the color picking flow for your documentation? If you just pick a browser to screenshot then you will get calls from people using a different browser who are confused that it looks different for them. If you screenshot every supported browser then your documentation becomes much more expensive to create and maintain.

I once had a problem with my laptop, which was a problem with the drive. I pulled it out and duplicated the problem on a different laptop, so I needed to get a replacement. I kept mum and went through all the steps I was instructed to (reboot with this or that key held down, etc) until finally support said “well sorry, we’ll have send you a box for you to send back the laptop”. It would have been useless and annoying to the person on the other end of the phone to dry to skip all that. Like doctors, they must deal with a lot of people who studied at the university of Google and think they know it all.

I have a few times sent in bug reports on software I had previously worked on myself. Again, just file it like any other bug. Usually the bug just gets fixed (or not) but I did once get mail from a former colleague who said he was assigned my bug and how the hell was I? Sadly he also told me, “we aren’t going to fix it.” :-/

Of course most of the time I don't know any more than the next schlub. Otherwise I wouldn't have called.

I've actually had pretty good success with this strategy, though it really depends on the company. Framework laptops and system76 for example were both phenomenal with this approach. The first reply I got from them was either an engineer or someone who talked to one, or someone very experienced in CS who would be a good candidate for engineering.

Worst case if the CS person has no idea what I'm talking about, then we start from scratch but at least they know I'm not a dumbass they can BS :-)

Also iOS tends to be way more consistent than android, windows, etc, so there could be a case for iOS native and 'company consistent' for everything else, especially if you're in the USA. iOS people pay more and it could be worth it to have two branches for customer support if it leads to total better conversions and thus more profits. Your business's core competency is not making UI toolkits, it's selling whatever your making. Leverage the literal billions of dollars apple and google invest into the core UX toolkits.

This is something humanity can solve once and for all then be done with it.

Implementing your own will have bugs and generate a lot more support. The dialog I get on my iPhone is magnitudes better than any other home baked pickers I’ve seen.

Date pickers on the other hand I agree are more complicated to standardize, due to frequent need of overlaying extra data, like price, together with the dates.

So they should use the exact same OS and they'll have the same color picker everywhere, native to that OS. Problem solved.

> Oftentimes the customer is also a business that has an internal support desk

Maybe I misunderstood something, but if it's a business with internal support desk, surely if they want consistency they want it everywhere, including the work machines (BYOD aside) they provision?

How would that work if the app had to work on both desktop and mobile?

And, how easy would it be to make sure all users were using the same model and make of mobile device?

You could write a website that doesn’t use JavaScript, is meant to be accessed primarily through curl, etc but if it’s a business project then you’re going to end up with a product that your users (average people) will view as more janky than otherwise, and you’ll spend more time and money on it too, for the benefit of 0.01% of the population who would be slightly inconvenienced if you didn’t.

The Unreasonable Effectiveness of Simple HTML:

https://shkspr.mobi/blog/2021/01/the-unreasonable-effectiven...

Are any companies foolish enough to assume otherwise? I understand there is a minuscule number of users who don't want to run JS in their browsers, but aside form Amazon and their near-unlimited resources, who is catering to that small number of users?

For features that have been very widespread for enough time, it's okay to have a javascript polyfill as the only fallback, in general.

This is a big one. At a past job we actively discussed this and instead decided to use JS over things like datalist due to it potentially increasing the CS burden. Datalist specifically was tried, but the inconsistent results meant it had to go.

We eventually ceased support for all browsers but Chrome as well due to the inconsistencies.

No amount of polyfill or other JS can save JS when JS cannot JS. It's terrible for accessibility unless it "works" to start and in that case your point is moot.

The company I work for has JS app that is resilient against the missing-content problem you refer to. It is also more accessible than any other web app I've ever seen in my life. There's nothing about JS that breaks screen readers: you just... generate the right HTML with the right attributes.

The problems you see with JS apps that don't work are apps written by people who don't care about their app working and don't care about accessibility. That's orthogonal to whether a JS app maintained by a competent team can have better cross-browser compatibility than one (by the same team) that leans entirely on new HTML and CSS features.

If your site is popular over Tor — that is, if it's used for warez or by whistleblowers and journalists who need to browse privately — this may be good advice. If it's not, people who disable a core aspect of the browsing stack are savvy enough to enable JavaScript on a site-by-site basis when necessary.

Well there's our difficulty communicating. I'm talking about all web sites, not just applications that happen to be run in a browser. A regular HTML page with text in it is far more accessible than any application depending on execution could ever be. Web applications can, in very rare cases be made accessible (assuming you have perfect execution and JS feature support in the browser). But actual web pages always are. 99% of the time if you can do it with just HTML and text/images you should.

* Switches

* Autocomplete input fields

* Color pickers

* Accordions

* Modals

The accordion is arguably applicable to both, but with all the others it's pretty clear that TFA is about web apps, not content-heavy web pages.

Sadly, the article itself is of no use and only a rant, since the “you” in “you don’t need” is not defined.

Have fun checking for mobile, tablet, desktop, Android, Apple, Chrome, Firefox.

It is not that developers rejoice over creating controls all the time. There is still html and css involved.

But now that I’m saying this, I think an attribute for script tags that only load if the browser doesn’t support feature X (or any feature in a set, so you can roll up polyfills that tend to be needed together.

That could be backward compatible because existing browsers would just load everything, and new ones could negotiate.

The standard behavior of "render unknown elements as if they were a div" isn't viable for more complex elements that aren't just content holders. Alternatives that involve developers specifically coding a backup component are more expensive than just writing a bespoke component in the first place.

What sort of graceful decay are you imagining for these cases where a whole widget is missing or is implemented differently across browsers?

I see the options in the keyboard [0], in the place where autocorrect suggestions appear. But that's the first time I have EVER seen that in a mobile web UI for a page's form control (aside from password auto-fill apps that use that same space).

I don't hate it -- it's actually much nicer than trying to awkwardly scroll a poorly built custom JS drop-down. But I have no confidence that all normal users would figure out how to use it. So I think it's DOA for mobile.

Also, it is flat-out not supported on Firefox Android [1].

[0] https://imgur.com/a/Ecb4503

[1] https://caniuse.com/?search=datalist

Also: https://adrianroselli.com/2023/06/under-engineered-comboboxe...

JavaScript is pretty well standardized, html and CSS is less so.

Here is an example of JavaScript-free CSS motion:

https://egbert.net/blog/index.html

Also, datalists still need JS in some cases like when a default value is set. I have the workarounds and browser quirk notes here in the (to-be-launched) new LibreOffice website code: https://git.libreoffice.org/infra/libreofficeorg/+/835a5cc59...

Good news is that a Firefox dev plans to look into improving datalist behaviour, so only a single click would be enough to display the list.

For me it shows the options above the keyboard where normally word suggestions are shown.

But please limit how you use this; it’s not actually a good idea most of the time you might think of using it, and often has undesirable side-effects.

> Native carousels with scroll-snap,

But carousels are still a bad idea, so scroll-snap is of extremely limited legitimate application.

> Scroll driven animations

Pages that do this are normally improved by removing it.

Smooth scrolling is a great example. The native API allows a user to interrupt at any point. Most JS implementations are janky as all hell and users suffer.

Scold design choices all you like but don’t expect to be listened to. Especially when you’re not providing any actual reasons why “carousels are still a bad idea”.

It’s widely understood and documented that carousels are a bad idea, and plenty has been written about it.

(I should clarify that the problems are with carousels as a way of presenting diverse widgets; as a way of presenting a collection of pictures about a single item, it can be acceptable.)

If your goal is user friendliness, it would behoove you to use a design which is user friendly.

Using a design which is user unfriendly and asking "how can I make this unfriendly design seem friendly" seems to be approaching the problem from the wrong direction: the design choice itself is the biggest contributor to user friendliness.

Either you care more about yourself and your design choices than user friendliness, or vice versa, and both are totally valid options, but don't pick the former and claim the latter.

I too dislike carousels… But at the same time the Amazon homepage prominently features a carousel, and I know that Amazon ruthlessly A/B tests homepage variants so the carousel presumably tests well… so I’m not sure that they’re actually “bad” in some sort of universal objective way.

1. Maybe you didn't like it so returned it, but are still in the market.

2. Maybe it was a gift and you now want one yourself (or vice versa)

For something relatively expensive it may be the best expected value add even if the chance of repurchase is only 1%. Maybe the repurchase rate is 1% while the base purchase rate is 0.1%.

I'm not sure it is, but it seems entirely possible that this is actually a smart move by the ad engine.

No, it doesn't. It tests which one is more positive, not which is is positive.

> Like the A/B test that repeatedly demonstrated that after you buy a blender, your most likely purchase is another blender... (which Amazon still hasn't fixed nearly a decade later)

That isn't an A/B test.

"positive" in the sense of "always answering questions with 'yes'", not in the sense of "positive numbers". Turns out when you start linking people's compensation to their datascience results, the results start to lean in whatever direction optimises for compensation...

> That isn't an A/B test.

A series of A/B tests. All the alternatives failed to produce better metrics than the status quo, so everyone became satisfied that their local minima was optimal

An attempt was made to tackle this once and for all with XForms, but it never got implemented in browsers. Instead we have virtually all CSS/JS component frameworks provide their own limited set of form elements with different semantics.

I'm too young to know what happened or why. By the time I got my first engineering job, JSON was the standard choice for "stuff you need to serialize."

I feel like YAML has also become the default choice in several areas where XML would be flat-out better.

The benefits mentioned above are due to schemas, and not the serialization format or tool scope, all of which could be improved independently.

But even if an excellent combo dropped from the sky getting everyone to use it would be very hard due to inertia.

That said, some folks with demanding needs use protocol buffers or thrift, etc. And have for a while.

I'm not advocating for universal XML use, nor am I advocating for universal JSON use. I'm advocating for standing back and asking yourself "what am I trying to accomplish?" then choosing the right tool for the job.

As for protobuf: I've seen entire companies built on it. It's amazing what your engineers can do when they don't spend half their time twiddling bits or arguing about data formats. It's a godsend for embedded developers (like me), because JSON, XML, et al are non-starters in that space.

Others won’t even try to edit xml/json and constitute the great majority of humans.

json is better but the lack of trailing commas dooms it as a more general format.

XSLT is powerful but harder to get right than just reshaping JSON.

It is. You throw it in React and get on with your life. It's only "not solved" because some people have a bizarre fetish for avoiding JavaScript and will find any excuse to wedge in their half-baked alternatives.

This isn't some "bizarre fetish," it's an issue with implications from performance to code organization to legal compliance. (No, seriously -- Domino's had to deal with an ADA suit a few years ago because their app dispensed with standard elements with default behaviors, like <button>s, in favor of unlabeled <div>s that had effectively no compatibility with screen readers.)

This is a core component of a lot of problems with modern webdev.

Framework fatigue? Yeah, because UI toolkits frequently reimplement basic structural elements, in their own specific dialects.

Bloated codebase full of external dependencies, that only works well on fast internet connections? Well, look at all the overdependence on third-party libs, or even or even hand-rolled behaviors in JavaScript taking up dev time, for implementations of things that browsers support natively now.

Messy codebase that needs a CSS class for every element, or even style declarations within the CSS classes themselves? You can do less of that if you use semantic elements and modern language features -- because then you can write unique selectors without having to explicitly name everything.

I'm not saying that it's without its own problems -- obviously different orgs will require different levels of support for older browsers, for one thing -- but there's a reasonable argument to be made that the current ecosystem overcomplicates this a lot, and that relative to using the platform, sometimes all the extraneous dependencies are the half-baked alternatives.

Use of JavaScript has approximately zero correlation with website accessibility. If anything, sticking with a mainstream framework makes you more likely to meet accessibility requirements, not less.

> Bloated codebase full of external dependencies, that only works well on fast internet connections? Well, look at all the overdependence on third-party libs, or even or even hand-rolled behaviors in JavaScript taking up dev time, for implementations of things that browsers support natively now.

If your concern is dev time then third-party libs are a great thing, and trusting the library generally means less test burden than trying to figure out what each browser supports at the moment and whether that fits with your support matrix. If your concern is performance, you have to actually measure it - often JavaScript performs better than the native browser implementation of a feature.

> Messy codebase that needs a CSS class for every element, or even style declarations within the CSS classes themselves? You can do less of that if you use semantic elements and modern language features -- because then you can write unique selectors without having to explicitly name everything.

CSS selectors are far more messy than using a CSS class for every element. CSS is a tarpit where everything almost but not quite works, minimising your interaction with it is the only way to stay sane and keep your codebase maintainable.

Intent is not something you can work out programmatically, so we can’t have nice things in some situations.

The last fancy form I worked on, I had to make sure the click event fired the form submit fairly directly so the browser would allow it.

Do you know if there are other ways to hide but allow search?

I agree with most of these (I haven't played with dialog enough to have an opinion) but datalist is not a valid choice IMHO unless it's an internal tool. It's ugly, limited in what you can do, and not style-able. This is the problem with a lot of the "just use the built-ins" (looking at you date picker), not only are the defaults not great but you can't change them even if you want to. As soon as you hit one of the many brick walls when it comes to styling or changing behavior (Oh you want the week to start on Monday? Too bad) then your only choice often is to reach for a full replacement library that, yes, uses JS.

I'm all for using the lighter-weight options and agree with HTML > CSS > JS hierarchy but sometimes JS is the only answer if you want to make your UI look nice and have the features you want.

“Hey Boss, I know this looks like shit today and is missing a ton of features but maybe one day we can enhance it”

That wouldn’t fly and since I make components to wrap just about anything we use (third party or custom implementations) so I’m not beholden to it, I can always rewrite that component to use data list (or whatever built-in) if and when it grows up. Also some code gets written once and practically never touched again so my chances to go back and enhance data list as browsers progress is kind of a fairy tale, at least at all the companies I’ve worked at,

Not using native as-is.

For the start day of the week (and most suggested customizations of input[type=date]), it's a good thing that this is outside of your control. The appropriate calendar to display should be locale-dependent. The user's platform already has capabilities to configure and display this is a way most likely for the user to be able to effectively use.

The platform's date picker is better than whatever weird thing you custom built.

That would also require browser creators to be consistent in implementation

& you still have the "relying on people to update things" problem where it could be years after a new feature is introduced until it's widely enough supported to be useful

I do tend to agree there are plenty of poor implementations and convoluted JavaScript contraptions. Afaik there's plenty of standardized solutions to keep back button functionality with dynamic content and afaik the popular web frameworks support that out of the box.

Are they actually seething? I've read the top comments on this post and don't see much that I'd describe as seething, just some people who bring up valid points about browser support.

Also two separate times in the last year I've had to help a team that's using traditional MVC with no JS at all, and now they have a feature that can only be done with JS. But they have an entire dev team and no one knows JS at all. They don't even know where to start, so they're calling me in to help them retrofit it in at great expense. It would have been cheaper to just use JS from the start, and they have to pay for that mistake.

Sadly this is lost on a lot of folks here. We're not using JS out of ignorance, we're using it out of necessity. We don't build react front ends for CRUD because it's inherently better to browse with curl, we do it because it's currently the most effective way to meet the needs of the business. The goals of the business rarely align with the goals of opinionated technologists, but that hardly is grounds for the level of scorn I see from that crowd.

1. https://daisyui.com/components/drawer/

2. https://daisyui.com/components/carousel/

For the people down voting: Drawers and other content that appear on the page needs to be announced and needs to have a state aria-expanded next to the controlledby.

This is still a genuine question. Maybe there is a way, or maybe developers collectively think that's not important (our auditors would disagree but, anyway).

I really wish component providers would start explicitly documenting this. My dream is to find a component library where each component is accompanied by videos showing how each thing behaves in different accessibility tools.

It's as if authors of these frameworks severely underestimate the amount of testing required to make these things actually work across browsers. Once you have that many (themeable, no less!) components, all bets are off you'll still able to fix it without breaking existing themes and applications.

Point I am trying to make is: learn all the nitty gritty about CSS (specificity, box layout, selectors, etc...) and really understand how the base language works. Then go play with frameworks, figure out which ones fixes the parts you don't like, and makes the parts you do like better.

I remember that dropdowns work a lot better now. Do you remember which components you had issues with?

This is new to me: What on earth is "snap" and how is it done? My screen certainly does not react to finger clicks.

(Btw, I don't think that unknown methods for interaction is an especially good recommendation of an user interface element library)

> It's one of the core principles of web development and it means that you should Choose the least powerful language suitable for a given purpose.

> On the web this means preferring HTML over CSS, and then CSS over JS.

Ah I totally do this, I never though to put a name to it besides taking the ‘minimal’ approach - if you can do it with just HTML, then by all means, just mark up some content and be done with it.

I will make an important nit. Keep in mind this is a nit. It's text in bold in the page, but this is NOT an attack on anything else in the article, which describes good design practices.

There is no principle that one should "Choose the least powerful language suitable for a given purpose."

This would, in fact, be an incredibly stupid principle. One want the most powerful language for any purpose. However, "purpose" is broadly defined:

1) We want code to be semantic. This allows a11y tools, search engines, and various performance optimizations to understand what's going on.

2) We want clean abstractions. In a horizontally-abstracted system, we would like the content designer to be focused on the content, the UX designed to be able to focus on the UX, and the back-end engineer to be focused on the back-end. (Note that, contrary to the beliefs of most people who have only worked on database-backed web applications, vertical abstractions are okay too, and break things up completely differently).

3) We want systems to be bug-free and understandable.

This can leads to programming paradigms like functional programming + React, where no mutation is allowed. This isn't a random restriction which reduces power; to the contrary, it increases power by allowing predictable state, avoiding a whole class of bugs, and allowing debugging with time travel.

In other words, you want good design discipline. However, the point here is much more on "good design" and not "discipline."

Every one of the changes proposed can be derived from first principles from the above. But this does not come from some principle of "least power."

To make this even simpler: Think of diet discipline. The goal isn't discipline about being hungry and eating yucky food. The point is about being healthy and losing weight. That probably involves being hungry and eating yucky food, but that's not the point. Food should be as tasty as possible and people should not be hungry to the extent goals on weight, heart health, insulin resistance, etc. can be accomplished.

Same thing here. Languages should be as powerful as possible, while allowing goals around readability, introspection, a11y, abstraction, etc. to be accomplished. That requires very specific and narrow constraints on what one bans.

This is mistaken. https://en.wikipedia.org/wiki/Rule_of_least_power

In my career there are two types of software projects. Ones that start off using a powerful language and libraries, and those that don’t because “this is just a prototype/small project”. 9 times out of 10 the second type naturally evolves into something more complex and requirements become harder to solve with some “least powerful” language. Inevitably a costly migration is made to a more powerful toolset, be that react, Spring, or whatever.

I think it’s a bit different in infrastructure where the core of what you want is a declarative set of requirements and properties. But in SWE you’re a fool to start your project with the least powerful tools.

If what you need is a configuration language, please don't express it in Python. If what you need is a regular expression matcher, please don't express it in a bespoke recursive-descent parser written in the enclosing language. If what you need is a SELECT over a large dataset, don't download all rows from the DB and then iterate/filter them on the local host.

I think there are many reasons for this, not just for human readability -- also for performance and security. Berners-Lee is quoted in that wiki article as saying it helps semantic extraction, too, but I personally consider that less convincing.

EDIT: automistake/grammar

Oh god please express it in Python more so than anything else. The configuration language file -> templating the configuration language file -> scripting the templates to the configuration language file pipeline has to die.

If you're going to use the simplest thing possible make it easy to throw away when the nerds get more complex instead of having to build the complexity on top. Regex is a great example -- if used internally when you need something more you just throw it away. But if you make a single static regex part of your configuration your users are stuck with it.

Ironic but true. How often is it actually the needs getting more complex, and how often is it the nerds wanting to make it more complex so they can try out some new tech?

I believe "power" in this context describes the amount of freedom the language allows. The less powerful the system is, the better you can reason about it and the more external tooling you can add around it without breaking corner cases. A webpage is less powerful than a .exe running on your system, but that is what makes it so useful - you can run it at 144 fps, use it with a screenreader, custom CSS, high DPI (even if the webpage was written in the 90s), etc. and all of this relies on the lack of power of the webpage.

If html can reasonably do X then it's probably better at doing X than doing it js. If that rule of thumb isn't true then there's no point for js to exist at all, it would mean js is strictly better in all scenarios.

If you're using Deno and run into the limitations of the JavaScript language/ecosystem, you use its FFI to call out to libraries written in languages like C and C++.

Similarly you might address a performance issue in your C code by writing assembly code, which is the most powerful language essentially by definition, and which of course has plenty of downsides.

It's not mistaken to disagree with the principle, but that's not what the comment you replied to was doing.

I was mistaken. I appreciated the correction. It was helpful. The language "This is mistaken" was correct, and I took no offense to either being mistaken or being called on it by MaxBarraclough. That was a helpful comment, and it's valuable when people call out mistakes.

There is such a principle. I didn't know about that framing. Now I do. Yay!

I don't even disagree with the principle. I disagree with the one-liner summary of the principle, as well as the longer summary in the blog post. The principle should be stated in terms of specific design disciplines:

* Declarative > imperative, when you don't need imperative

* Functional > structured, when you don't need mutations

Etc.

On the topic of conversations: I know this wasn't done here, but I don't even mind having my code, comments, or emails called stupid. They often are (yours are too -- aimed at whomever might be reading this -- everyone does stupid things and makes mistakes). I only mind if there's a personal subtext. Although that's not common, high-performing engineering cultures are able to discuss things people do with strong language, and having that not be judgmental of the people themselves. That's a difficult skill and culture to develop, but it's super-nice to be in one if you can get there. You can share things early (when there is a lot of stupid), learn a lot, get a lot of feedback, and give a lot of feedback.

Everyone does stupid things, and organizations work better when those are caught and corrected early, when it feeds into learning (and, as prerequisite, when it doesn't feed into ego or performance management).

I also agree that sometimes it's a mistake to use a language that may later turn out not to be powerful enough. Consider ugly build-system languages that were once fully declarative but had to evolve imperative features to cope with difficult cases. They would have been better off using something like Python from the start.

It's not simply about choosing less powerful things over more powerful ones. It's about exactly what I wrote. I'll paste the whole definition:

"In choosing computer languages, there are classes of program which range from the plainly descriptive (such as Dublin Core metadata, or the content of most databases, or HTML) though logical languages of limited power (such as access control lists, or conneg content negotiation) which include limited propositional logic, though declarative languages which verge on the Turing Complete (Postscript is, but PDF isn't, I am told) through those which are in fact Turing Complete though one is led not to use them that way (XSLT, SQL) to those which are unashamedly procedural (Java, C).

The choice of language is a common design choice. The low power end of the scale is typically simpler to design, implement and use, but the high power end of the scale has all the attraction of being an open-ended hook into which anything can be placed: a door to uses bounded only by the imagination of the programmer.

Computer Science in the 1960s to 80s spent a lot of effort making languages which were as powerful as possible. Nowadays we have to appreciate the reasons for picking not the most powerful solution but the least powerful. The reason for this is that the less powerful the language, the more you can do with the data stored in that language. If you write it in a simple declarative from, anyone can write a program to analyze it in many ways. The Semantic Web is an attempt, largely, to map large quantities of existing data onto a common language so that the data can be analyzed in ways never dreamed of by its creators. If, for example, a web page with weather data has RDF describing that data, a user can retrieve it as a table, perhaps average it, plot it, deduce things from it in combination with other information. At the other end of the scale is the weather information portrayed by the cunning Java applet. While this might allow a very cool user interface, it cannot be analyzed at all. The search engine finding the page will have no idea of what the data is or what it is about. This the only way to find out what a Java applet means is to set it running in front of a person.

I hope that is a good enough explanation of this principle. There are millions of examples of the choice. I chose HTML not to be a programming language because I wanted different programs to do different things with it: present it differently, extract tables of contents, index it, and so on."

The name of the principle is ill-chosen, since it's designed to be provocative rather than informative, and therefore can lead the reader astray. The central core is actually about: "The reason for this is that the less powerful the language" in the specific ways articulated "the more you can do with the data stored in that language."

Having just finished a pure JS + Petit Vue project the creativity and fun came back for me, while highlighting some important parts of the larger ecosystems.

I'm still anti the newer frameworks though - and i think most are like me because of the ridiculous complexity these days, the sweetspot for me was around Vue 2, Angular 1.

The newer frameworks just have too much "magic" going on, way too many files, dependencies, ever changing tooling, and no one seems to understand even small parts of it fully. It becomes about reading manuals and following conventions, instead of being creative and getting things done.

Sharing simple data from one div/component to another is a good example of too much complexity; from 1 minute sharing across your app/teams through window.sharedObj, to 40 intermediate steps, 100 files, 100 imports, stores, 10 dependencies, .value.value.data.data, and extremely long nonsensical errors when your data has stranded somewhere.

Either that or they don't have nearly enough magic to separate the developer from all of the paradigms of the web, so they can apply their own idea with any clarity.

But yeah, they sit there, at just about the worst possible spot. One can improve them by going either way.

But it's the exact opposite? At least if we're talking Vue 3, literally everything about it is less complex than Vue 2 was, especially with Vite. You're telling me that Webpack is less complex than Vite? At my work our 1 Million+ LOC Vue app the Vite config is like 40 lines for Prod, Staging & local dev each, and every single line of the config is dead obvious without even needing to check the docs, especially when you compare it to the monstrosity that Webpack setups usually end up looking like. Plus there's the insane speed at which even gigantic projects get built, whereas Webpack can easily take 100x the time. Hell, even HMR would take around 15 seconds on an uber powerful machine before we made the switch to Vite, where it now takes ~500ms.

Sure, there's a small bit of adaptation to be made with refs and calling `.value` outside of templates, but once you grok it it's actually a lot more logical than the magical `this.` you'd see everywhere in Vue 2, since `this` can refer to a LOT of things at any given moment, and it's never 100% clear what it is.

> Sharing simple data from one div/component to another is a good example of too much complexity; from 1 minute sharing across your app/teams through window.sharedObj, to 40 intermediate steps, 100 files, 100 imports, stores, 10 dependencies, .value.value.data.data, and extremely long nonsensical errors when your data has stranded somewhere.

Again, this is the complete opposite to my experience with Vue 3. In Vue 2 you had to deal with Vuex and the weird getter/mutation/state stuff, whereas with Pinia you just set some state as an object, and you can directly manipulate that state wherever you want, even with excellent devtool support.

And I definitely wouldn't call sticking all your state into a random `window.` object less complex than using something like Pinia, if that's your idea of less complex then I'm happy to not be working on the same codebase as you. I'd rather you not be creative with state management like that, cause every time I've ever had to deal with some monstrosity of an untyped `window.GodObject` I've wanted to throw my laptop against the wall.

Not to mention that if you opt for TS (which is like a single line in the Vite config), it's WAY more productive than Vue 2 since you now have properly typed emits and props and can actually have an overview of what data is flowing where. Plus CompAPI in general is just objectively less boilerplate and less code than the old Options API. An identical component will have much less code in 3 vs 2, especially complex ones, and ESPECIALLY once you start talking about mixins.

Also, passing props hasn't changed between Vue 2 & 3. You still just pass it in the template via `:myProp="myProp"`, all the same caveats as before still apply, except now it has proper type hinting that your IDE can help out with without having to scan the file itself. If you wanna avoid prop drilling (passing data from a parent to a deeply nested grandchild component), then provide/inject (also typed) or just Pinia (which again, is dead simple in comparison to Vuex or heaven forbid some monstrosity of a `window` object) is there to help.

The Vue 3 docs are also the best I've ever had to work with, and if you read through it just a single time you'll have an extremely clear understanding of how the framework actually works. No guesswork needed, and they always outline drawbacks as well as how to work around those drawbacks.

If you just care about sites that are document based, of course you’d prefer the static content stuff! But he wouldn’t be working on a project you’d be visiting anyway, so who cares if you stop visiting?

I was a frontend dev for a few years but I was stuck at the fringes because I wanted to do things as simply as possible. I always wondered if there existed some secret island of "least javascript possible" front enders, but all I found were "create react app is great, but do you know what would be even better? a tool on top of that to help us!".

https://www.codepel.com/demo/css-carousel-slider-without-jav...

there's an other comment posting a tailwind version , and I thought having a raw version would be helpful too

that's the issue with raw things, as you don't need any library, they are not marketed and it's really hard to find them when libraries take all the first results

for the "it broke the back button" isn't because it uses anchor so it works as expected for anchor , i.e you get to the previous anchor before going back ? (Which can be overrided by a line of javascript if you dont want that behaviour, but at least you can link to a specific slide of the caroussel )

Just because you use an anchor tag, and anchor tags add to page history, doesn't automatically make it "working as expected". It's unexpected behavior for the user.

My point is its different from "it broke the back button" , when you use the table of content links in wikipedia they have the same behaviour and you don't go that it broke the back button

In my experience, managers will complain but the users don't actually care and just want something that works.

Dialog was rushed in without fixing many problems it has because Chrome (and apparently other browser, too) want to remove prompt/confirm/alert.

The custom-styled switch doesn’t work on iOS Safari. It certainly can work without JS, but this kind of mistake is potentially informative in evaluating whether it should.

That’s not to say “if you want a custom-styled switch, JS is a better way to achieve that.” But if you’re already starting from the premise that HTML has a functional equivalent, it’s okay to use that for the default behavior and enhance it with JS to ensure it’s interactive when it’s enhanced with CSS to satisfy a non-standard design.

It seems on Firefox, focus-visible only appears when tabbing, not when using the space key to toggle. Not sure why that is.

I have some complaints about how Firefox handles these features, though. Closing modal dialogs with the escape key doesn't seem to work, even though it's described in the docs on MDN [0]. It does work in Chromium.

Also, the native color picker in Firefox is really weird: The Custom/+ button triggers on mousedown, which feels surprising and disconcerting as a user.

[0] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di...

In my mind there's a hard separation between website and web app.

If you're just a site, you don't need JS and should only use it for progressive enhancement.

Web apps I have no problem throwing a "You need JS to use this app" error.

Use the right tool for the job. JS is an awesome hammer, but it sucks as a screwdriver.

That's one of the core principles of web development? Why? I'm prepared to be embarrassed, like a "senior dev" who asks "uh, what's polymorphism?" but... I've never heard this "core principle" before and I've been doing web applications since DHTML displaced java applets.

- input type="checkbox" - It would be nice if this wasn't so janky to have a different look / function to your checkbox. Like some secondary type you could just apply, such as: subtype="toggle" or subtype="tristate" or subtype="cycle" Its weird you have to hide all the normal elements and then intercept all their functionality.

- HTML "dialog" - I like the element, because of "dialog::backdrop", since applying effects to the background for a dialog helps with UI focus. "backdrop-filter: blur(4px)" is also pretty cool.

It would also be nice if it "actually" behaved like a div. Tried implementing it on a project [1] with UI popups, and found out it displays different for show() and showModal() [kinda weird], and also has a massive hidden margin.

Apparently "backdrop-filter" can be implemented on normal divs though, so gonna try that approach.

[1] http://forsako.rf.gd/AmericanCities/LibOfCongressGame.html

The point is that a person reading system logic shouldn't need to be distracted by layout, and a person worried about styling shouldn't need to think about code.

Whether that matters depends on the specific system and the types of abstractions used, but it can be very important to making code maintainable, and in some cases, org structures practical (where the team maintaining the CSS might not be the same as the team maintaining the system logic).

Is it possible to use one for the other? Of course.

There’s no “right place”.

It’s a web browser. You program it in whatever way you like that you enjoy that makes sense to you.

Use whatever approach you need to get the job done. Mix and match. Come up with new ways. Do it simple. Do it sophisticated. Combine JS and CSS. It’s all valid.

Don’t listen to people who try to tell you how to program.

This worked for me:

* DO listen to people who tell you how to program

* Listen to many types of them (Microsoft programmers, functional programmers, Unix systems wizards, digital logic designers, UX designers, etc.)

* Do what they tell you for at least long enough to understand why they're telling you what they're telling you to do. This requires a very open mind. A Unix programmer stepping into a Microsoft shop or vice-versa will find many things which go against their most core values.

* Understand the underlying, fundamental, first principles their best practices derive from (keeping in mind some of those first principles are incorrect -- especially within the Microsoft community), and different ways people have figured out how to structure code, the upsides and downsides of each, and how they mix-and-match.

* From then on, program from first principles when you have time, from best practices when you don't, and quick-and-dirty hacks when you really don't, or are just having fun.

Yeah that’s showing an incomplete understanding of web application development.

I never really got my head around the correct way to think in CSS.

I am at the "I can see numerous ways of doing this" but I never really know the standard or best way to do it. It was the same when I started doing web dev / Django stuff, whereas now, with years of experience, I do know the best way to approach a problem, to keep code minimal and clean and readable.

(If anyone can suggest some tutorials that get me past that stag with CSS I would grateful).

... But the trade-off is lack of control, and that can be a problem. The author notes, but I think under emphasizes, that the color picker, for example, has no standard on how it should be implemented and so browsers are free to choose. The Safari color picker, in particular, is so bad that color picking is the one thing I recommend people absolutely roll a custom widget for, unfortunately.

And, in general, if you go this approach you are trading off needing to care and feed for your own widget solution with needing at least a passing understanding of how the browser-implemented widget will operate in every browser that your team will choose to support actively. And the implementation spec for browser widgets is far more open-ended then the constraints placed upon a JavaScript implemented widget with assets you have created from scratch.

What's bad about it? Can't test it on desktop right now, but on iOS it opens all the bells and whistles, including the "pick color from anywhere on the page".

What used to be horrible across all browsers is the date picker: tiny buttons, tiny numbers etc.

This is actually a bit better than the picker implementations in other browsers because it gives the user a chance to use any colors they’ve saved in the system picker, as well as any color picker plugins the user may have installed.

And there's no language in the declarative API to, for example, start the user on the Mac OS system color picker.

Frankly, JS for an open source project used by thousands of users is a nightmare. This was a reason we have done our best to remove it and provide much more stable uses through yaml that then is used to construct the correct html rather than the spaghetti of JS from before.

I’ve come to view JS with a lot of skepticism the older I’ve become. People are free to use it, but I do hope web assembly gives more choice in this monopoly, which I believe is the only reason people fundamentally use JS, though they will invent many reasons why “it’s great!”

My experience over the years has been that the language and tech stack matter much less than the discipline of the team. Rewrites always feel like a huge improvement for the first few months, but as time wears on they become just as convoluted and bloated, either because the domain is inherently complex or because the team thought that the old tooling was to blame for their own poor coding discipline.

I find it particularly interesting that YAML of all things is what you've turned to as an improvement. You'll find plenty of people on HN and elsewhere who've learned to avoid YAML like the plague because of bad experiences with it, so it seems clear that it's not objectively a better choice than JS for avoiding spaghetti.

I hesitated posting just because I had a feeling this would not make sense. The project is for super computers and so it’s niche for the admins since they are overburdened at their centers and don’t have time or sometimes the expertise to role their own JavaScript to do advanced things with a form that is then used on the backend to submit jobs to clusters and apps on HPC systems.

But this is a niche. My perception of the web dev space is it’s a mess and often has endless debates that do nothing for users, and much of the mess and debate centers around JS, a language that is the only choice (a monopoly) which then claims to be a great choice (how is that choice? Seriously, I’ve never understood that statement).

No. Choose what you like, what you enjoy, or what the boss told you to use. Ideally the project defines prioritize that give guidance. Otherwise do what feels right.

Don’t follow some arbitrary doctrine.

>> Choose the least powerful language suitable for a given purpose.

(Don't make me needlessly enable JavaScript to use your site.)

Rubbish. Web technologies are way too sophisticated to boil down to some silly rule of thumb that “the least powerful technologies are the” best in some way.

As a professional developer, use every technology at your disposal and use it in whatever way you like, including the most advanced techniques.

Ridiculous to be given the most one of the most powerful development tools ever made - the web browser - and artificially constrain how you use it for some dogma.

And if you’re a junior developer, ignore people who tell you how you should program - do it how you like unless the boss says different.

The walkthrough in the article seems to demonstrate pretty effectively that the powerful development tools offered by a modern browser may obviate the need for elaborate frameworks in many cases.

Where this is the case, then, relying a framework instead of the tools the browser already provides artificially constrains an application, potentially for dogmatic reasons, and regardless of a developer’s level of advancement.

Browsers have rapidly come a long way even just in recent years. Frameworks well and truly have a place, but narrowly relying on frameworks, particularly out of beliefs about browser capability established years ago (like when React was introduced), can neglect browser-native functionality that can provide same-or-better results, with potentially better outcomes in performance, accessibility, maintainability, and more.

This qualifier probably applies to >90% of this website’s audience, so I don’t think it’s useful.

Using less power if you can get away with it is absolutely sensible. If my implementation is suitably robust without the use of type families, data kinds, singletons, lenses, etc., then that’s a more economic solution.

A website that requires JavaScript is, and always will be, worse than one that accomplishes the same without JavaScript.

Are users happy? Is dev speed of improvement good enough? Can you onboard new devs easily enough?

That’s it. Nobody cares if you used CSS or JS for a toggle switch.

The only people who disable JavaScript in their browsers and expect the 2023 internet to accommodate them are right here in this thread.

Just componentize it and move on to solving the next business problem, not the next code elegance problem.

My 2 cents: native solutions like HTML and CSS are preferable: they are designed to degrade well, they work with screen readers, with increased font size, high contrast, and other less-known or unknown and even future use-cases and needs. No dev team has the time to test their custom JS solution on all possible browser targets, and in reality they frequently fail even basic accessibility needs for no good reason.

At least to me, honoring the principles of the web is our responsibility, especially in our current time when they are arguably under attack from well-funded players. I would hate to see the web degrade into a delivery mechanism for opaque executables that work only on corporate blessed mega-browsers.

Where does this idea come from? I’m seeing it all over these comments, and I strongly suspect this sentiment is coming from people that haven’t actually looked at WCAG or been tasked with creating a compliant accessible website. You can botch the contrast, hard code font sizes in pixels, and leave out pertinent navigation details for screen readers with plain HTML and CSS. Here’s WCAG if you don’t believe me (emphasis mine):

> Myth No. 9: Pages With JavaScript Cannot Meet WCAG 2.0: FALSE WCAG 2.0 was designed to allow many new modern technologies to be used and still provide accessibility. Pages with JavaScript can be made to conform to WCAG 2.0. It is also possible to write pages with JavaScript using the JavaScript in a way that would make the pages not conform. It is also possible to create a page using only HTML which do not conform.[0]

There is nothing about using JS that makes a site less accessible, and there is nothing built in to HTML to make a site automatically accessible. The only way you’ll have an accessible site is by testing it manually and bringing in users to find edge cases.

[0]: https://www.w3.org/WAI/GL/wiki/WCAG_Myths

Other than the people who have to wait several minutes for your 20MB JavaScript framework to load on their slow metered connection just so you can make an expandable section using a bunch of <div>s rather than the native <details> element. But those people don’t matter because they should just move to a country with unlimited fast internet, am I right?

Nobody is suggesting using a 20mb framework to make a toggle switch work on a standalone page that isn’t a web app.

If you’re building a web app either way, then choosing between a screen full of CSS or a handful of lines of js is negligible.

For expanding sections, you should use native HTML elements when they do the job with less effort/code. You should use JS when they don’t.

What a strange statement. 'Vanilla' JS has been supported 'natively' in browsers since the late 90s.

Only a very small but vocal minority of users disable JavaScript, as it's not a default setting in any of the web browsers with a market share higher than the rounding error.

In a lot of cases, designing a no-JS website disadvantages both the service provider and the users:

- the service provider has to support a higher load to render the page and process the data on the server,

- the user has to endure longer processing times for their data, since their request necessitates a round trip from/to the server adding additional latency.

For example, let's think of an image processing web app. All of this can be done on the client side (and this gives the user a higher sense of privacy since their data doesn't need to reach the server). It's much faster there, reduces the server load - allowing the service to be used by more people at once.

And there is no value in appeasing the no-JS minority, since either maintaining a no-JS version of the app in parallel, or building the entire app without JS, outweighs the potential ROI from the <1% of users[1].

If you disable JavaScript because of tracking and ads:

- browser extensions exist to only prevent tracking JS from running without affecting the websites,

- you can still be tracked server-side.

[1] https://gds.blog.gov.uk/2013/10/21/how-many-people-are-missi... - 0.2% of users of the UK online government services had JavaScript disabled. Based on the research I can find online, most of the no-JS users are using TOR, which isn't a terribly profitable demographic for commercial websites.

I keep JavaScript always on and if I see a website abusing my trust, I just blacklist the entire website from my browser and never visit it again.

As a developer, all of my publicly available personal projects feature no tracking, no advertisements, and no third-party JavaScript in general. JavaScript is a really good tool, but as any tool can be, JS can be misused.

> Don’t follow some arbitrary doctrine

Isn't choosing what the boss told you to use simply because they told you to following arbitrary doctrine?

If someone has a reasoned argument for a specific tool they should share it, at which point you're picking it for that reason not because of the boss said to

Developers, engineers, whatever need to be responsible with the product they make. Part of that means making tool decisions that fit the specific context and pushing back when necessary

I don't like it where there's react for complex stuff and then another pattern for simple stuff. It's hell either way. Just one thing that is simple and can compose to complex things. Not different patterns to handle different levels of complexity.

Any api should be simple and compose-able into complex things. Here we have (react) which is not simple and not de-composable into simple primitives. ANd we have html without JS which isn't composeable into something more complex.

But, at least on this device (Brave, iOS) some of the mentioned features just didn't work (e.g. emoji accordion) or were awful experiences.

The autocomplete drop-down seemed very broken and both the checkbox and modal especially felt very sluggish. Like I would look for an alternative sluggish.

I've had plenty of positive no-js experiences, but this wasn't it.