Given that the entire Remix team has spent the last several years doing training teaching people how to use React, and building one of the core libraries in the React ecosystem, this seems like a rather off-tangent train of thought and unrealistic expectation for what Remix might have been.
>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 efforts in building a truly paradigm shifting approach to webdev?"
What I'm suggesting here is that it's time to advance the state of the art in Web development. But, I could certainly be wrong. It might instead be time for another incremental improvement in the React/Vue/Angular-ish, HTML/code-mashing, shadow DOM-rendering, SSR-driven, reactive framework universe.
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 what exactly you envision being suddenly invented at this point that would be radically different. (Or, tbh, why you feel a team that is knee-deep in React would suddenly turn around and go a completely different direction.)
>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.
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?
>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 = '<div>'
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.
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.
>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.
