DEV Community

Discussion on: Moving away from ReactJs and VueJs on front-end using Clean Architecture

Collapse
 
fabiorizzelloomnia profile image
fabio-rizzello-omnia

Well if you think about it React forces you to write applications in a determined way too.
It's just less opinionated on some topics but still gives you a way to do things, the React way. Just saying the thing you have to pass props, never change props, and component will re-render automatically on changed props(or state) without having to manually tell the component what changed, that's already enough to enforce you a way to develop.
Just because React is less opinionated on things like global storage, router, i18n, forms etc.. It doesn't mean it's not a framework

Collapse
 
joelbonetr profile image
JoelBonetR 🥇 • Edited

But it's not, and it's not my opinion. React and Preact are not framewors and it's a fact. It's like saying Node is a framework or a language when Node is only a javascript runtime environment so in order to speak consistently and concisely, we need to categorise and qualify things like they are.

In computer programming, a software framework is an abstraction in which software, providing generic functionality, can be selectively changed by additional user-written code, thus providing application-specific software. It provides a standard way to build and deploy applications and is a universal, reusable software environment that provides particular functionality as part of a larger software platform to facilitate the development of software applications, products and solutions. Software frameworks may include support programs, compilers, code libraries, toolsets, and application programming interfaces (APIs) that bring together all the different components to enable development of a project or system.

Frameworks have key distinguishing features that separate them from normal libraries:

  • inversion of control: In a framework, unlike in libraries or in standard user applications, the overall program's flow of control is not dictated by the caller, but by the framework. This is usually achieved with the Template Method Pattern.
  • default behaviour: This can be provided with the invariant methods of the Template Method Pattern in an abstract class which is provided by the framework.
  • extensibility: A user can extend the framework – usually by selective overriding – or programmers can add specialized user code to provide specific functionality. This is usually achieved by a hook method in a subclass that overrides a template method in the superclass.
  • non-modifiable framework code: The framework code, in general, is not supposed to be modified, while accepting user-implemented extensions. In other words, users can extend the framework, but cannot modify its code.

By the other hand, a software library is a suite of data and programming code that is used to develop software programs and applications. It is designed to assist both the programmer and the programming language compiler in building and executing software. It generally consists of pre-written code, classes, procedures, scripts, configuration data and more. Typically, a developer might manually add a software library to a program to achieve more functionality or to automate a process without writing code for it.

That being said, from the different options we have for the front-end, i'll pick 5 and they are categorised like this:

  • Angular and Vue are frameworks
  • React and Preact are libs
  • Svelte is a compiler.

Hope it helps you understand the differences :)

Thread Thread
 
rockson_30 profile image
Rockson • Edited

Answering from non-work account
That's a really good answer. Yes even tho React has some sort of DI you can't really say it's extensible

Thread Thread
 
joelbonetr profile image
JoelBonetR 🥇 • Edited

When you import a lib just to achieve a goal you usually fit into this approach, otherwise you can either choose another one (and fit into it) or write down your approach and publish it as the new lib to do the same others do but on a different manner, then your lib will need to pass 2 filters:

  1. Community (if it solves a real issue, it does it on a simple (no suggar needed) way, it's buggless, covers all possibilities that any project could need, a medium-big project is built with that as example of capabilities and it's well documented, you can get some fans and stars on github).
  2. Us current engineers, tech leads and so will eventually take a look at it if the community growth enough to find devs who knows that lib or to share with the team to solve a current situation for a new or existing project. If you simply changed the way of doing things by stubbornness instead trying to understand how the things work and why they work this way, it'll simply be ditched off and it'll die along the other hundreds of js libs released every month that does not fit for real solutions.

I can understand your reasons to avoid using a lib or framework "as is" and in the end you can agree with me that is a try to avoid tech debt in a project, not less not more.

Then there reasons that counters this reinvented wheel. If you use react millions of devs out there will be available to work within your project in few hours, if you need higher performance and less included libs, you can simply pick preact and every react dev will be skilled to work with that as well.

If you create your own approach and build a project or even a company with that, the end result is that the world keeps rolling and new tech will appear anyway to solve other problems you don't even know about -yet- or to automate things you didn't even mind -yet- so people will like to use this "latest tech" (We know "latest" mean that it appeared 4-5 or 7 years ago and now it's popular and everyone works with that) so even if you figure out how to trick some dev to work in your company or project, they will eventually fly away to another company at the first sight of working on a non standard dinosaur. This will put you in need to increase the salary for your devs and new hires which is also costly and at this point, the life-cycle of your App will be near the end and needs a tech refresh regardless of your initial effort.

The end questions would be then, Is it worth? what do you prefer?

Thread Thread
 
xurxodev profile image
Jorge Sánchez Fernández

Hi, thanks for your comment.

Everything has advantages and disadvantages but in long-term applications I think it makes more sense to uncouple and in the future it will be appreciated in my experience.

Regards

Thread Thread
 
joelbonetr profile image
JoelBonetR 🥇

Bet you don't pay the salaries so! 😁