Is back-end development really more conservative than front-end development?

Question

Backend

Recently, I often hear that developers complain about how much they need to know to be successful: technologies, frameworks, programming languages, tools, etc. From my own experience, I can judge that this directly concerns front-end development - a whole bunch of js frameworks that appear almost every day, css preprocessors, build systems, bootstrap, graphic editors, etc. But as for the back, the picture there is not so frightening - it is enough to know 1-2 frameworks, DBMS well and have server skills. Everything else is on demand. And follow the updates of only these technologies. Is it really?

Answer 1

Half the answer is in the question, but the devil is in the details.
Indeed, for relatively productive backend development in almost any programming language, you need to know several basic frameworks and tools that solve most problems. This is the skeleton of ~90% of applications more complicated than hello world. Although this skeleton also changes and develops, albeit not as fast as we would like , like various processes (not conservatism, but a longer life cycle). The total weight of technologies and tools is no less, and certainly no less dynamically changing, than that of frontend developers.
Further personal experience on the example of Java.
About 7-8 years ago, it was enough to know Spring, Struts, Hibernate and Apache Commons in addition to developing most solutions. Well, a J2EE stack for Enterprise-level tasks.
In the year 2014 Spring, Hibernate is still in the programmer's arsenal, but a bunch of absolutely new things appeared like AMPQ, Hadoop, Netty, Scala with a functional paradigm, multilingual environments with Clojure/Groovy/JRuby; alternative implementations of popular libraries became more common (for example, Guice / Guava); older technologies such as J2EE have become less common. And only Key-Value storages, caches and other NoSQL are like dirt. Even the approach to building applications has changed - few people in 2005 heard about asynchronous event-driven models and started designing from the REST style (in fact, there are the roots of the frontend developer as a separate specialization). About the evolution of build systems, VCS, benchmarks and other "micro" elements, you can paint more than one sheet.
And yes, frontend comrades will forgive me for, perhaps, a snobby tone, but lighting up the intricacies of async IO depending on OS specifics like epoll / kqueue or taking into account the CAP theorem when building a middleware cache is a higher level of complexity than the new CSS preprocessor and CoffeeScript with another MVC / MVVM framework. Some tasks, such as thread synchronization, are mostly in the realm of mathematics.
I am sure that in frontend development there are tasks that are more complicated and interesting than the layout that went to the pixel and updating fields after JSON parsing, but IMHO backend development is closer to old-school system programming, while frontend is application programming with design impurities.
There are more frontend tools, more difficult backend tools.

Answer 2

Yes.

Answer 3

And let the holivar begin!

Answer 4

I personally think it's about the industry as a whole.
In the backend, in fact, everything is even worse in my opinion. Because on the web frontend you only have HTML, CSS and JavaScript. In the backend, you can use any languages, plus a DBMS and other applications (web servers, all sorts of cache buses, etc.). So the problem is at least similar to the front-end multiplied by three.
If you want relative stability, take, say, Java and the subject area - UI or the web there, and pretend that nothing else exists for you. Even limited in this way to the flow of information, you can easily choke.

Answer 5

Yes, there are a lot of things in the frontend, BUT!
I have programming experience in both backend (Java, PHP, Go, Node.js) and frontend (JS, HTML, CSS) and here's what I'll say.
Take SASS. I studied it in a day. Slightly more. I shoveled the docks, made examples for fixing
And now let's take the same java. Spring Framework for example. I've been programming on it for a little over six months. I can’t even say close that I know all its subtleties. That's the whole difference. No need to look at the number of frameworks & tools in a given area. You need to approach the issue from the point of view of investing time.

Answer 6

Very similar to the truth, isn't it? What ordinary users do not see should not be fashionable.

Answer 7

well, not to say languages ​​have bred
ruby ​​pythons pkhp
all different versions of
all sorts of nodes and its
database analogues breed
noskl and so
on and in general the evolution is significant in the backend more significant than in the front

Answer 8

Back-enders are dumb to admit that all their work is analogous to cout << "hello world :-) :-) :-)
But in fact, the front-end is "what, where, in what form to display and accept the answer", and the back-end is only "what to display ".

Answer 9

in the frontend it is enough to know jquery or angular or any other of your choice, css preprocessors and various css frameworks, learn in 2 and a half days, in the backend everything is quite more complicated, you can’t solve some problems with one tool, you need to know - several mysql subd, mongodb, caching systems redis, memcache, working with Linux, not just one version of ubuntu, maybe centos, several frameworks that are also riveting every day, the same build systems, deploy systems, rabbitmq asynchronous task systems, celery and a lot of other things, keep an eye on updating even one framework is problematic, not to mention several.

Answer 10

The front end hacked into the server through a Node.js window and a JavaScript bridge and spawned 80k packages, it's hot, it's bearable... https://www.npmjs.org/