|
I hate to sound elitist or whatever, but I’m just tired of seeing a blog title something about writing a scalable or “enterprise” web app and the content almost always being “write modular code, write comprehensive tests, and don’t write spaghetti code though usually through the veil of domain drive design jargon (whether or not they don’t use the term DDD or they are literally quoting Dr Bob blog posts and including vague graphics showing the “boundaries”). But, any decent developer will literally come to the same realizations after spending a significant amount on anything that’s not a toy/pet project. I also get that not everyone has had that realization and this blog may be insightful/helpful to them, it’s just not the content I was hoping to come across as it’s something I’m very interesting to hear what others are doing. I’m not going to pretend I’m some hardass enterprise engineer, but my only time spent on frontend work these days are on two different applications that solely exist because the actual enterprise software sucked so much that these applications exist. So, I like to think I at least have an idea. As over the years the features have been added to the apps, and more of the “fun little quirks” in the data. Which is why I want to hear how real “enterprise” level frontends are being handled. Believe me, I know the value of keeping my code modular, and I really know the value of keeping logic out of presentation, but if working with enterprise software, and software that’s deployed to 30+ different departments to standardize and centralize processes they’ve been doing themselves for 50+ years (under the guise of “making their jobs easier” but really they central office where just tired of having to deal with the random of assortment and varying quality of data, lol) there’s always another edge case. I cringed when they mentioned that using one of the big frameworks, and forgoing global styles, because after a couple years of “the frameworks built in css isn’t totally the way we need it” (or more likely, “fucking updates broke the UI on a minor release for no reason”) or “oh using the current components we use to do that don’t take data that way or return it the way we need either, and it’d take too long to replace, just create a new set for this feature” it’s not going to be the nice paradise where everything is siloed off just like in Uncle Bob’s blog. I just this week got sick of UI framework’s because the built in component I needed wasn’t able to handle the task in the exact right way, so I had to make adjustments to it, and I’m just that’s never going to break in the future... not to mention that absolutely none of them are really doing any more than the bear minimum accessibility wise, which is one of the reasons to use a framework was to eliminate that boilerplate. So, I just started tinkering with the new Vue3 composition API to build a UI framework that literally has no styles attached just dom elements that know how to setup their aria-attributes, handle keyboard events so a mouse isn’t the only method, etc (as well as if they weren’t passed given enough information to make themselves complaint with the aria guidelines). To style them, I’m just going to make pass in a list of tailwind classes in a config files at build time, that they can (optionally) but will in no way the actual core framework itself is dependent on. I just want to hear how some real enterprise team are managing their frontend (and more importantly their commentary — I can find code online but without the context it’s not the same) when they have 100x the amount of edgecase legacy bullshit I have to deal with and likely 1000x the burden of buroqracey |