[flufluflufluffy]

I find Remix really nice to work with, it’s a framework that embraces and utilizes web standards (what the article is arguing we should get back to doing more), and I’ve learned everything I know about it (and the majority of everything else I know about front end dev) for free. It’s not like you need to purchase courses to learn. At the same time, I don’t think there’s anything wrong with selling courses to teach people about a framework. But the idea that the entire thing was created just to sell courses about it is not true.

But I do agree that there’s just way too much fast moving, breaking changes on front end in general, frameworks released every other week, etc…

[nullpoint420]

But it _doesn't_ use web standards. It has it's own mental model and gotchas just like any other framework.

[uhoh-itsmaciek]

It does. It bridges a purely server-rendered architecture with a SPA really nicely, and does it mostly with web standards. You don't need to run any client-side JS with a Remix app. It's not perfect, but there are a lot of benefits to its approach.

I won't try to argue there's no front-end treadmill: there absolutely is, and I had to laugh reading the current top comment because I just had to migrate off Apollo CLI at work.

But this "The web was perfect in 1999--stop changing things!" take is tedious and intellectually lazy. (I'm not accusing you of it, but it's certainly a common sentiment.)

We should be working together to solve concrete problems, and avoid both chasing the latest fads and pretending there's no room for improvement.

[bloomingkales]

It’s a nuanced topic. If we want to dive in, I can provide a glimpse into the first layer of the anus as we stick our head into it.

When we shepherded a lot of sheep into frontend via these courses and boot camps and quasi courses/bootcamps in the form of certain frameworks (hey, you only know this one framework?), we created a cohort of something.

Now what is that something? It’s not really the tinkerer that loves doing this stuff and would have found a way to express themselves (please pay attention to the word “express”, as in, can’t help it). That something was … a pragmatic identity. A pragmatic identity was formed where “I am now a software engineer because I and my cohort agree, we really know how to do our stuff”.

Such a cohort can only be fueled by identity, not passion. This cohort can’t innovate and must cling to the identity of their original accreditation, so they will always be defensive.

That’s the first layer of the asshole as we enter it, it goes deeper. The second layer involves large amounts of money and people’s livelihoods, to which they’d defend unto death.

[uhoh-itsmaciek]

I don't believe you want to have a productive conversation about this. It sounds like you just want to be angry.

[bloomingkales]

Okay? I'm having a lot of fun talking about some of the parts of our circus. I can't change anything. There will be new cult leaders (evangelists) for frameworks, and new cohorts, we can't change the past. Just pay attention to the rough framework (no pun intended, swear) as it happens again, and try our best to call it out, because it didn't always lead to great outcomes.

Money will be made on all sides regardless and we will all be fine financially. I'm talking about something else, inner. The infinite anus, asshole, is real - but now I'm just projecting.

[nullpoint420]

> mostly with web standards

IMO, the pain from "mostly" starts to show when integrating React Router v6 with legacy frameworks and applications. I'm sure if you go all in on React Router v6 it's great.

At my $DAYJOB we are migrating to Remix w/ GraphQL Federation. It's been a pain.

Especially because we haven't finished any of these migrations:

* ExtJS -> JQuery

* JQuery -> React class components

* React class components -> MobX-observed components

* Observable MobX components -> functional React components with context

* Functional React Components with context -> React Router v6

* React Router v6 -> Remix w/ GraphQL federation

I understand my situation is unique - I'm just bitter from needing to know ~6 different frontend technologies at once. Let alone all the Not-Invented-Here-Syndrome abominations in our codebase.

[sodapopcan]

It's not that unique. The one enterprise app I worked on (that was started with Rails 1) had all of: Prototype, jQuery, Backbone, Angular, React, Handlebars AND mustache, vanilla CSS, SASS, CSS in JS (or whatever it's called). I wouldn't be surprised if they've introduced Tailwind at this point.

[nullpoint420]

This is also a project started w/ Rails 1, so I feel our experiences may be similar.

To be fair to both code bases - it's very impressive that they're still running, right?

[sodapopcan]

Definitely!

It actually wasn't even THAT bad considering how huge it is. People still complained (admittedly myself included), but it had been TDD'd from the start so had very good test coverage, at least. Also, some people who had worked on really massive Java applications called it "really good!" so it's all about perspective, I suppose :)

[koakuma-chan]

Remix already has data loading, why add GraphQL? It's a pain in the ass to work with from my brief experience.

[nullpoint420]

That's my point exactly. I have the same questions from leadership.

[apsurd]

your last note that adds not-invented-here abominations… if chasing endless frameworks of the month is bad, and building stuff in house is bad, then what do you propose to avoid making this mess?

[nullpoint420]

I would propose that if you want to change frameworks, actually complete the migration from one technology to the other.

My problem is having all of them existing at once.

[zaphar]

Skip a couple framework versions and indeed entire frameworks. Maybe go a couple years before you "upgrade" to something else. It is entirely possible you could go as much as 5 or 10 years on something. You'll still have to evaluate and potentially mitigate some CVE's. But that could actually be less work and less aggravating.

[nobleach]

But it's based on the fetch standard and formData submission. You're literally running a server that handles those two things.

[nullpoint420]

My point being, it's "based on" Web Standards, it is _not_ Web Standards.

What if I use `fetcher.submit(data, { encType: "application/json" })`? Why not just use fetch directly at that point? I believe it adds a layer of indirectness that just wasn't there before.

If web standards are so important, why don't we use `window.fetch` and `new FormData()` directly instead of wrapping it?

[nullpoint420]

My favorite example of this being JSON gets converted to FormData on the frontend, which then gets POST-ed to the server, which then converts it to JSON on the backend.