5 ms·

They lost me at: return ( <div> {projects.map((project) => ( <Link to={project.slug}> {project.title} </Link> ))}

They lost me at: return ( <div> {projects.map((project) => ( <Link to={project.slug}> {project.title} </Link> ))} <Form method="post"> . . . </div> 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. EDIT: The people downvoting this are suffering from a failure of imagination. Sure, Remix may be an improvement over some current frameworks' failings, but there's no reason improvements need to be so incremental or debt-bound.

newsbinator 5y ago
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.
elwell 5y ago
Try ClojureScript + Re-frame
dcre 5y ago
This is just React.
BigJono 5y ago
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 from that then sure, I'd be all for it. And "smashing together" code and templates is the best thing to ever happen to web development. Template languages suck ass, they rely on thousands of lines of build time magic to work. JSX is a line for line transform (which is as simple as the build time logic can get while still enabling any sort of templating whatsoever), that conceptually maps back to a simple call to add an element to the DOM some time in the future. As soon as you get over the "ew, code and "html" together" reaction, you realise that "everything as code" is the easiest way to just completely avoid hidden complexity and surprises.
- unclebucknasty 5y ago
  >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.
gherkinnn 5y ago
This comment is at least 5 years late. JSX has been a thing for so long now and it works.
- unclebucknasty 5y ago
  >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.
  - gherkinnn 5y ago
    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.
    - unclebucknasty 5y ago
      Well, it's not just about templating (awful as that is). But, I hear you.
mclightning 5y ago
I guess nostalgia is a powerful force in JS world.

newsbinator 5y ago

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.

elwell 5y ago

Try ClojureScript + Re-frame

dcre 5y ago

This is just React.

BigJono 5y ago

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 from that then sure, I'd be all for it. And "smashing together" code and templates is the best thing to ever happen to web development. Template languages suck ass, they rely on thousands of lines of build time magic to work. JSX is a line for line transform (which is as simple as the build time logic can get while still enabling any sort of templating whatsoever), that conceptually maps back to a simple call to add an element to the DOM some time in the future. As soon as you get over the "ew, code and "html" together" reaction, you realise that "everything as code" is the easiest way to just completely avoid hidden complexity and surprises.

unclebucknasty 5y ago
>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.

gherkinnn 5y ago

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

unclebucknasty 5y ago
>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.
- gherkinnn 5y ago
  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.
  - unclebucknasty 5y ago
    Well, it's not just about templating (awful as that is). But, I hear you.

mclightning 5y ago

I guess nostalgia is a powerful force in JS world.