Hacker News Reader

I think I will never understand, how people write their code in such a messy unorganized way, that it becomes unclear, whether touching some piece of code changes the behavior on 50 other pages. To me that reeks of badly structured code, with bad abstraction layers, perhaps stuffing too much stuff into a single module or, if the language is still backward and doesn't have modules, a file. Especially for websites, the path to rendering a page should be pretty clear. Have some weird JS requiring menu functionality? Well ... put it in "menu.js". Will it affect 50 other pages? No, it will affect the menu. Or yes, if you count the menu as part of those pages. Have some video player stuff? Well it is going to affect all pages where there is the video player. Something for forms? All pages where you have such forms. Then there are things like maybe animations or checkbox states. But I fail to come up with examples, where the scope of the change is so unclear, that one can't relatively quickly figure out what will be affected and what not. It must be some WordPress mess or something. Then I can imagine it. But with a site built from ground up? Nope, must be bad design or structure.

Of course you could just have made up that example as a straw man as well.

> To me that reeks of badly structured code, with bad abstraction layers, perhaps stuffing too much stuff into a single module or, if the language is still backward and doesn't have modules, a file

Yes and that’s normal. Big ball of mud is the worlds most popular software architecture.

Original: http://www.laputan.org/mud/

My modern take based on the original: https://swizec.com/blog/big-ball-of-mud-the-worlds-most-popu...

> Well ... put it in "menu.js". Will it affect 50 other pages? No, it will affect the menu

MVC frameworks, used traditionally, don’t support this super well. If you want some dynamic value in the menu supplied by the backend, every view has to make sure it passes that value into the template layer. Change the menu, gotta go around changing every view to supply that new value.

MVC with jQuery or some SPA framework at some point you have to consider why the menu is tied to the view at all, and not deriving its state from the user session. I'd say in either case who decides that (and who rewrites it) is equally messy. The nice part about SPAs is you can usually slice off that functionality and give it to one set of developers to deal with in isolation much easier than you can with an MVC structure.

> why the menu is tied to the view at all, and not deriving its state from the user session

Yes! But it turns out in some of these frameworks “the user session” is not a magic global, your view has to pass it into the template.

And even if it was a global, you are super limited in how much derived data/queries you can compute off of it. Because you’re not using a full-powered language – instead it’s jinja, mustache, or similar.

This is doing the same thing described in the GP of your comment.

If 1/few people are building a site so simple that the menu code is in "menu.js", then sure, separate your code and go about your day. But when 30+ FTEs are building a huge app with lots of tightly interconnected features, then the complexity is there no matter how you architect your code - it's part of the business requirements. Like GGP said, they're different domains, and stuff said about one doesn't necessarily apply to the other.

Nailed it. And a lot of people who say "this sounds like an application, let's pick an application framework to use" from the start are people who have experienced what you're currently experiencing. But it's very hard to describe in a compelling way to someone who has never had the same experience.

Oh I was hired because I’ve been here before and know what to do. It’s fast becoming a career specialty lol

But the "looks like not an app, maybe we should not use an application framework" tends to be silenced by "React bootcamp people are a dime a dozen so let's use what they know".

Maybe. Personally I haven't come across this phenomenon. But I haven't worked on this type of system in a very long time, so it's probably different perspective from different experience.

>A good example are pages that take 5 seconds to load because they have to do so much, then you submit a form, and the page reload takes 5 seconds to go through but there is no UI feedback so you press the button a few more times because maybe it didn’t work? Then you get an error because the first action worked but the subsequent actions failed due to uniqueness constraints.

It's been standard practice for at least 25 years to disable the submit button once it is pressed. If you aren't doing this as a developer, you are practically begging for trouble, and it's really so easy to avoid that trouble.

Lots of people build stuff and don’t have 25 years of experience. Or it seemed like “unnecessary complexity” when the app had 5 users and interactions took 100ms.

A lot of standard things feel like “wow people are way overthinking this, it’s so easy” when you have 5 users :)

Whoever taught them wasn't doing their job well.

At least adding in the feature once you notice the problem shouldn't be difficult.

Or disable the component completely until you receive a response.

I agree with you about the customer-facing issues which occur with vanilla sites which don't deliver good user experience.

However, I'm interested in how frameworks solve the developer experience problem you mentioned:

> Will this javascript file you touched affect only the feature you wanted, or another 50 pages you didn’t even know about?

> When you add a new thing in a template, how many N+1 issues across how many pages did you just cause?

> Where does the data even get loaded??

Doesn't this just change into

- "Will changing this React component affect only the feature I want, or do other pages interact with it differently?"

- "When adding a new component into a template, will I break any other pages which use this template?"

- "Where does the data even get loaded??"

> Doesn't this just change into /../

Yes and no!

TypeScript helps a lot – you get quick traceability of where things are used and squiggly lines, if you break a contract. Yes a statically typed MVC framework would get you this, but in my experience the apps that get into this mess also don't use types "because types add too much complexity" (likely true for that company stage).

Componentization brings the other piece – self-contained components that declare their own data dependencies (load their own data), bring their own isolated styling, and generally handle all their internal behavior. This takes some skill/experience to get right and yes you can totally pull it off with every toolstack if you're good enough. The benefit is having a stack that encourages you to think about interfaces and contracts between components and hiding the messy internals from the outside world.

So for example in Flask I'm encouraging this pattern of tiny composable views: https://swizec.com/blog/a-pattern-for-composable-ui-in-flask... Once you have these, you can then move them in and out of the page with some JavaScript and an Ajax call. HTMX does this afaik and it's also how we used to build PHP+Ajax apps for a brief moment 20 years ago before client-side rendering took over for various reasons (smaller payloads mattered back then as did sharing an API between web and mobile)

edit: Point is that an approach based on composability guarantees that components won't break each other, can be moved around, and can live side-by-side without worry. The more your stack can guarantee this (as opposed to manual vigilance) the better.

Thankfully, there's a bunch of great and "easy to get going" languages now that __also__ have types (or optionally encourage them) that the "don't have types" thing isn't as much of a forced issue anymore (though engineers can still choose to go type-free and eventually face the wrath of lack of types in a large-scale project)

I’d approach this with a wizard-style (step by step) interface and transactions—orthogonal to JS framework.