Live data from Hacker News

Remix – A framework focused on web fundamentals and modern UX

remix.run

71–80 of 307 posts

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

#71

I really wish there were frameworks that developed ways to plug in with your already favorite backend kit instead of solely isometric with Node. You couldn't pay me to give up Phoenix in Elixir for backend work but it does lock off a healthy amount of the neat things being done to make data loading on the frontend more optimal. Phoenix has LiveView + AlpineJS but I really don't want to give up React which still feels…

There's no strong requirement to use Node for your backend...your Remix codebase can fetch() data from anywhere in the `loader` function: https://remix.run/docs/en/v1/guides/api-routes#api-routes

I get that I can run this as a SPA, but then don't I lose out on the prerendered HTML fetched from the server? That's what I mean by isometric with Node.

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

#73
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, Sidebar, and Content into individual template files.
Remix highlights that Header, Sidebar, and Content are three separate components. Instead of loading the data all at once (#2 above) and then rendering all at once (#5 above), it allows you to load and render each component individually.

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

#74
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…

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 was in html files that also contained php, it was snarled mess. frameworks separate that to a large extent (one could argue angular/vue etc went backwards)

5. regression, aka CI/CD: there are actual testing flows today, unlike the 2000s

6. if you've been out for a really long time: reactivity. 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. This is a big step over PHP where you sprinkle magic server commands everywhere, and big step up over Jquery, where you have to target each DOM class/ID, which is tedious.

That being said I maintain a LAMP site, a pure-NodeJS site (get() verbs send back pug templates), and a NuxtJS website. I prefer developing the NuxtJS website (hot loading is sweet), but I can hack the LAMP site in a snap without touching literally everything; the NodeJS website is more aesthetically appealing in terms of architecture, but adding content to it is laborious.

EDIT: I'd go even further and say there is way more of a diaspora today. In the old days you could approach any website and basically understand what was going on in the frontened. Today there are layers upon layers of compiling/transpiling/parsing etc, that creates dozens of bespoke syntaxes. It is maddening, but I chalk it up to the fact that companies hire for the "hot new thing," damn the consequences, because their PMs are youngins too. There's a enormous lack of engineering discipline everywhere you turn. You will find many, many, MANY of the tools fail to even succeed at their own how-to guides because they have no real deep thought behind them.

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

#75
post #3

Earlier quoted context omitted.

They just did (maybe still going) Q&A session where they did a demo and answered question. Remix seems to be more like PHP or Ruby On Rails, it handles both server side functionality (calls to db, third-party APIs...) as well as the frontend code in a single file.

That can be done on NextJS as well using getInitialProps, getServerSideProps, or getStaticProps Some of the notable differences between NextJS and Remix are the following: - While both support file-based routing, Remix is baked with React Router -- giving developers the capability to declare custom routes without sticking to file structure conventions - NextJS banks on its static site generation to generate "cache-ab…

> NextJS banks on its static site generation to generate "cache-able" websites

Does it? You can still do traditional SSR in Next

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

#76
post #30

Earlier quoted context omitted.

Remix might be a few years too late to be honest. After watching the session, there does not appear to be any significant differences from Next.

the team behind remix probably has the biggest following in the react scene, so even without having any major differentiation (though I happen to think they do have) it's going to gain popularity.

I'd never heard of Remix before today. To contrast, I heard about Next 3-4 years ago, despite not using it at work until a few months ago

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

#77

Earlier quoted context omitted.

That can be done on NextJS as well using getInitialProps, getServerSideProps, or getStaticProps Some of the notable differences between NextJS and Remix are the following: - While both support file-based routing, Remix is baked with React Router -- giving developers the capability to declare custom routes without sticking to file structure conventions - NextJS banks on its static site generation to generate "cache-ab…

> NextJS banks on its static site generation to generate "cache-able" websites Does it? You can still do traditional SSR in Next

You can. I'm stating SSG in the context of caching and in comparison with Remix's approach.

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

#78

Earlier quoted context omitted.

That can be done on NextJS as well using getInitialProps, getServerSideProps, or getStaticProps Some of the notable differences between NextJS and Remix are the following: - While both support file-based routing, Remix is baked with React Router -- giving developers the capability to declare custom routes without sticking to file structure conventions - NextJS banks on its static site generation to generate "cache-ab…

It doesn't really promote its use, but it's exceedingly easy to use cache headers with Next.js if you're using getInitialProps or getServerSideProps. My issue with Next.js (alongside lack of nested routes) is that it has a handful of weird light abstractions which make things marginally easier for developers for the most common cases, but completely tie the hands of people who know what they're doing. To that end, Re…

While it is easy to use cache headers with NextJS -- as you said -- you have to know what you're doing.

It still boils down to use case, implementation, and quite possibly preference.

Personally, I'd still pick NextJS any time for any enterprise-level projects. Remix would be a fun little new framework to toy with for personal projects.

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

#80
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…

As a 47yo UI Designer and UX/User Centered Design Pioneer (CEO, PM, Business Owner, etc.), I have one rule of thumb towards "Cool JS/CSS/New tech":

I wait for the tech to become "Unavoidable" in Implementation practices.

Aside of "mental load", every new paradigm shift is measured in education/expenses/support time. So waiting for "market validation" is the only valuable option for me. This approach has saved a tons of money for my clients and thousands of hours in support/maintenance.

"Keeping up with the cool kids" is not valuable business decision, you can invest in systemic design knowledge and "proven technology" optimization.

Post reply on HN