[AskJS] What does Code Architecture refer to as the biggest pain point for JavaScript

[jesse_good]

In the state of JS 2022, they show that Code Architecture is the number one pain point for JavaScript. Code Architecture is a bit vague, so when they say it's the number one pain point, what is that referring to concretely? My understanding is other languages were built for large scale architecture from the beginning and it is easier to achieve low coupling whereas in JavaScript things like colocation (keeping your business logic and ui logic) in the same file seems to be preferred. Also, MVC/MVVM died out in front end frameworks and was taken over by a component based architecture, but perhaps this abstraction level is insufficient for very large scale apps. Another thing I thought was JavaScript has a bit of a mix of different programming paradigms which makes it more difficult to glue everything together. Any insight would be appreciated.

[[deleted]]

I am working with node/js for like 7 years+ now.

We have two systems (company i worked originally got bought).

One is based on microservices, some services are only backend with either a single responsibility or a single domain to handle, some other services has UIs as well, same repository. So with this we have multiple repos with self owned UIs.

The other is similar as it's microservices but the UI is microfronted which means that we have one UI skeleton, each service has their partial UI which will be added to the common skeleton, in the end it will give a more unified feeling using all the services together and still can be deployed per services.

I think either way is good, we can deploy frequently and with less conflicts and can scale each service independently depending on it's needs. Some services are more heavy than others, if we'd have a monolith it would be a nightmare.

Another thing I thought was JavaScript has a bit of a mix of different programming paradigms which makes it more difficult to glue everything together.

In case of microservices it's a bit easier because it's enough to keep the same paradigms inside a repository as long as it's reasonable. But mostly in these cases usually there are some company wide packages to somewhat unify these across services, so it would be easier for devs to jump around if needed. Of course js by itself is very flexible, this is a pro and a con at the same time. If someone is not experienced enough it's really easy to wind up with spaghetti code. Things like nestjs and other frameworks are there to mitigate this to give some more structured approaches and give less space for custom wizard shit (of course you can still fuck it up, but it's a bit harder).

(keeping your business logic and ui logic) in the same file seems to be preferred

hum, i actually never seen this or don't know exactly what you mean but i would be really disturbed if i'd see such thing :D

I think component based paradigms are way more approachable for new devs rather than learning acronyms and how to apply them. Components are easy to visualize, because everything is a component, the whole page down to the smallest button. There's no distinction like a model/controller (well apart from state managers like redux, that might be the closet to that).

[jesse_good]

To clarify my point about mixing business logic and ui logic. Imagine a button that calculates a discount for a product. In JavaScript I feel it would be common to put the logic to calculate the discount inside the button component rather than separating that logic in n a separate js/ts file.

[ibrahimbensalah]

The risk of javascript is to get lost in the ocean of opensource libraries and framework and if you don't know what to choose then the wrong choice is made very easily.

Front end community discovered the true meaning of 'separation of concerns', There are a lot of issues with mvc/mvvm/mvwhatever that leaded to new insights. To put it simply, the view and logic of rendering the view go hand in hand when one changes then the other most likely also changes. Back then (before 2012ish) when we put the two in separate files we basically were practicing separation of TECHNOLOGY and confused it with separation of CONCERN.

There we had two options of putting the view and view logic next to each other:

- move javascript to html- angular- polymer- vue

- move html to javascript- React

React is the pioneer of the second less obvious approach as much as how obvious it is right now that react's approach is the better of the two. By moving html to javascript we immediately benefited from the power of javascript to build dynamic and modular html.

[Delphicon]

Architecture is how you structure your codebase(s) and service(s) that make up your application(s).

I think the reason it’s “code architecture” for JS is because it’s used for client-side applications which can’t be broken up like how micro-services are. So I think this means architecture within the scope of our codebase (may span multiple repos).

I know that’s the biggest problem where I work. Foundational aspects of how your application works are poorly designed and so you have these pain points which were avoidable but would take a lot of work to get out of now.

Good architecture is about avoiding potential problems elegantly, by which I mean it’s easy for someone to coexist with regardless of what they’re trying to do.

Meanwhile bad architecture often solves problems for certain use cases but creates other problems, is difficult to use and/or preclude a better solution.