Live data from Hacker News

Remix – A framework focused on web fundamentals and modern UX

remix.run

271–280 of 307 posts

Re: Remix – A framework focused on web fundamentals and modern UX

#271

They lost me at: return ( {projects.map((project) => ( {project.title} ))} . . . I don't know why we need another framework that smashes together code and HTML/directive-based templates like this and, generally, keeps us bound so tightly to web idioms. Would be nice to have a framework that obscures these kinds of "web fundamentals", so we no longer have to wrangle such low-level primitives to build complex apps. EDI…

No, I didn't downvote you because I'm "suffering from a lack of imagination". I downvoted you because those "web fundamentals" are the web fundamentals. Putting another abstraction layer over it to obscure it does jack shit other than make your code more complicated. As long as I need to render a h1 or a div to draw anything on a web page, then I want control over the h1s and the divs. If there was a way to get away…

>I didn't downvote you because I'm "suffering from a lack of imagination"

The problem with suffering from a lack of imagination is you don't know you suffer from a lack of imagination.

The entirety of your comment is devoted to the current and past state of things. JSX is better because "template languages suck ass". You need to "render a h1 or div" to "draw...on a web page" or "add an element to the DOM", etc.

So, you're championing one approach because you think it's better than everything else that already exists. That's the definition of a lack of imagination.

>Putting another abstraction layer over it to obscure it does jack shit other than make your code more complicated.

I doubt you appreciate how many layers of abstraction already exist. But, per your logic we should all be writing assembly code.

You have it exactly backwards. There's no reason HTML has to be the target simply because that's what the browser currently consumes. If, tomorrow, browsers "natively" consumed something that was less document-oriented and more idiomatically app-appropriate, then will you understand? Would you be comfortable with coding to that abstraction level? Because everything you touch is essentially running in a VM. These frameworks could easily provide that layer versus the one they provide.

So try to get HTML and other "web fundamentals" unstuck from your brain. Imagine languages and platforms for building non-Web (e.g. native) applications and perhaps that will help open your mind a bit.

Imagine.

In any case, thanks for the comment versus just a silent downvote. FWIW, I upvoted you for that, even though your comment was poorly considered.

Re: Remix – A framework focused on web fundamentals and modern UX

#272

Earlier quoted context omitted.

> this seems like a rather off-tangent train of thought It's funny to hear someone complain about tangents on an HN thread. And, right on cue, as of this writing the top comment [0] literally starts with the phrase ”Off topic:" and has 7 replies. Irony aside, my point is very much on topic, as I am asking exactly the question, "what if teams like Remix had instead invested their considerable talents and years-long ef…

Perhaps it would help if you could clarify what you envision a "truly paradigm shifting approach to web dev" might look like? I'm legitimately asking. There's been a near-infinite variety of options tried thus far, both with and without "HTML code mashing". I'm not saying it's entirely impossible for anything truly new to be invented at this point, but given the constraints of what a browser is, I'm really not sure w…

>Perhaps it would help if you could clarify what you envision a "truly paradigm shifting approach to web dev

Really? You can't imagine even a single alternative approach?

Get inspired by Swing or even VB—really any ground-up app-building environment. The point is that we keep stuffing things back down to "web fundamentals" when what we're really building is apps, not web pages.

>but given the constraints of what a browser is, I'm really not sure what exactly you envision being suddenly invented

That's the problem--this idea of browser constraints. Again, free your mind of the browser and "web fundamentals". We're willing to transpile, Webpack, etc. but somehow still stop at coding to and thinking in HTML/DOM/etc.?

We can do anything and we're already effectively building on VMs. Why do this?

>why you feel a team that is knee-deep in React would suddenly turn around and go a completely different direction.

Man, I'm really not stuck on the idea that the Remix team should've done this. It was just a hypothetical when I said "Would really be interested to see what that same team could have created had they broken out of the React/SSR/etc. box." My point there is that a lot of talent/time is going into these incremental improvements.

So, I get that they're just giving the people what they want. I just think it's time for the people to want something entirely new.

Re: Remix – A framework focused on web fundamentals and modern UX

#273

They lost me at: return ( {projects.map((project) => ( {project.title} ))} . . . I don't know why we need another framework that smashes together code and HTML/directive-based templates like this and, generally, keeps us bound so tightly to web idioms. Would be nice to have a framework that obscures these kinds of "web fundamentals", so we no longer have to wrangle such low-level primitives to build complex apps. EDI…

This comment is at least 5 years late. JSX has been a thing for so long now and it works.

>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 template for never innovating on anything again. Just substitute anything you prefer for JSX.

I think I dramatically understated the situation when I said there was a lack of imagination.

Re: Remix – A framework focused on web fundamentals and modern UX

#274

Earlier quoted context omitted.

Perhaps it would help if you could clarify what you envision a "truly paradigm shifting approach to web dev" might look like? I'm legitimately asking. There's been a near-infinite variety of options tried thus far, both with and without "HTML code mashing". I'm not saying it's entirely impossible for anything truly new to be invented at this point, but given the constraints of what a browser is, I'm really not sure w…

> Perhaps it would help if you could clarify what you envision a "truly paradigm shifting approach to web dev Really? You can't imagine even a single alternative approach? Get inspired by Swing or even VB—really any ground-up app-building environment. The point is that we keep stuffing things back down to "web fundamentals" when what we're really building is apps, not web pages. > but given the constraints of what a…

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. Which of these are you actually asking about?

JSX has been argued about since React was first introduced [0]. It exists because React tries to stay "just JS" and use JS logic for flow control, rather than having a completely separate templating layer. Some people love that, some people hate it.

Drag and drop for laying out an app exists - there's multiple projects out there that allow a very VB-like GUI design experience for React components.

Modern JS build tooling exists to solve the multiple problems I listed earlier: insufficient standard library, building full-size apps with tens of thousands of SLOC and large teams, and optimizing deployment bundle and asset sizes.

HTML and CSS are the native language of browsers. You can certainly use canvas/WebGL to draw pixels on screen (and that's what "compile-native-desktop-to-WASM" demos do), but you lose all the built-in accessibility of HTML, and still have to reinvent all the widgets from scratch.

As for "breaking free of browser constraints and web fundamentals"... well, we _are_ talking about still delivering code to run in a browser, so what other options are there?

I'm genuinely not understanding what you're trying to envision or describe here. You seem to have a particular vision or set of ideas - can you describe what you're picturing more specifically?

[0] https://www.youtube.com/watch?v=x7cQ3mrcKaY

Re: Remix – A framework focused on web fundamentals and modern UX

#275

Earlier quoted context omitted.

This comment is at least 5 years late. JSX has been a thing for so long now and it works.

> 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.

Re: Remix – A framework focused on web fundamentals and modern UX

#276
post #191
post #179

Earlier 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 actually seems that Remix just wraps the form element with its Form element that prevents "the way html works" from happening and instead provides a loading/submission state to the UI while performing the form submission via fetch in the background. At least that's what the demo suggests.

I watched the demo and the guy kept saying if this was `form` (meaning lowercase), it would still work, which is misleading.

Honestly I don't see anything exciting about "supporting" form method because that's such a broken and limited way of doing UI. The assumption that every time you submit a form, it results in a request, or that the request is exactly what you put in the form, is false. Just because something exists in html does not mean it's the right way to do thing.

Re: Remix – A framework focused on web fundamentals and modern UX

#277
post #265

Earlier quoted context omitted.

I must not understand the question, because the answer is "the obvious way". You just run the V8 process once in each container and scale up your containers. There's nothing special to it. What are you concerned about breaking?

> I must not understand the question, because the answer is "the obvious way". You just run the V8 process once in each container and scale up your containers. There's nothing special to it. Interesting. So the idea is that the you scale identical instances of your app to increase both frontend and backend throughout? Sorry for the stupid questions. I am used to using a CDN for serving the front end and just scaling…

With something like Cloudflare Workers, your CDN actually becomes geographically distributed server instances. Since the work involved in actually serving the frontend code is never the bottleneck, it ends up working out pretty well.

Next allows you to compile the "static assets" and put them on a "dumb" CDN like say a typical Rails application. I don't think Remix supports this pattern at this time, but again, it does work with a perfectly reasonable alternative.

Re: Remix – A framework focused on web fundamentals and modern UX

#278

So, after looking over the docs, here's my comparison list between Remix (which I haven't used) and other things that I've used. - 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 was to use that instead of API endpoints. I hope that we soon see a Remix-compatible form validation libr…

From Ryan: "It's so fun to see people's takes on what Remix is. Especially the "this isn't any different than [x]" and I'm screaming from my office "open the network tab, slow down your network, click the button really fast, click back/forward really fast! then you'll see the difference!"

https://twitter.com/ryanflorence/status/1463241922168774658

Re: Remix – A framework focused on web fundamentals and modern UX

#279

Earlier quoted context omitted.

> Perhaps it would help if you could clarify what you envision a "truly paradigm shifting approach to web dev Really? You can't imagine even a single alternative approach? Get inspired by Swing or even VB—really any ground-up app-building environment. The point is that we keep stuffing things back down to "web fundamentals" when what we're really building is apps, not web pages. > but given the constraints of what a…

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, respectively:

1. Yes. JSX is flawed (for a different reason)*.

2. Yes. We should be building graphically

3. Yes. The tooling should reflect the paradigm

4. N/A. We shouldn't care about the underlying display layer (perhaps the most meaningful point)

5. Yes. It makes sense to run in the browser because ubiquity and standards. But a lightweight "VM" that translates from a more idiomatically suitable mental model/coding approach to raw web standards can be used to insulate us from thinking in HTML.

*JSX is flawed not by its design, but by the problem it's trying to address. That problem is emblematic of outdated, low-level thinking. I'm trying to push the discussion up a layer or two: that is, there is no need for a webdev to ever type an angled bracket.

Anyone who has ever worked in an app-building environment that's purpose-built for creating apps should look at that return statement in my comment at the top of this subthread and think "What the?".

So, again, if you're not seeing it, then one approach is to think Java Swing or similar for building web apps. And, it doesn't just end at a GUI builder. From event processing to component bindings, we should be dealing with higher level concepts, not web stuff like HTML-ish templates (irrespective of whether we rename them to **X because they're mixed with code and delivered via return statements).

Sure, there'll be times when you need an escape hatch to target lower-level constructs. But these should be rare and, even then, the available API should allow us to target these with clean idioms, not:

x = ''

If you're still not seeing it, I can guarantee you that in a couple of years we're going to have something much more akin to what I'm talking about. Maybe it'll be delivered via one of the low-code platforms or similar. JSX and the React-ish frameworks will soon-after be dead, or perhaps these environments will generate something akin to it on our behalf. I really don't care if React, et. al. get a second-life as compiler output. And, that's the point.

Re: Remix – A framework focused on web fundamentals and modern UX

#280
post #24

Nice. Defining multiple zones, each with their data and error boundaries, at little to no cost is a nice approach. Though as silly as it might sound, Remix’ publicity work has put me off it. Will read the docs anyway.

Same, the way they have went about "evangelizing" for it really left a bad taste

Honestly, same. I'm still going to give it a shot, because it does look interesting.
Post reply on HN