4 ms·

I don't mind vouching for this comment because it does further the discussion. It's a lot more interesting that the "let's should be lets" comments.

unclebucknasty 5y ago
Hey, I appreciate that. I noticed in another of your comments you mentioned it seemed similar to Nuxt.js and you were digging in further to look for differentiation. That's kind of what I'm getting at here: things in this space are moving needlessly incrementally at this point, creating so many permutations on largely the same underlying themes and staying pinned to original Web semantics. Why do we accept HTML as an app UI "language"? Is that what we would choose if spec'ing for that use case today? So, why do we introduce all of these new layers, complete with webpacking, transpiling, etc. only to continue surfacing such ill-suited low-level constructs in our code? That's not to say the Remix team aren't good people or haven't made real improvements here. Reading further, I see where they're creating value, and the testimonials seem to be inspired. So, it seems successful for what it is, but that's all relative. What I'm suggesting is that it's time for a paradigm shift in Web development. Would really be interested to see what that same team could have created had they broken out of the React/SSR/etc. box.
- acemarke 5y ago
  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.
  - unclebucknasty 5y ago
    >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. [0] https://news.ycombinator.com/item?id=29313460 https://news.ycombinator.com/item?id=29313460
    - acemarke 5y ago
      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.)
      - unclebucknasty 5y ago
        >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.
        acemarke 5y ago
        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 https://www.youtube.com/watch?v=x7cQ3mrcKaY

unclebucknasty 5y ago

Hey, I appreciate that. I noticed in another of your comments you mentioned it seemed similar to Nuxt.js and you were digging in further to look for differentiation. That's kind of what I'm getting at here: things in this space are moving needlessly incrementally at this point, creating so many permutations on largely the same underlying themes and staying pinned to original Web semantics. Why do we accept HTML as an app UI "language"? Is that what we would choose if spec'ing for that use case today? So, why do we introduce all of these new layers, complete with webpacking, transpiling, etc. only to continue surfacing such ill-suited low-level constructs in our code? That's not to say the Remix team aren't good people or haven't made real improvements here. Reading further, I see where they're creating value, and the testimonials seem to be inspired. So, it seems successful for what it is, but that's all relative. What I'm suggesting is that it's time for a paradigm shift in Web development. Would really be interested to see what that same team could have created had they broken out of the React/SSR/etc. box.

acemarke 5y ago
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.
- unclebucknasty 5y ago
  >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. [0] https://news.ycombinator.com/item?id=29313460 https://news.ycombinator.com/item?id=29313460
  - acemarke 5y ago
    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.)
    - unclebucknasty 5y ago
      >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.
      - acemarke 5y ago
        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 https://www.youtube.com/watch?v=x7cQ3mrcKaY