[jscholes]

> That's only if you want to take advantage of the hydration and client side routing.

I feel it would be doable for a framework to determine which links should be client-side routed versus not. Or, failing that (or in conjunction with it), provide a way for developers to indicate that information, without reinventing a cornerstone of the web and HTML mark-up from scratch.

[armandososa]

> I feel it would be doable for a framework to determine which links should be client-side routed versus not

I think that is worse. Replacing a core html element behind the scenes to do a `history.pushState` is like to monkey patching. This way you can still use <a> elements and everything will work just fine, or you can very deliberately use a <Link> element if you want the extra functionality it provides.

Same as with the <form> element which will work just fine in Remix as if it was a 2005 PHP project. Or you can use Remix‘s <Form> component which does all the "AJAX" magic behind the scenes that you'll spend two weeks adding to your 2005 PHP project.

[pier25]

That's probably what they would have done if starting from scratch, but Remix is built on top of React Router which is a 7-8 year old project with its own idioms.

Also, Remix is for React developers. It's expected you will use JSX, components, etc.

Personally I have a toy client-side router for Svelte. Links that need to trigger client-side navigation simply use a Svelte action:

<a href="/" use:link>Home</a>

https://github.com/PierBover/roots-svelte-router

[vagrantJin]

I agree with your point.

I dont know what it is about some devs aversion for HTML.

But a anchor with a data attribute should more than suffice rather than creating over-engineered abstractions.

But then again, not many devs even read the HTML docs.