[HN Gopher] You don't need JavaScript for that
___________________________________________________________________
You don't need JavaScript for that
Author : soheilpro
Score : 737 points
Date : 2023-12-02 09:57 UTC (13 hours ago)
(HTM) web link (www.htmhell.dev)
(TXT) w3m dump (www.htmhell.dev)
| Alifatisk wrote:
| The custom switch was honestly kind of impressive
| syslog wrote:
| From the UX point of view I very much prefer the oldschool way
| of ,,ticked"/,,nonticked" instead of ,,left/right" switch.
| jotaen wrote:
| To me, they have slightly different semantics: I perceive the
| checkbox as "passive" form element (i.e., only to have an
| effect on form submission), whereas the toggle switch I
| understand as instant action (i.e., effectuated immediately,
| on click). Unfortunately, it's not consistently used that way
| in practice, which makes the situation confusing at times.
| pohuing wrote:
| I wonder how much the culture you're used to matters for
| this. What if you grew up with right to left writing system.
| Should your switches have the off state on the right?
| 11235813213455 wrote:
| I'm ok with window.prompt(), window.confirm() etc
| kristopolous wrote:
| I was disappointed it wasn't there.
|
| In my experience, managers will complain but the users don't
| actually care and just want something that works.
| anamexis wrote:
| They're mentioned in the dialog section.
| troupo wrote:
| Moreover, unlike dialogs they are immediately accessible.
|
| Dialog was rushed in without fixing many problems it has
| because Chrome (and apparently other browser, too) want to
| remove prompt/confirm/alert.
| goatlover wrote:
| Removing prompt/confirm/alert breaks the web for all sites
| making use of it going back to the JS 1.1, so that has to be
| a no go.
| tiku wrote:
| The thing is, that sometimes javascript is a lot easier that 40
| lines of css.
| frognumber wrote:
| Yes, but the 40 lines of CSS puts the logic in the right place.
|
| 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).
| sdflhasjd wrote:
| The big thing you didn't mention is accessibility. Unless you
| know exactly what you're doing, just a few lines of
| javascript will let you break a user interface in so many
| subtle ways.
| andrewstuart wrote:
| >> puts the logic in the right place
|
| 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.
| rado wrote:
| JS for UI is wrong, because there will be FOUC, and if you
| preload JS, the page will be slower. Of course, if
| something is impossible with CSS, JS is fine.
| andrewstuart wrote:
| >> JS for UI is wrong
|
| Yeah that's showing an incomplete understanding of web
| application development.
| rado wrote:
| Yeah, the 90% of web apps whose UI is broken, I don't
| understand them. Haven't we all seen multimillion $
| airline mega web apps that can't present a decent form?
| frognumber wrote:
| > 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.
| Capricorn2481 wrote:
| Javascript on the frontend is not for "systems" logic, it's
| for small changes to the layout without reloading the page.
| This myth that HTML, CSS and JS are all separate "systems"
| that need to be isolated has to die.
| ImPostingOnHN wrote:
| JavaScript on the frontend is not intended for "small
| changes to the layout without reloading the page", it's
| intended for changes to content. CSS is one of the tools
| intended to manage layout and appearance.
|
| Is it _possible_ to use one for the other? Of course.
| nfw2 wrote:
| All the examples in this blog post use CSS to implement the
| functionality of the widget, not just appearance of them. By
| your own reasoning, that should be handled by JS, not CSS
| makapuf wrote:
| Of those 40 lines, many are styling to create the look of the
| switch in css, it could have been replaced with an image (and
| needed for a js solution anyway)
| cm2187 wrote:
| But it's also too often broken, fragile, and the worst sin of
| all, break default behaviours of browsers. It is the price we
| pay for html having been stale for 15 years between the late
| 90s and 2012-ish.
| collyw wrote:
| As a mostly backend guy that's the case most of the time for
| me.
|
| 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).
| chrisweekly wrote:
| https://every-layout.dev shows how to leverage CSS properly,
| from first principles.
| collyw wrote:
| Thanks, I'll check it out.
| rado wrote:
| The correct way to think in CSS is to think in HTML, which
| has the functionality we need (like a checkbox etc) and CSS
| is an enhancement on top of it. Ditto JS.
| rcbdev wrote:
| This is anecdata but in my experience the way WebDev (esp. HTML
| and CSS) is being taught in academia is very crusty. I've seen
| Juniors enter the workforce with a solid understanding of table-
| based layouts from the 2000s for some reason.
| spongeb00b wrote:
| The other end of the spectrum: I'm seeing graduates with great
| knowledge of frameworks, but no understanding of the
| fundamentals that these are built on. It's all fine until
| they're trying to debug a problem and don't know where to turn.
| _glares at Tailwind_
| Zetobal wrote:
| That's not a tailwind problem that's an educational one.
| kristiandupont wrote:
| I guess it's a sign of the domain expanding (exploding,
| really). "Software development" is not a single discipline,
| even though it's still taught as such in many places.
| sensanaty wrote:
| I mean you can't really use Tailwind if you don't understand
| at least some of the underlying CSS. It's not like it does
| anything magical for you, it just gets rid of having to give
| class names to things and has some nice little utility
| functions as well such as `grid-cols-x`.
| frognumber wrote:
| This was very nice!
|
| 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.
| MaxBarraclough wrote:
| > There is no principle that one should "Choose the least
| powerful language suitable for a given purpose."
|
| This is mistaken.
| https://en.wikipedia.org/wiki/Rule_of_least_power
| davedx wrote:
| It's a stupid rule. Why?
|
| 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.
| williamcotton wrote:
| Is C more or less powerful than TypeScript?
| MaxBarraclough wrote:
| More. JavaScript is deeply constrained by design.
|
| 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.
| kevindamm wrote:
| I think it does make sense if you consider it in terms of
| actual language power (a la Automata Theory) as opposed to
| just varying kinds of Turing-complete languages as it seems
| you're framing it.
|
| 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
| Spivak wrote:
| > If what you need is a configuration language, please
| don't express it in Python
|
| 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.
| wizzwizz4 wrote:
| It sounds like we just need more thoughtful configuration
| file design. None of the tools on my computer, save
| systemd (which is its own whole mess), are as you
| describe: most of them are using data formats, and only a
| few are using shell, Tcl or Python scripts.
| PhilipRoman wrote:
| I'd say Spring and React are less powerful than just plain
| Java/Javascript, in fact having any framework usually
| reduces the "power".
|
| 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.
| esrauch wrote:
| html or css is less total power in exchange for being
| better at some specific things.
|
| 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.
| gibbitz wrote:
| Funny, until I read this it didn't occur to me that this
| rule smacks of premature optimization. Odd though that
| often in optimizing an application after it's written we
| don't often consider something as high level as switching a
| tabbed interface to pure HTML/CSS from a JS framework
| plugin. I would guess this is due to cost, but I've never
| heard anyone articulate it this way...
| darkerside wrote:
| Can we not use language like mistaken and stupid to describe
| what is clearly a heuristic?
| Peritract wrote:
| It is mistaken to assert that there is no such
| principle/heuristic.
|
| It's not mistaken to _disagree_ with the principle, but
| that 's not what the comment you replied to was doing.
| frognumber wrote:
| As the original poster, I will go on the record:
|
| 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).
| MaxBarraclough wrote:
| Thanks. The intended tone of my comment was to be factual
| and direct, not to be derogatory. Pointing out a mistake
| is certainly not the equivalent of calling someone
| stupid.
|
| 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.
| frognumber wrote:
| I was not familiar with that, so thank you, but to explain
| it, you need one more click, to:
| https://www.w3.org/DesignIssues/Principles.html#PLP
|
| 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."
| davedx wrote:
| You put it very diplomatically. In my world I'm a lot more no-
| nonsense about the anti-react movement: they can go spend their
| careers making dull static websites with progressive
| enhancement and I'll work on the interesting stuff without
| them.
| MyFirstSass wrote:
| This is interesting. React / Vue 3 has totally destroyed the
| creativity involved in webdev for me after working on
| multiple larger projects.
|
| 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.
| sam_lowry_ wrote:
| Thanks for the hint on Petite-Vue, it's just enough
| framework to my taste!
| sensanaty wrote:
| > 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.
|
| 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.
| couchand wrote:
| You have a million lines of in-house Vue code or is that
| inclusive of dependencies?
| marcosdumay wrote:
| > The newer frameworks just have too much "magic" going on
|
| 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.
| klabb3 wrote:
| You don't have to support, use or even like React in order to
| like responsive clients that don't roundtrip to a server for
| every little thing. Heck, it doesn't have to be reactive
| programming at all for all I care, as long as the result is
| good. It just happens to be that currently reactive
| programming is generally the least bad system to program in.
| But even CSS transitions can do a lot of heavy lifting and
| degrades well.
| _a_a_a_ wrote:
| _shrug_ And I won 't be visiting. The only thing I care about
| is useful content well presented. I always disable JS for
| security reasons (that, and because pages load a hell of a
| lot faster and with far less memory). Yes, things break but
| it's a price I'm more than happy to pay.
| gemstones wrote:
| The interesting stuff tends to be webapps, that people pay
| for and are often internal to a company.
|
| 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?
| jakelazaroff wrote:
| I promise you that the majority of React apps are effectively
| "dull static websites" that happen to be rendered on the
| client and that you can do a ton of interesting stuff without
| it. Here's a full-on Photoshop clone in the browser built
| without any libraries: https://www.photopea.com/
| Zetobal wrote:
| Well the absolute insane amount of component/ux libs say
| something else. I also can't really differentiate between
| companies anymore everything is just shadcn with low effort
| chatgpt copy.
| andrewstuart wrote:
| >> Choose the least powerful language suitable for a given
| purpose.
|
| 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.
| tnbp wrote:
| Do this only if you don't care about the people that use
| (sometimes: have to use) your software. Otherwise,
|
| >> Choose the least powerful language suitable for a given
| purpose.
|
| (Don't make me needlessly enable JavaScript to use your site.)
| andrewstuart wrote:
| >> Do this only if you don't care about the people that use
| (sometimes: have to use) your software.
|
| 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.
| tnbp wrote:
| Your web app is most likely rubbish and 20 times as
| complicated as it needs to be, and probably _still_ nothing
| special.
|
| A website that requires JavaScript is, and always will be,
| worse than one that accomplishes the same without
| JavaScript.
| unsupp0rted wrote:
| > 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.
| klabb3 wrote:
| I don't know exactly where you're going, (and to be fair
| the parent comment is rude) but it's wise to be humble
| even if you are a professional. Some of the most
| experienced people in the field frequent these threads,
| HN is not a monolith of neo-luddites.
|
| 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.
| xigoi wrote:
| > Nobody cares if you used CSS or JS for a toggle switch.
|
| 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?
| unsupp0rted wrote:
| Vanilla JavaScript is supported natively by all web
| browsers now.
|
| 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.
| rado wrote:
| Or these people are execs on business trips on terrible
| hotel or remote connections.
| rado wrote:
| Nobody cares because people have been trained on crap
| software for decades and don't know what it is capable of
| when optimised well. USP opportunity, anyone?
| zztop44 wrote:
| Sure, maybe if it accomplishes _exactly_ the same. That's
| why I disable JavaScript on most news sites. But in the
| real world most web apps simply can't accomplish the same
| without JavaScript, which is why we use JavaScript.
| jmbwell wrote:
| The article seems to be suggesting to remember to use the
| power the the web browser already provides instead of
| needlessly using frameworks.
|
| 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.
| yakshaving_jgt wrote:
| > As a professional developer
|
| 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.
| BirAdam wrote:
| Sure, I guess. Just act like all of those vision impaired
| folks don't exist, and put the entire website in JS that
| their screen reader can't handle. Nice.
| Drakim wrote:
| Remember kids, if a minority is a "rounding error" it's
| okay to ignore, block, and hurt them though your
| profession. That's what webdevs tell me.
| _gabe_ wrote:
| Disabling JS doesn't magically make your site screen
| reader friendly. It's entirely possible to create a shit
| layout that uses no JS and is just as horrible to use as
| a shit layout with JS. Likewise, adding JS doesn't
| magically make your site non-screen reader friendly.
|
| What actually makes a site screen reader friendly?
| Developers that actually write accessibility tests, tab
| through their site manually, open it with a blindfold and
| a screen reader to make sure they can navigate it, etc.
| This myth that no JS automagically enables accessibility
| needs to die.
| rado wrote:
| It's even more ridiculous to bring the browser to its
| knees, destroy performance, and accessibility, because the
| trendy framework made your dev life easier.
| matsz wrote:
| > (Don't make me needlessly enable JavaScript to use your
| site.)
|
| 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.
| xigoi wrote:
| Many websites that use JavaScript, particularly news sites,
| would be _much_ faster without it.
| matsz wrote:
| True. As an user, I just don't visit websites that
| disrespect me, though.
|
| 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.
| _heimdall wrote:
| > No. Choose what you like, what you enjoy, or what the boss
| told you to use
|
| > 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
| thyselius wrote:
| Nice. But the second switch doesn't work on iPhone ( doesn't
| toggle when I tap it)
| Joeri wrote:
| It is not supposed to, the code is completed in the third
| example.
| alserio wrote:
| they explain that it works but you need the next step to see it
| mock-possum wrote:
| > *The rule of least power*
|
| > 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.
| rado wrote:
| So the unofficial (?) input:before is safe to use now, what's the
| consensus?
| seanwilson wrote:
| > Of course, designers may not like the way this looks and we
| want to create a great looking custom switch.
|
| The general UI rule is use a switch when toggling has an
| immediate impact (similar to pressing a light switch) vs a
| checkbox when there's a submission step before it has an impact
| (similar to ticking a paper form then mailing it). See:
|
| https://www.nngroup.com/articles/toggle-switch-guidelines/.
|
| It made sense after learning this but I didn't find the
| difference that intuitive before. A lot of UIs get it wrong (e.g.
| switches in forms, checkboxes for settings that immediately
| change something) but it only bugs me now I know which one to
| use. It's not only for cosmetics though.
| kristiandupont wrote:
| I personally had not heard this but it does sound intuitive to
| me. A checkbox is literally something you would check on a form
| (i.e. piece of paper) before handing it in. A switch on the
| other hand, it something that offers immediate feedback in the
| real world.
| tgv wrote:
| Idk. There are enough switches that don't have an immediately
| noticeable effect, e.g. when you have to open a panel to turn
| things on or off, or when you have to go to another room.
| It's always hard to come up with the perfect
| definition/metaphor, but perhaps it's more like an operation
| that has a lasting effect.
|
| But like designers shouldn't overdesign, we shouldn't
| overthink what's "correct" use. If it works and/or feels
| natural, it's ok. If it doesn't, it's time to consider
| alternatives, but you shouldn't implement them because some
| rule says so.
| pavlov wrote:
| It's a useful distinction but frustrating to apply in
| practice because we don't have a similar convention for many
| other UI elements like input fields and date pickers. You
| can't tell at a glance whether these will produce an effect
| immediately after entering a value, or whether there is a
| separate submission action.
|
| In terms of primitive types and common UI platforms, we have
| this immediate/deferred distinction for booleans and enums.
|
| Booleans are represented by checkboxes vs. switches as
| already discussed. And enums are represented by radio buttons
| (the traditional form element) vs. multi-part buttons (which
| Apple calls segmented controls).
| vertnerd wrote:
| I wish someone came up with a better UI than the toggle.
| Usually, I understand what it means, but I often find toggles
| where it isn't clear what the state of the toggle is. Right vs
| left, color vs no color, just isn't obvious to me. A visible
| check in a box is crystal clear.
| Timon3 wrote:
| A toggle works fine if it's not treated as boolean, due to
| the exact problem you mention. What fixes it for me is having
| the meaning spelled out on both sides of the toggle, e.g.
| like this: dark (o ) light
| runnerup wrote:
| Separately, some UI's make it very hard to tell which side
| is selected. It's a rare problem, but especially anxiety-
| inducing for me when it does appear.
| neffo wrote:
| (o ) "Do you want to receive marketing emails from our
| partners?"
|
| This is absolutely a dark pattern.
| ben0x539 wrote:
| Even worse when there's not even a grammatical structure,
| like
|
| "opt-out options"
|
| "annoying marketing emails (o )"
|
| am i... enabling the thing? opting out of the thing?
| uxp8u61q wrote:
| It's also a stupid pattern. Privacy and spam laws usually
| require informed consent. They might as well just not ask
| for anything, because any consent they get this way
| doesn't count for shit.
| dylan604 wrote:
| are you using anxiety with a bit of hyperbole here, or is
| it really making you anxious? I can see it being
| confusing and needing extra time to really look at it
| rather than being instantly obvious, but it's nothing to
| cause stress. It's just a setting/option. It's not going
| to cause significant issues if misinterpreted. You can
| just set it the other way, and do it again.
|
| Is this the same thing that separates those that like to
| mash all the buttons and twist all the knobs to see what
| happens vs those that don't want to touch anything
| because they don't know what will happen?
| runnerup wrote:
| > are you using anxiety with a bit of hyperbole here, or
| is it really making you anxious?
|
| Depends on the setting. Sometimes they're for things that
| have greater than usual effects, like getting locked into
| a subscription payment or agreeing to additional charges
| for Spirit Airline flights. Other times they're for
| things that I have difficulty taking the initiative to
| address, like notification/unsubscribe settings, for
| which my ADHD only allows me occasional "windows" of time
| where I'm able to initiate or follow-through on changing
| the settings.
|
| Sometimes it doesn't really matter and I just scoff at
| the bad UI and it's not a problem.
| yaur wrote:
| The worst offender to me is the ambiguous ui around
| creating a teams meeting for meetings created through
| whatever we are calling the outlook web thing these days.
| You don't find out if you did it right until you have
| sent an email to your attendees with an erroneous teams
| link. And yes that is anxiety provoking.
|
| Of course part of what makes it ambiguous is that there
| is a setting somewhere completely different which when
| set will add a teams link whether the slider is set or
| not.
| webel0 wrote:
| This can be used as a dark pattern. If you want a user to
| use a particular setting (e.g. "Customize my ad
| experience.") you can just make it unclear which they're
| choosing.
| aembleton wrote:
| Radio buttons would work better.
| Timon3 wrote:
| It depends on the structure of your site. If you have,
| say, 10 pairs of boolean options in quick succession,
| toggles work way better than radio buttons.
| xscott wrote:
| I agree, but it seems like a lot of times you get:
| (o foo) (bar o)
|
| And I don't know if I'm supposed to click it to change to
| `foo`, or if that means it is already in the `foo` mode.
| Timon3 wrote:
| That's definitely much worse, both due to what you
| describe, and due to the fact that you don't know what
| the label on the other side says.
| arcanemachiner wrote:
| (I'm gonna abuse your example to rant about dark mode
| selection interfaces.)
|
| There's a small problem with your example: Dark mode isn't
| a binary setting.
|
| For modern applications, there should be 3 settings:
| System, Light, and Dark. (I like to use a dropdown menu to
| select the theme).
|
| This makes it work for people whose theme changes
| automatically between day and night (it's a built-in system
| setting on macOS, and possibly Windows). L
|
| For a web app, Light and Dark can set a value in
| localStorage which sets the theme manually, but System
| should remove the setting.
|
| You can detect the correct theme when the page is loaded,
| and also add an event listener to detect theme changes (so
| that either the user or the OS can change the current
| theme). It's actually not too difficult to set up properly.
| andrei_says_ wrote:
| I think the first widespread use of a toggle was in iOS a
| long time ago.
|
| The core function of a toggle is to - well - toggle.
| Off (o ) On
|
| And the way it was used was Dark (o
| )
|
| or Dark ( o)
| varrock wrote:
| The article linked by the commenter above addressed your
| concern. They mention the toggle should have an _immediate_
| state change. I really liked the iOS airplane mode example
| the article used:
|
| > When turning airplane mode on for iOS, Apple provides
| immediate results by changing the cellular bars in the upper
| left-hand corner to an airplane icon.
|
| To summarize, it sounds like the toggles you've experienced
| haven't led to an immediate state change, which likely
| identifies them as better candidates for a checkbox like you
| mentioned.
| marcosdumay wrote:
| Honestly, besides being standard, checkboxes solve all of
| your problems.
|
| That separation between immediate and delayed effect seems
| quite artificial to me, and doesn't exist at all on other
| types of inputs. It looks like a bad, post-fact justification
| created just to placate some masses instead of for good
| fundamental reasons. (And yeah, I do know who I'm criticizing
| here.)
|
| Anyway, it's a lost battle, so whatever, let's leave with the
| bad consequences.
| sopooneo wrote:
| Total aside: but related to ambiguous true/false designation:
| A lot of times when people write articles like "Ten Myths
| About NodeJS", it is unclear in each of the numbered items
| whether the stance initially described is the _incorrect_
| myth, or the _correct_ view as proposed by the author. To
| make it worse, some writers vary the structure between items!
| chiefalchemist wrote:
| Yeah, too often. But that's not the toggle's fault. The
| majority of the time the design (colors) and the associated
| label are the root problem. A toggle doesn't have to be
| ambiguous. Unfortunately, designers / UX'ers seem to think
| so.
| jopsen wrote:
| Switches seems like an innovation that just makes UI worse.
|
| Checkboxes are easy to understand.
|
| If there is immediate effect then using a checkbox also works
| perfectly fine.
|
| The switch is just always worse (IMO).
| StableAlkyne wrote:
| > Switches seems like an innovation that just makes UI
| worse
|
| I once visited a site that had a hamburger menu holding the
| navbar that auto-hid if you clicked away. They also had a
| switch on the corner of the opposite side of the screen
| that opened the navbar and kept it open
|
| I still sometimes wonder what was going through the UI
| guy's head when they made that
| chatmasta wrote:
| The most annoying toggle is the Spotify no-repeat/repeat-
| all/repeat-one button. Is it currently not repeating? When it
| has the dot, is it repeating one song, or all of them, and
| will pressing it make it repeat just one?
| leephillips wrote:
| Agreed. The Spotify UI is bad in general, but this one
| especially. I've been using it for years and I still have
| no idea what I'm doing there.
| webel0 wrote:
| A big offender here is (was?) instagram's privacy settings. I
| recall trying to help my mom turn her profile to be private
| and we were both confused: does the blue mean it is private
| or not?
| seanwilson wrote:
| > A visible check in a box is crystal clear.
|
| For the "off" state though, I've never found an empty square
| outline being that clear (this looks similar to a button or a
| text field) or easy to spot, and a cross/X in the square
| instead can also be confused with "on". Not saying a switch
| fixes this however.
| Waterluvian wrote:
| I can absolutely see this. But to share a different perspective
| since "instantly vs. submit" doesn't make sense in some of my
| software that's constantly applying input changes on change:
|
| I use a switch to toggle one specific thing, checkboxes to pick
| zero, one, or many related things.
|
| Eg: switch: "slow mode is active for robots in this zone."
| Checkboxes: "this applies to robot types A, C, D."
| lelandfe wrote:
| Apple can scarcely pretend to adhere to it, but their HIG on
| checkboxes, radios, and switches is good:
| https://developer.apple.com/design/human-interface-
| guideline...
| jwells89 wrote:
| Also worth noting that on macOS (where you'd see
| checkboxes), things like settings dialogs very rarely have
| "save" or "apply" buttons, with any settings changes taking
| effect immediately. Checkbox vs switch has no bearing on
| immediacy.
|
| The only exceptions are cases where partially applied
| settings can cause problems (like network settings) and the
| odd holdover that's survived since the pre-OS-X days (like
| the settings dialog in Music, previously known as iTunes,
| previously known as SoundJam MP).
| montroser wrote:
| I like the sentiment here, and the switch is cool, and
| summary/details is occasionally handy. But -- the datalist
| element is almost never a realistic option for anything more than
| a toy or prototype.
| arun-mani-j wrote:
| My favorite "no JS, we have CSS" stuff are side bar (drawer) and
| carousel. DaisyUI (a TailwindCSS components library) has
| components readily available too :)
|
| 1. https://daisyui.com/components/drawer/
|
| 2. https://daisyui.com/components/carousel/
| egeozcan wrote:
| How do you announce the drawer to the screen readers?
|
| 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).
| withinboredom wrote:
| I believe it is announced as soon as you add it to the DOM
| _and_ make it visible. I don't have a computer near me to
| test it, but that's what I remember when testing this stuff
| out a few years ago.
| dawnerd wrote:
| I've had to add a bunch of js to support this in the past
| when accessibility reports come back saying there's no
| announce, mainly around css only dropdown navs.
| withinboredom wrote:
| Do you remember which reader software it was?
| egeozcan wrote:
| I'm not the person you're replying to but we test with
| NVDA, and we did have problems with some CSS-only
| solutions.
| dawnerd wrote:
| I don't, it was a while ago and we just use js now for
| that sorta stuff even if it's only for toggling aria
| attributes.
| simonw wrote:
| Every single time I go looking for JavaScript components like
| this I find myself asking the same question.
|
| 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.
| continuational wrote:
| I'm always initially excited about these frameworks, but like
| all other frameworks I've tested, DaisyUI has a number of
| issues in iOS Safari and other browsers.
|
| 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.
| tln wrote:
| What framework is the best in your testing?
| recursivegirth wrote:
| Not OP, but which framework is the best is a very
| subjective question. Frameworks in general make what you
| want to do easier to do, at least from a developer
| experience perspective. Generally this meets the mark for
| most use-cases, but has proven to be a problem (especially
| in ORMs) if you want to go outside of the box. They seek to
| abstract complex or cumbersome logic into more consumable
| APIs, and in most cases this ends up being a footgun.
|
| 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.
| continuational wrote:
| Usually these frameworks don't survive a "try to click on
| each element in their official demo" test in iOS Safari
| without glaring, visual issues, so I don't see much reason
| to rank them.
| arcanemachiner wrote:
| Was this recent? I'm not 100% on the version numbers and
| dates, but I believe iOS support got better on daisyUI v3
| within the last year or so.
|
| I remember that dropdowns work a lot better now. Do you
| remember which components you had issues with?
| yetanother12345 wrote:
| > link: components/carousel/ >> "Snap to " [start|center|end]
|
| 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)
| chrismorgan wrote:
| > _Native smooth scrolling with scroll-behavior: smooth_
|
| 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.
| afavour wrote:
| The point of the article isn't to dictate what design elements
| people use, it's to point out more user friendly ways of
| achieving those designs.
|
| 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".
| chrismorgan wrote:
| > _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.)
| ImPostingOnHN wrote:
| _> The point of the article isn't to dictate what design
| elements people use, it's to point out more user friendly
| ways of achieving those designs._
|
| 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.
| gibbitz wrote:
| Let's not forget the popularity of Instagram and tik tok both
| of which are basically carousels wrapped in an app. The
| problem with carousels is the expectation that they deliver
| more content than a simple visual (links, calls to action,
| paragraphs of text etc.). They're the content not the
| navigation.
| 542458 wrote:
| > But carousels are still a bad idea
|
| 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.
| chrismorgan wrote:
| I believe you're significantly overstating how good and
| thorough a job they do of such things. Also it's not the sort
| of thing that's particularly conducive to A/B testing.
| swiftcoder wrote:
| BigCompany A/B testing has this unfortunate tendency to
| demonstrate positive results to whatever you are testing.
| 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)
| hinkley wrote:
| Avoiding triggering buyer's remorse is something high end
| consumer business understand and Amazon emphatically does
| not. I just bought a kayak, don't advertise $3000 kayaks to
| me. Advertise dry bags and paddles and dry suits, you
| numpties.
| gibbitz wrote:
| So you don't need javascript for any of that anyway ;)
| FireInsight wrote:
| Why is native smooth scrolling not a good idea most of the
| time? I usually add it at least right after implementing some
| TOC-style anchors.
| chupapimunyenyo wrote:
| Thanks for your opinion
| cantSpellSober wrote:
| > know that [outline: none] not a good idea
|
| Why recommend a style on summary:focus but not input:focus?
|
| Shouldn't we style :focus-visible for both or neither?
| afefers wrote:
| The irony is using a JavaScript-based static site generator to
| make the site: https://www.11ty.dev
| xutopia wrote:
| Nothing ironic here. It's a different domain problem and
| they're using a different domain solution for it. The generator
| might simplify an otherwise much more complex problem down to
| its essence.
| intrasight wrote:
| Not so ironic now - as there aren't really good alternatives to
| a build step with a static site. But my opinion is that that
| may change now with the adoption of HTMX for static sites.
| There doesn't have to be a build step since you don't have to
| build full pages from their constituting parts.
| uxp8u61q wrote:
| You do realize that HTMX is a Javascript library?
| intrasight wrote:
| Of course I do
| redhale wrote:
| I was unaware of Datalist, but it does not appear to work on
| Chrome Android, at least not really.
|
| 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
| 11235813213455 wrote:
| works fine on chrome android
| from-nibly wrote:
| This is why these solutions take so long to catch on.
|
| JavaScript is pretty well standardized, html and CSS is less
| so.
| egberts1 wrote:
| CSS is easier than JavaScript.
|
| Here is an example of JavaScript-free CSS motion:
|
| https://egbert.net/blog/index.html
| demosthanos wrote:
| CSS may be easier, but that's irrelevant to OP's point--
| it's less standardized across browsers, so if you have to
| support a bunch of different browsers of varying ages it's
| _much_ easier to write JavaScript with boring CSS (and even
| transpile it if you want to use newer features!) than it is
| to polyfill all the missing CSS features you 'd need to use
| it instead of JavaScript.
| rymiel wrote:
| This thing where the datalist options show in the keyboard is
| some recent thing, i.e. a few months ago. It used to be
| "normal" before that, but I guess someone wanted to change
| things only for the sake of changing things
| technojunkie wrote:
| Hey browser makers, can we please be able to style the datalist
| dropdown?
|
| Also: https://adrianroselli.com/2023/06/under-engineered-
| comboboxe...
| croes wrote:
| Have you looked above the keyboard?
|
| For me it shows the options above the keyboard where normally
| word suggestions are shown.
| buovjaga wrote:
| I wonder if adding autocomplete="off" to the input element
| changes the behaviour? It is in any case required for sanely
| using datalists. Otherwise the value selection history will be
| appended to the dropdown list (observed in Chromium).
|
| 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.
| NegativeLatency wrote:
| I really wish data list was better, shipped it on an admin
| dashboard for something, and while it works fine in safari it's
| a bit broken in several ways on chrome and Firefox, leading me
| to need to replace it with JavaScript
| cushychicken wrote:
| Didn't work for me either on iOS.
| victorbjorklund wrote:
| Really nice. Some elements I wasn't aware of. Will def come back
| to this.
| caditinpiscinam wrote:
| I bet you could use the <details> element to implement the
| show/hide comment behavior on hn
| revskill wrote:
| My principle is always: The principle of the most power.
|
| I would use that to do simplest thing as possible, or i'm not
| afraid to do the best thing possible.
|
| Let's say you start with pure html, now how to decompose your
| HTML into multiple components with state ?
|
| Start with component-approach instead.
|
| Compiling to HTML is just the implementation detail.
| shadowgovt wrote:
| In general, good advice.
|
| ... 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.
| troupo wrote:
| > The Safari color picker, in particular, is so bad
|
| 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.
| jwells89 wrote:
| On desktop, the color picker in Safari has two stages: on
| first click it presents a 10x10 grid of colors with 10 extra
| basic colors on top, with a "Show Colors" button on the
| bottom that opens the macOS system color picker.
|
| 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.
| shadowgovt wrote:
| Yes, but tell that to my clients who keep telling me "Why
| can I choose any color in Chrome but in Safari I'm limited
| to a crayon box?" They either can't use color picker
| plugins or they can't figure out how to access them.
|
| And there's no language in the declarative API to, for
| example, start the user on the Mac OS system color picker.
| dhalucario wrote:
| The datalist element didnt work for me on Mobile Firefox (Fennec)
| xigoi wrote:
| This has been a known issue for a long time.
| https://bugzil.la/1535985
| allan_s wrote:
| An other example of "you don't need js" carousel :
|
| 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
| chrisweekly wrote:
| fyi, "another" is a single word
| allan_s wrote:
| Thank you ! As you may have guessed English is not my first
| language.
| chrisweekly wrote:
| My pleasure. Grammar nitpicking tends to get downvoted (as
| happened here), but my intent is to help educate. Glad it
| helped!
| internetter wrote:
| This works terribly on mobile and broke my back navigation...
| allan_s wrote:
| Can you precise what works terribly ? On which mobile browser
| ? I m interrested as I plan on replacing our current
| carousels by this one
|
| 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 )
| xboxnolifes wrote:
| It scrolls the screen to the carousel on click, and every
| click adds to page history so you need to click that many
| time to back out.
|
| 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.
| rudasn wrote:
| Love this. I make heavy use of dialog elements on WireHub.org,
| along with bootstrap classes to achieve drop downs that work
| without JS and still look nice.
|
| Only issue is you have to click the summary element to hide the
| dropdown, and that's where I cheat a little and use JS to hide
| it.
| ptx wrote:
| Great article! Very clear. Nice examples.
|
| 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...
| eigenvalue wrote:
| Wish I had read this a month ago before I wasted hours fighting
| against some of these things in tailwind and JS. That color
| picker trick is awesome, and the styled toggle switch looks
| extremely slick.
| dmezzetti wrote:
| 100% agree that everything doesn't have to be JavaScript. You can
| do a lot with just HTML and CSS.
|
| My company's website is all HTML/CSS - https://neuml.com
| eyelidlessness wrote:
| Edit: my mistake, the first custom-styled switch example isn't
| the full example. I realized that after I commented. Original
| comment below for posterity. It doesn't apply to this case, but I
| think it's still relevant as I've encountered the mistake I
| _thought_ I was seeing in "you don't need JS" contexts pretty
| frequently. In any case, sorry I misunderstood the example in the
| article.
|
| 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.
| simonw wrote:
| Did you try all of the custom styled switch example? The first
| one didn't visibly work for me on Safari but the others did -
| the examples are meant to build up a demonstration of the final
| pattern.
| eyelidlessness wrote:
| I was just coming back to edit my comment to acknowledge
| this. My bad! I think the principle still applies, because I
| have definitely encountered the mistake I thought I was
| seeing here. But it doesn't apply to the example. That's what
| I get for commenting before the morning coffee sets in :)
| kilian wrote:
| Author here. The first styled example doesn't have the style to
| respond to the checked state. I explain that in the article
| right below the example.
| cfr2023 wrote:
| Good spirit, I was just recently seeking reference materials
| about how to execute an accordion style fold in pure html or CSS
| and discovered the approach you describe - so simple, we should
| be seeing it more often.
| dan-robertson wrote:
| A nice thing about using <details> instead of JavaScript is that
| Ctrl+F can see into the details and open them up whereas it can't
| open a JavaScript accordion.
| matteason wrote:
| hidden="until-found" will make this possible in JS-based
| accordions and other hidden content but is unfortunately only
| in Chromium-based browsers for now:
| https://developer.chrome.com/articles/hidden-until-found/
| remram wrote:
| MDN compatibility table: https://developer.mozilla.org/en-
| US/docs/Web/HTML/Global_att...
| agumonkey wrote:
| Funny we just hit a similar issue while scanning for some
| docs..
| remram wrote:
| TIL, thanks for the tip!
|
| Do you know if there are other ways to hide but allow search?
| chiefalchemist wrote:
| Actually, for accordion (i.e., details and summary), as I
| understand it, is not accessible out of the box. It's odd that
| the spec for that control / UI element / tags isn't accessible.
| But you can use JS to fix that.
|
| A colleague once shared a blog post with me on this but I can't
| find it atm.
| Eumenes wrote:
| I wonder how inefficient web apps contribute to carbon emissions
| ulrischa wrote:
| Other good example where no JS is needed: styling internal and
| external links
| joshstrange wrote:
| > datalist
|
| 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.
| theandrewbailey wrote:
| I was implementing a search suggestion box, and thought that
| datalist could help. It works fine until you want to display
| options that don't strictly start with what's been typed in,
| e.g. if the input is misspelled, no options will show. There's
| no way to force it to display everything, so I opted for an
| ordered list instead.
| gibbitz wrote:
| Always worth noting that using JS to extend the built-in
| semantic markup is a future-forward approach. When I started
| working in web development, changes took up to a decade (IE6
| held us all back, but the w3c was also fairly toothless back
| then). Now they happen quickly. Next year, datalists may be
| stylable in the big three without prefixing but you'll be
| beholden to your custom JS solution because business won't pay
| to rebuild. If you use JS to extend the native functionality
| you can always remove the JS at lower cost when the support is
| acceptable. Also with this approach, where the native controls
| are acceptable you can use it now and just apply the JS as a
| polyfil
| escot wrote:
| Are you aware of any frameworks that take this approach? For
| example, if I could import their Datalist and use it, but at
| build or maybe runtime it decides what to use based on the
| target environment? We of course have this for tons of things
| like language features.
| joshstrange wrote:
| I don't mean to be snarky but: have you ever worked at a
| company where that would be acceptable?
|
| "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,
| couchand wrote:
| > (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)
|
| 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.
| nonfungibleuser wrote:
| Article has a typo, now instead of not. "In contrast to JS, which
| is imperative, HTML and CSS are declarative. You tell the browser
| what to do, now how to do it. That means the browser gets to
| choose how to do it, and it can do it in the most efficient way
| possible."
| throwaway81523 wrote:
| It's a step in the right direction but CSS is another tool of
| abuse by what Philip Greenspun called "artistes" to make
| unreadable pages. I'm not a proponent of Gemini but basically all
| aspects of layout and typography need to be returned to the
| browser, which must be controlled by the user. Designers have
| endlessly shown that they can't be trusted with it.
| toldyouso2022 wrote:
| I use them and doing so saves a lot of time developing. Problem
| is that managers will complain that they are too simple. At least
| that's my experience working with "enterprise" consultancies
| todotask wrote:
| Some weird issue with <details> in Safari on iOS is that "open"
| attributes could disappear when iirc overscroll or something, so
| I was force to use JavaScript or disable overscroll behaviour.
| demondemidi wrote:
| The answer is always: of course you don't. But weaving in clever
| HTML like this is a pain in the ass to maintain, when you can
| drop in a reusable, extensible widget for your framework that has
| already been debugged and is one line of code that everyone
| understands.
| demosthanos wrote:
| The thing that this article is missing is that we use JavaScript
| in these places because compatibility is better. We can even use
| new JavaScript by transpiling, but polyfilling missing CSS and
| HTML is a lot harder to do and impossible in some cases (not to
| mention your polyfill will use JavaScript).
|
| `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.
| _the_inflator wrote:
| I side with you.
|
| 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.
| fingerlocks wrote:
| > The color picker is neat, but extremely nonstandard
|
| 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.
| demosthanos wrote:
| You do, but companies don't. A major advantage of a browser
| app over a native app is having one system that behaves
| relatively consistently across all platforms. This isn't just
| cosmetic: providing customer support for a web app that has
| _exactly one_ expected set of behaviors is far easier than
| asking your support agents to keep track of the constellation
| of different features users might have access to depending on
| their platform.
|
| 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.
| drdaeman wrote:
| > that prefers consistency
|
| So they should use the exact same OS and they'll have the
| same color picker everywhere, native to that OS. Problem
| solved.
| rhapsodic wrote:
| _> So they should use the exact same OS and they 'll have
| the same color picker everywhere, native to that OS.
| Problem solved._
|
| 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?
| wlesieutre wrote:
| Because as a customer there's nothing that makes me
| happier than when I contact customer service and they say
| "our website is made for Windows so you'll need to use
| the exact same OS as us"
| dizzy3gg wrote:
| Really? I am trying to put my customer/mum hat on and but
| is this really true. How many OS would you need to really
| support? 4 or 5? On top of that docs/knowledge would be
| more standardised. Google/peers/family would help people
| more.
| demosthanos wrote:
| > Google/peers/family would help people more.
|
| 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.
| gumby wrote:
| I hear the know it all customer is the worst.
|
| 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." :-/
| dgacmu wrote:
| The picker that opens in Firefox on Android is quite
| terrible, fwiw. Chrome on android has a good one.
| superkuh wrote:
| Nope. Javascript means that if it fails then it completely
| fails and the content is not there at all. While the HTML
| examples may not look correct in older browsers, the actual
| content will be there. With JS it's just nothing. Nothing at
| all. It completely breaks accessibility. With HTML my
| screenreader can at least still read it. JS generated content
| prevents this.
|
| 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.
| demosthanos wrote:
| None of what you said is an inherent problem with JS.
|
| 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.
| CharlesW wrote:
| The parent commenter is saying that JavaScript in the
| browser MUST NOT be a dependency for core functionality
| because it may be disabled ("when JS cannot JS").
|
| 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.
| rado wrote:
| Sample URL?
| lelandfe wrote:
| The <dialog> element actually has _deep_ support at this point,
| and the polyfill for the few percent of your users on 2021-era
| Firefox or Safari is totally fine. I highly recommend the
| element if you 're making modals; the accessibility gains are
| fabulous.
| MattGaiser wrote:
| > but because customer support will find it harder to help
| people.
|
| 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.
| kjkjadksj wrote:
| Compatability is only better if you make the assumption that
| all your users need to be using javascript. I much prefer using
| the web without javascript, it impacts my laptops battery life
| by hours. Some sites, are not compatible with this and render a
| blank page or complain to me that they require javascript to
| render some text in windows. Meanwhile Amazon has a javascript
| free clone of their ecommerce site, showing that such herculean
| feats are possible without reaching for javascript.
| hinkley wrote:
| Battery life is the silent victim. Maybe browsers should name
| and shame websites that are heavy.
| quickthrower2 wrote:
| I would love to know how many milliwatts a page is using?
| Any way to find out?
| Dylan16807 wrote:
| Sites should work without javascript, but I think it's fine
| to demand a somewhat up to date browser in that case.
|
| For features that have been very widespread for enough time,
| it's okay to have a javascript polyfill as the only fallback,
| in general.
| standardUser wrote:
| > Compatability is only better if you make the assumption
| that all your users need to be using javascript
|
| 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?
| joegibbs wrote:
| I think that is a pretty good assumption to make. The vast
| majority of websites are being made for the average person to
| use, and the average person is using one of the big browsers
| with more or less standard settings.
|
| 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.
| thex10 wrote:
| I try to push for making websites without JavaScript but
| nobody wants to because it requires some forethought. TIL
| Amazon has a functional no-JS version, amazing!
| hinkley wrote:
| I briefly contributed to WURFL before I got out of mobile.
| Being able to figure out limitations based on UA I think has a
| place in the world because you can generate script tags for
| polyfills in the head based on which you need.
|
| 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.
| yetanother12345 wrote:
| > I hope we eventually get to a place where browsers that don't
| support these features
|
| Uhm... I wonder whatever happened to "decay gracefully"?
| demosthanos wrote:
| Define "gracefully"?
|
| 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?
| solatic wrote:
| details / summary is an important hack when writing bots that
| post comments to GitHub PRs or issues, such that the details are
| hidden unless the user clicks on it, and thus helps keep the
| comments tidy instead of each comment being really, really long.
|
| It does, however, run into the 64Ki character limitation per
| comment. So HTML5 magic isn't by itself a magic panacea.
| kazinator wrote:
| It has to be usable by users with ten-year-old browsers. Now
| what?
| timenova wrote:
| Slightly off-topic, but just wanted to mention, the author of the
| post is the creator and developer of Polypane [0]. I've been
| using Polypane for the last few months (got a student discount
| with the GitHub Student Pack) and it's been amazing. It really
| helps speed up building light+dark mode, phone+desktop UIs
| quickly. I highly recommend opening Polypane on a second screen
| while developing any kind of web UIs.
|
| [0] https://polypane.app
| agumonkey wrote:
| The detail/summary element is a very common need, I had no idea
| it was so well implemented.
| corethree wrote:
| I'd like it so that there's one thing that handles everything.
|
| 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.
| wly_cdgr wrote:
| I'm sure you can convince some people once "CSS programmer"
| starts generating hits on job site searches.
| MagicMoonlight wrote:
| That toggley button is so good. The front-end meme developers in
| this thread are absolutely seething over this post but it's a
| good point. Why do we have all these stupid sites made in JS? If
| people just followed one standard like HTML, everything could be
| consistent and you could easily adapt it for things like
| accessibility or translation. You go on modern sites and the back
| button doesn't even work because it dynamically loads things all
| on a single page.
| nijave wrote:
| >If people just followed one standard like HTML, everything
| could be consistent
|
| 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.
| gibbitz wrote:
| Well usually the framework requires a plug-in and the plug-in
| requires RTFM which not all developers do. Also these
| frameworks and their plug-ins change and have their own
| dependency management that can cause code rot in short order
| that leads to accessibility or functionality falling off
| quickly. The solution to this becomes smoke testing for these
| already solved problems. Standardizing on built-in behavior
| makes testing all of this functionality the responsibility of
| someone not on your payroll or Jira board. I get that this
| isn't always going to be the solution, but that doesn't mean
| our code still needs to follow patterns developed to support
| Internet Explorer.
| nozzlegear wrote:
| > _The front-end meme developers in this thread are absolutely
| seething over this post but it 's a good point._
|
| 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.
| ksbrooksjr wrote:
| No one is seething. HN is filled with these low quality "js
| developer bad" comments these days. I have no idea what a
| "meme developer" is.
| nfw2 wrote:
| Why is choosing the least powerful language for a given purpose a
| core principle of web development? If a language has flexible
| abstractions, it can make hard tasks possible, and ALSO make
| simpler tasks easier. Whereas a language with clunky mechanics
| makes simple tasks complicated and hard tasks virtually
| impossible.
| yakshaving_jgt wrote:
| For the same reasons that using fewer moving parts is a
| principle in engineering more broadly.
| tgv wrote:
| Friction and wear?
| couchand wrote:
| KISS.
| joveian wrote:
| Nice to see encouragement to avoid javascript :). Dropdowns that
| require javascript are particularly common (and unnecessary).
|
| It seems on Firefox, focus-visible only appears when tabbing, not
| when using the space key to toggle. Not sure why that is.
| jasonjmcghee wrote:
| There sure is a lot of positive responses to this, and I get the
| draw of removing JavaScript. I usually find myself feeling more
| optimistic than the peanut gallery...
|
| 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.
| eiiot wrote:
| Notably, many of the features championed by this article just
| don't (yet) work on mobile Safari. JavaScript is used because it
| (usually) works everywhere, unlike niche browser features.
| beders wrote:
| Here we are in 2023 still battling with forms (see comments about
| datalist and color picker) and general UX for users entering
| data. It blows my mind. Why this isn't a _solved_ space is beyond
| me.
|
| 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.
| cjauvin wrote:
| What would it mean for forms to be "solved"? They are solved if
| you want to stick to boring/vanilla technologies. They are not
| if you insist on solving them, once again, with React, and then
| again with React hooks, and again and again, ad infinitum.
| mikeryan wrote:
| The reason is not "solved" is that everyone has a different
| "problem" so it's impossible to solve for all of them.
| Businesses solve for their use case using the the solution that
| fits their constraints.
|
| Having a multitude of "solutions" is a feature, not a bug.
| 9dev wrote:
| It's not like a handful of form controls looking like Windows
| 95 and hyper-specific React form fields are the only options.
| Here's an entire industry creating millions of components for
| basic fields; surely we can come up with better extensions
| and configuration, slots and styling opportunities that make
| life better for everyone.
| hinkley wrote:
| There are a few things a person could do that we can't because
| of CSRF.
|
| 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.
| Devasta wrote:
| The rejection of XML technology means that the web is condemned
| to endless reimplement shitty versions of what it provided.
| We'll still be implementing our own basic UI controls for the
| rest of our lives.
| ryukoposting wrote:
| Maybe this is a little unrelated, but why did our industry
| collectively pound our fists against the table and scream
| until XML went away? It's a little ugly and very verbose, but
| it's highly expressive and it has a proper schema language.
|
| 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.
| mixmastamyk wrote:
| XML is hard to read and write for humans and not efficient
| for machines, while the tools are complex.
|
| 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.
| hardcopy wrote:
| In other news, you don't need a native app for that.
| amatecha wrote:
| Relevant: https://enhance.dev/ "The HTML-first full stack web
| framework"
| LAC-Tech wrote:
| Do any front end developers actually subscribe to the "rule of
| least power"?
|
| 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!".
| jddj wrote:
| Well there you go.
|
| I've been using dialog a lot but every time I've been hacking
| some backdrop around/behind it.
|
| Had no idea about the property, that's great.
| oglop wrote:
| Great read. We have been trying our best in the project I work on
| to rip out as much JS as we can and implement things using the
| right html tags among other things.
|
| 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!"
| demosthanos wrote:
| Do you have a link to the FOSS project? I'd be interested to
| see the specific JS (and YAML) code that you're referring to.
|
| 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.
| oglop wrote:
| If the admins using your project are sys admins, they seem to
| prefer yaml. Shrug.
|
| 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).
| 1vuio0pswjnm7 wrote:
| But need Javascript for advertising and tracking. If this is
| incorrect, I'm interested in any examples where Javascript is not
| used and what percentange of online advertising this comprises.
| seabass-labrax wrote:
| Last time I checked, Carbon Ads don't use JavaScript, although
| it is not a _targeted_ advertising business. As for analytics,
| there is a considerable amount of personally identifying
| information you can collect exclusively with User-Agent headers
| in your sites ' requests, and of course the age-old technique
| of tracking pixels still works in most cases.
| chupapimunyenyo wrote:
| Bear blog uses css for tracking Why do you need it?
| matheusmoreira wrote:
| This is amazing. I'll be studying all of this and applying it to
| my site as appropriate.
| julienreszka wrote:
| Designers hate native forms for some reason. (job insecurity?)
| araes wrote:
| Couple items.
|
| - 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
___________________________________________________________________
(page generated 2023-12-02 23:00 UTC)