Remix.run Logo
onion2k 12 hours ago

You don’t need big frameworks or component madness that’s more of the same.

You don't, but in any sufficiently complex app you'll end up writing a sort of 'mini framework' of your own as you abstract all the things that crop up more than a few times. That framework might be really nice at the start but it'll get more and more hacky as the project continues, especially if you're constrained by resources. Eventually you'll regret not using something standard.

If there are more than a couple of developers on the project it'll be something no one really likes after a year or two.

If there are more junior developers it'll be a reason for them to want to get off the team because they won't want to be a part of the 'old legacy code'. Then it'll be hard to find people who want to join.

Eventually, as it gets harder to recruit people to the team because it's on a weird, legacy framework that no one knows, there'll be a big project to refactor it on to something more standard. That'll probably be React. At the same time most of the senior developers will be calling to scrap the codebase entirely and rebuild it (wrongly in almost every case, but they don't care and want a greenfield project to play with new things on.)

This is a story that has played out at every large org that builds apps internally, and probably a lot of startups as they mature and need to hire more devs. You might as well skip all of it and use a standard framework from the start.

austin-cheney 8 hours ago | parent [-]

This has never been true for me. I never end up writing any kind of internal framework. Instead I write libraries that solve specific problems and achieve code reuse, which are really either functions or data storage objects restricted to their own files. At least, that’s how I think about code universally, libraries, but specifically in the browser this comes up less because the problem space is much smaller. Really in the browser it’s all about organizing code around event handling and putting text on screen. Let’s not over think this.

Anyways this idea of internal frameworks has always been weird to me. Nobody says this of code outside the browser, so why would they say this inside the browser? When I think about in those terms this clearly becomes a simple organizational problem and I don’t need a framework telling me how to organize things like a parent telling me to do chores.

WA 6 hours ago | parent [-]

What code are you using to reactively render state? Or do you write all DOM manipulations manually and just accept the problem of state explosion?

austin-cheney 5 hours ago | parent [-]

Here is an example: /lib/dashboard/dashboard_script.ts

https://github.com/prettydiff/webserver

When you aren’t using framework like components state restoration is a single function that runs only on page load. There is no state explosion and on localhost the SPA fully renders and finishes state restoration in about 105ms from http request.

WA 3 hours ago | parent | next [-]

Thanks, but this is a server-side thing and has nothing to do with client-side DOM manipulation?! Sure, you can put stuff on the server and do HTTP over the wire. It's oftentimes the better solution. But there are apps/tools that are rightfully an SPA (like tldraw or excalidraw for example) and can run local-first and offline in a browser. You build the entire app in JS and you'd need a bit more than vanilla Web components for that if you want to avoid client-side state explosion.

austin-cheney 2 hours ago | parent [-]

Look at the file path I specified. That file runs only in the browser.

brazukadev 3 hours ago | parent | prev [-]

Mate, if you are proud and happy to code this way, congratulations. That code is an absolute nightmare tho. Your eyes are trained on it so you think this is as good as an ergonomic framework.

austin-cheney 2 hours ago | parent [-]

How would you refactor it?