Live data from Hacker News

Remix – A framework focused on web fundamentals and modern UX

remix.run

131–140 of 307 posts

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

#131

Earlier quoted context omitted.

Yeah, other than the nested route thing, there doesn’t seem to be that much difference between Next and Remix when it comes to talking to a database.

Next.js has had nested routes since version 6. Not sure I see the difference in what Remix is offering? https://nextjs.org/docs/routing/introduction#nested-routes

I don't think the nested routes mean the same thing on the NextJS page. To my knowledge, NextJS doesn't support nested routers which is really what many are after. Like in the Remix demo, there are various content areas with nested content, which would be controlled by the URL. You can create url parameters manually like /account/:tab/:id but it's kinda hacky as you have to use router.params['param-here'] to get the parameter and the handle the rendering yourself. You'd really want an account router to handle each tab in the account area, and then each tab in that area has its own nested router than can display the relevant content (based on the ID of the invoice for example).

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

#132
From their contributing page: https://remix.run/docs/en/dev/contributing

> "We need you to "sign" a contributor license agreement (CLA) first that assigns us ownership so we are able to include it in this software. We don't yet have a CLA, but we are working on it and we will be able to accept your contributions as soon as we do."

Apparently, requiring a CLA isn't as uncommon as I initially thought, but I'm still curious why some projects require this but others do not. What about their business model / licensing choices necessitate a CLA?

https://en.wikipedia.org/wiki/Contributor_License_Agreement

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

#133

From their contributing page: https://remix.run/docs/en/dev/contributing > "We need you to "sign" a contributor license agreement (CLA) first that assigns us ownership so we are able to include it in this software. We don't yet have a CLA, but we are working on it and we will be able to accept your contributions as soon as we do." Apparently, requiring a CLA isn't as uncommon as I initially thought, but I'm still cur…

It's common for open source libraries that use split licencing. By assigning copywrite ownership to the project, they are able to licence your contribution however they like. Without a CLA, any licence change, sub-licencing or commercial terms would need to be negotated with every individual that has contributed code to the project

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

#134

Earlier quoted context omitted.

Frameworks are designed for the following (this is obviously an incomplete list): 1. large teams (not just one webmaster, circa 1999) 2. tooling like syntax checking, style enforcement, minification, and transpiling 3. component-based development & reuse; forces smaller files which are easier to lint and test 4. separation of concerns. in the old days there was one Apache www folder and everyone took a big shit in it…

> JavaScript allows getter/setter methods that can update the DOM when a value changes; this includes before/after and around-like methods that can integrate AJAX calls in a VARAIBLE name. e.g., you access the variable and an AJAX call fires and updates your DOM when the data returns with you doing ZERO coding. Maybe I'm old but that sounds TERRIBLE. When my code is doing something expensive like a network call, I wa…

Sure, that's one way to look at it.

Another way to look at it is you just removed 300 lines of buggy redundant code into one line that does exactly the same thing but without all the fuss. And now that your code is so small you can understand it better, and test it.

Also, there's this "new" thing called async/await: javascript is built on deferred execution, so you don't block on expensive calls. PHP is a dinosaur.

Reactivity is mostly used for managing the DOM in a natural, non-intrusive way, and my AJAX example is maybe extreme, but a good illustration. I'd say that concept in the frontend is biggest invention since 2010.

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

#136

I wonder how Remix ranks next to Blitz.js[1] or Redwood.js[2]. They seem like they're all trying to do similar things. [1] https://blitzjs.com/ [2] https://redwoodjs.com/

Yes, definitely different takes on the same problem! We could make a comprehensive list of all the differences, but the end result is that you can use all three (four if you include Next.js) to build any web app imaginable. At the end of the day, you must try them each for yourself and find which one resonates most with you and your team.

Thanks for the reply. Honestly, I'd love to see such a list, or even a short summary of each that provides as solid intuition as to why I might choose one over the other.

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

#137

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…

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.

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.

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

#138
post #118

I remember the team had the idea of charging for the software but now I am seeing that they raised VC money. There is no question that this sort of company can be big (See Vercel) but I'm wondering why this decision was made?

because this sort of company can be big

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

#139
post #60

So as a 56yo "old school" LAMP-stack monkey, could someone please give me a quick rundown exactly what benefits would investing the mental energy (a non-trivial amount) and time (less an issue) give to someone in my ancient yet comfortable canvas Cons? For sure next.js is an interesting framework and of course I use plenty of typescript in my projects to keep the UXs from feeling stale, but I have yet to see the over…

I think this new wave of server-enabled React is enabling codebases that are better organized than old MVC stacks. The MVC way was: 1. Look at the route 2. Recognize that this route has, e.g. A Header, A Sidebar, and Content 3. Load the data for the Header, Sidebar, and Content 4. Pass the data to the templating engine 5. Use the templating engine to render the route, which likely fans the data for the Header, Sideba…

[deleted]

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

#140
Java/React dev here. This seems great for a small app. But could someone help me understand how this would work in a large scale app? It looks like the some pieces of the JS make up the server side API of this and it runs in a V8 process. How would you deploy a production version on AWS and scale those à la ECS Fargate containers against RDS?
Post reply on HN