That's only if you want to take advantage of the hydration and client side routing.
You can of course use regular <a> links and navigate to a new page every time.
You can of course use regular <a> links and navigate to a new page every time.
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.
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.
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>
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.