DEV Community

Cover image for The Last Advice to Front-end Engineers
Ourai L.
Ourai L.

Posted on • Originally published at ourai.pro

The Last Advice to Front-end Engineers

I don't know why, but I have this annoying habit of being overly eager to meddle in other people's affairs, which is why I changed my group nickname to "Enthusiastic Netizen" in some WeChat groups.

Recently, some of my peers have been job hunting, cramming for interviews, and asking how to answer certain interview questions, and so on.

Seeing them like this, I get extremely anxious – they seem to be willingly jumping into a pit of fire, one after another!!!

At this point in time, the vast majority of my peers are "Web Front-end" developers centered around HTML, CSS, and JavaScript, and most of them are business front-end developers, who mostly work on middle and back-office applications.

The "Momentum" of Middle and Back-office Applications

Middle and back-office applications have two important characteristics –

First, business processes and data security are far more important than product experience. Compared to so-called "product power" and flashy visual design, ensuring that business processes proceed smoothly and that data remains intact is much more important, with the rest being just icing on the cake.

Especially when facing manufacturing and other physical industries, even without digital products, the business can still run, albeit less efficiently; digital products exist only to improve efficiency and have no right to change existing business rules, nor should they be the other way around.

Therefore, companies or departments that develop middle and back-office applications do not need the "product manager" of to C, but need a "requirements manager" who can understand the needs of the business side (mainly industry or domain experts) and convey them accurately.

Second, the front-end part of middle and back-office applications is highly patterned, and since business and data are prioritized, it is possible to better model at the system level and abstract a construction pipeline that automatically deduces the final application from the model as the source.

That is to say, as long as the model is extracted from the business, and various relationships are described based on a certain mechanism, the final effect of the operable application can be seen directly.

The ways to describe relationships can be:

  1. DSLs with programming-like experiences such as XML, JSON, JS pure objects;
  2. Visual operations by dragging and dropping on the page;
  3. Let AI understand the requirements document and then translate it.

The last one is the ability that I advocate and pursue for the "knowledge-driven, intelligent R & D integration platform" I mentioned.

As for what that "mechanism" is, there are two that I currently favor:

  1. The Nop platform implemented by Canonical based on its own reversible computing theory;
  2. The BFF framework that my senior is currently developing.

But they both lack support for the pure front-end part, and my "Anti-chaos Front-end Engineering" will fill this gap.

The "Fate" of Engineers

Before ChatGPT came into the public eye, we believed that in the R & D process of middle and back-office applications, designers and front-end engineers would be eliminated, and "requirements managers" and back-end engineers could collaborate to do the job.

The emergence of ChatGPT and similar products has also made it possible to eliminate most back-end CRUD engineers, and "requirements managers" only need to write detailed requirements documents.

Since it is a "trend" that business R & D engineers will be replaced by knowledge-driven, intelligent R & D integration platforms, why not accelerate this process?!

In our view, positions engaged in such R & D have no future, but some people do not think so – either thinking with the current perspective, or believing that humans are stronger than AI.

However, the fact is that the iteration and growth speed of technology is never linear, and one of the impacts of its development is to require people to renew their knowledge and skills; the most foolish thing about humans is to be self-righteous.

Conclusion

Although the main topic of this article is that business R & D engineers of middle and back-office applications will "suffer heavy casualties", it does not mean that to C is "unscathed", only the proportion will not be so large.

Compared with my idea, my senior's statement is a bit more exaggerated – maybe one day AI will create miracles and directly generate applications composed of source code, instead of those that have been abstracted layer by layer.

Such applications are black boxes, and from the perspective of software engineering, they are not maintainable, and any best practices and optimization methods will become invalid – neither meaningful nor necessary – just like after the advent of cars, knowledge and skills about horse riding became useless.

Many times I feel like that kind of person – telling others that a disaster will come in a few days and they should escape quickly, but they think I am talking nonsense and make fun of me.

So, this is my last warning, I hope those who see and understand it can take action and stop jumping into the pit of fire.

Top comments (1)

Collapse
 
keyru_nasirusman profile image
keyru Nasir Usman

This is amazing article. We want to see this kind of blogs on dev.to more often. I am tired of reading AI generated junk on my feed.