I guess now one can have markup, css, client side js, and server side js all in one file...
This seems like a potential huge plus to me.
Remix – A framework focused on web fundamentals and modern UX
281–290 of 307 posts
Re: Remix – A framework focused on web fundamentals and modern UX
#282Re: Remix – A framework focused on web fundamentals and modern UX
#283Earlier quoted context omitted.
> This comment is at least 5 years late. More like a few years early. Bookmark this. If you think JSX and screwing around with HTML-in-code is as good as it gets, you'll be laughing at your comment in a few years. BTW, I've been saying this since encountering the then-loved awfulness that was Angular 2. > JSX has been a thing for so long now and it works. That's a pretty spectacular statement — sort of a rallying cry…
Maybe I will be giggling at my former statements. Most likely, actually. But of all the things that need improving in the UI world, the templating itself is quite low down on my list of priorities.
Well, it's not just about templating (awful as that is). But, I hear you.
Re: Remix – A framework focused on web fundamentals and modern UX
#284Earlier quoted context omitted.
It seems like you're conflating a few different concerns here: - JSX as a paradigm for defining component display output - Drag and drop capability for UI design - How web apps are built tooling-wise - The actual display layer being used (HTML, canvas, etc, or at least that's what I think I'm reading) - Whether the browser is where these apps run at all (?) Those are all entirely different questions and concerns. Whi…
First, thanks for the thoughtful reply. > It seems like you're conflating a few different concerns here: > Those are all entirely different questions and concerns. What you're picking up on is that I'm talking about all of it, as my call is for a completely new paradigm , which necessarily upends everything. As such, these are not "entirely different concerns". They are tightly coupled concerns. So, to your points, r…
Okay, so what I _think_ you're saying here is that we should no longer be thinking about divs and spans and such as the raw materials we use to write a page, nor should we be writing HTML itself, but rather VB6-style "I want to drag a widget onto the layout screen"?
That does exist in some form today, between "low-code" tools and React-based drag-and-drop tools.
But then again, this also treads awfully close to the argument that "devs shouldn't be writing 'code' any more anyway, we can just hook together a bunch of boxes with arrows on screen and it all works". Thus far, those approaches still haven't taken over devs from writing code despite years and years of promises.
Re: Remix – A framework focused on web fundamentals and modern UX
#285Earlier quoted context omitted.
NextJS ships with both the built-in fs router AND a traditional imperative router. Also, there's a lot more to caching with NextJS than SSG.
Yes, NextJS does ship with an imperative router, but you cannot construct a custom route on the client-side without adhering to the core concept of building your routes based on the pages directory. I also agree that there's more to caching and SSG with NextJS. I'm simply stating some notable differences between NextJS and Remix, answering the top-most parent comment.
> "you cannot construct a custom route on the client-side without adhering to the core concept of building your routes based on the pages directory."
Actually, that's not true. You can opt out of the fs-based routing altogether.
Re: Remix – A framework focused on web fundamentals and modern UX
#286Earlier quoted context omitted.
> Forms seem better in Remix. Remix seems focused on progressive enhancement here, rather than fetch. Imagine if Next supported POST endpoints, and the idiomatic way of making your site Remix does nothing to make this happen, it's just the way html works. I dont see how it would not work on next. The difference is api is in a separarate directory and remix have them in the same file. Superficial.
It "wouldn't work" on next because your getServerSideProps receives a node http.IncomingMessage, and you would have to parse all of the form data yourself, or install a dependency to do it. Then you would have to write a second endpoint in a second file to be able to respond to a JS-enabled (fetch) request. Plus you get to implement all of the progressive enhancement yourself (state tracking, preparing that fetch req…
> Then you would have to write a second endpoint in a second file to be able to respond to a JS-enabled (fetch) request
This is only annoying if you prefer Remix's structure of putting the endpoint and the UI in the same route. To me I have no interest in making cookie cutter CRUD apps that map pages directly to API endpoints so this is useless.
Re: Remix – A framework focused on web fundamentals and modern UX
#287Earlier quoted context omitted.
First, thanks for the thoughtful reply. > It seems like you're conflating a few different concerns here: > Those are all entirely different questions and concerns. What you're picking up on is that I'm talking about all of it, as my call is for a completely new paradigm , which necessarily upends everything. As such, these are not "entirely different concerns". They are tightly coupled concerns. So, to your points, r…
Okay, so what I _think_ you're saying here is that we should no longer be thinking about divs and spans and such as the raw materials we use to write a page, nor should we be writing HTML itself, but rather VB6-style "I want to drag a widget onto the layout screen"? That does exist in some form today, between "low-code" tools and React-based drag-and-drop tools. But then again, this also treads awfully close to the a…
>Okay, so what I _think_ you're saying here is that we should no longer be thinking about divs and spans and such as the raw materials we use to write a page, nor should we be writing HTML itself,
Yes. It seems you grasped that some time ago, as you refuted it.
>this also treads awfully close to the argument that "devs shouldn't be writing 'code' any more anyway
Is Java Swing 'code'? WinUI? Was VB?
I don't think what I'm suggesting here is really that difficult to grok. But, hey I believe this thread has run its course. Appreciate the discussion.
Re: Remix – A framework focused on web fundamentals and modern UX
#288Earlier quoted context omitted.
Yes, NextJS does ship with an imperative router, but you cannot construct a custom route on the client-side without adhering to the core concept of building your routes based on the pages directory. I also agree that there's more to caching and SSG with NextJS. I'm simply stating some notable differences between NextJS and Remix, answering the top-most parent comment.
> "you cannot construct a custom route on the client-side without adhering to the core concept of building your routes based on the pages directory." Actually, that's not true. You can opt out of the fs-based routing altogether.
I'm not aware of said functionality on the client-side. Out of curiosity, do you mind linking me to said documentation or article on how to circumvent routing on the client-side without using fs-based routing?
Re: Remix – A framework focused on web fundamentals and modern UX
#289The person writing the doc seems to go out of their way to use let everywhere instead of const when appropriate. Where I work there is also a guy like that, curious is this some new "rethinking" trending opinion or what?
Re: Remix – A framework focused on web fundamentals and modern UX
#290Earlier quoted context omitted.
> Well, on a first page without any scroll you have action buttons which leads you to the pages where you can read at your own pace. For people who don't want that they've put small bits of information on each scroll. You're reversing the series of events. A user visiting a page (especially a homepage) expects it to offer relevant information in an easily consumable way. It is impossible for a user to automagically i…
I'm really glad I'm not working with UI/UX and project managers that you think would do that. Everything you stated is just your opinion (phrases like "anti-pattern" or "bad UX", "style over substance"), and that's fine. I don't find this homepage annoying. It's the opposite. I find it very informative. I'll for sure get involved with remix thanks to the great presentation and first impression they had on me. I'm doi…
If this is "the page that the title links to", it literally just gave me a headache. I am not sure why, something with how things moved in unexpected ways to me trying to scroll, I think.
If that is Great UX, I think I prefer bad UX.