[ianbutler]

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 more productive to me.

This looks neat but just like NextJS and Sapper it will not nicely play with my stack.

[rokob]

You might be interested in inertiajs: https://inertiajs.com/

It only technically is built for Rails and Laravel but reading the “spec” and the code I got it to work pretty quickly with a Rust backend.

It would be nice for more of these frontend niceties to be built around an API contract rather than a particular JS on the server implementation.

[nine_k]

I'd say that framework are like, mmm, rails. (RoR was a genius and very candid name.) They allow you move fast and safely as long as you move in the direction the creators if the framework had in mind. Their keyword is cohesion, and their drink is kool-aid.

When you need to move in a slightly or severely different direction, you're better of with a set of libraries. They allow you to build a contraption that matches your unique problem space. They require much more time and thought to achieve the first results. Their keyword is composability, and their drink is a cocktail.

At the start, or if you are a contractor, you want something really fast, so a framework is usually inevitable, unless you're overqualified.

Down the road you keep needing to move across the rails, so you slowly switch to using more libraries.

[mrkurt]

We've done some "fat app servers" that consume GraphQL APIs. You could build a Phoenix + Absinthe app, then consume it from something like Remix.

The real problem is switching languages. I sure get slow when I change from Elixir to JavaScript. There's not a bright line between backend/frontend in a fullstack app, so I've been much happier minimizing how often I have to switch languages.

[jkcxn]

It’s definitely possible. I have a project that does the same thing with Python and React but you could switch out the backend to anything that outputs html. The cool thing is your front end is just super modular components and your backend does all the heavy lifting, can talk directly to your DB and you don’t have to write a single API. Was thinking of putting something open source together, let me know if that might be of interest

[rolisz]

Yes, it would be if interest to me. I've been looking for something similar lately. One thing that I found is https://github.com/ChrisKnott/Eel but it's more geared towards making desktop apps

[jkcxn]

Can I contact you? My email address is in my profile

[nelsonic]

We're in the same boat. Wouldn't give up Phoenix on the backend for anything. We are gradually adopting LiveView with great support for components. Have you tried it?

Agree Remix looks good though!

[colinclerk]

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

[Grimm1]

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.

[kall]

Well you could run it as a sort of rendering layer in front of your backend, and talk to your phoenix app on an internal API or local socket. May not be worth it though. Unlike next, I don‘t think you can even run this as SPA only.

I think for remix to be able to do what it does, it kind of needs to run as a JS (not node!) backend, because a big part of it is running react on the server. Also, you are literally writing the server and client code in the same file. Closure and Reason which have strong react ports/bindings might be able to do it, but otherwise I don‘t see how.

What other backends need is probably a totally different framework, that wraps up a react server renderer with native language bindings. Might be neat, but totally different.

[couchand]

I think the term is "isomorphic", as in having a single form.

[Grimm1]

Ah yup you are definitely correct, that is what I meant.

[arcturus17]

Why don’t you just return JSON from the server?

I agree with you in the sense that I don’t want to write server code in Node since I like batteries-included frameworks (Django)…

I guess you’re talking about features like form validation and whatnot?