[z3t4]

You often have the dilemma whether something should be a link, or just a button. Links trigger a navigation to another page/URL, although in an "app" it could just render a new view rather then making a new browser request. A button is usually not a navigation, although it can render a new view and also have a unique URL. So the only difference is that you can right click and open in new tab on links, but not on buttons. And then you have to decide if you should style it like a button element or a:href element, where a:href signals to the user that they can right click and open in new tab, while a button does not. But you can also make an a:href look like a button, which can be considered an anti-pattern. Buttons do look nicer then links though. And buttons can also trigger a navigation, like in a form submit, but it's technically difficult to support submitting and open in new tab at the same time, because browsers have a hard separation between tabs, where one tab can't easily access another tab and vice versa. So while it's technically possible UX is often a matter of budget/laziness and stack/architecture.

[madeofpalk]

There's not really much of a delimma. This is a problem that was solved in "single page apps" 10 years ago.

    - links are for navigation
    - buttons are for action

Styling and appearance are not a factor - you can make buttons look like links, links look like buttons.

Simple rule is "should this view have a url". Should the user be able to navigate directly to this page? Should it exist in the history? Should the user be able to share a URL to that page to someone else? Most times the answer to all of these is.

In your javascript application, it is trivial to do single page app view navigations (without triggering a full browser request) by listening to link clicks and acting on it just as you would if it were a button click. All frameworks and routing libraries will handle this for you out of the box. If you roll your own, its not that difficult to add this functionality.

[throwaway0885]

You're just making blanket assumptions about pretty hard UX problems.

Are tabs a view? Should they be buttons or links? What if the tabs are in the sidebar in some widget?

What about collapsible items? HN uses JavaScript to store your collapsible preferences to your account. Not shareable but consistent on page refresh. Is that good? I don't know.

The fact is, in PWA world, what's a links and what's a button is blurred, and there's nothing wrong with admitting it.

[dalore]

Should "book now" be a button or a link?

It is an action, but it navigates you to the booking page. That page should have a url and should be able to be shared. But wanting to "book now" is an action and most sites have them as a button.

[kaoD]

I will reword GP: if your <button> onClick navigates to another URL, your button is not a button but a link.

[vinniejames]

There is no dilemma. 99 times out of 100 the user is expecting a link (aka a browser history update) and a way to get back to that screen (an idempotent collection of data on that url).

[kall]

That's actually a heuristic I often use to decide this dilemma: Would I want to open this in a new tab / copy the link? In terms of styling, I like to start both from zero so that a button "look" can easily be a link (like "learn more").

[wyqydsyq]

Yeah it's a trade-off and button links what this person would be experiencing.

General best practice IMO is any navigation link/button that is just some permalink like a profile page should be an a tag to support natural browser interactions like open in new tab or bookmark link, it also helps crawlers index your app if the interface in question is some sort of public directory you'd like indexed and has SSR. Only navigation based on ephemeral state (submitting forms etc) to things nobody would typically share a link to (logout URL, submit button going to a thankyou page) should be buttons.

[lstamour]

Yeah, another way of putting it is a link is great for GET requests while a button is better for POST requests (form submissions, AJAX, etc.) If you use a link for these, you have to think about what the href points to, you can’t just use JavaScript alone when it’s a link. If it’s a button, JS is more acceptable due to the inability to open new tabs, etc.

[no_wizard]

You’re leaving out major accessibility differences when using a button vs anchor tags