🙅‍♂️ Is full-stack possible? 🙅‍♂️

# [ $davids.sh ] · message #224

• @ [ $davids.sh ] · # 1256

  I distinguish 2 types of full-stack developers:

  • backend-oriented full-stack – a backend developer who can quickly and efficiently assemble a frontend (using ready-made solutions).

  • frontend-oriented full-stack – a frontend developer who creates interactive SPAs and, at the same time, can create a backend API (BFF) for themselves, which interacts with third-party services, caches, and sets up a database schema for themselves, and makes SQL queries to it.

  For the former, the biggest problem was making changes without re-rendering the entire page, but without having to write JS code.

  I might be going crazy, but I'm sure I used something called "Live templates" or something similar to write views in RoR that would auto-update via AJAX, but I can't remember what it's called (old-timers, help me out).

  Currently, I would call htmx + a convenient templating tool (like templ for Go) the most convenient tools, and with them, we have a frontend of sorts without JS.

  In short, I would say that due to the shift in focus towards SPAs, solutions for this category of developers have simply stopped being invented and popularized, but the NEED is HUGE.

  Because (1) few people want to delve into the intricacies of JS libraries, and (2) finding a decent frontend developer is like trying to hit yourself in the appendix.

  As for the problem of the frontend-oriented full-stack... you know, I'd like to say it's also "technological," but to start with, there are already technologies that simplify frontend-backend interaction:

  • Hasura / Supabase – convenient hyped technologies that allow you to configure access levels in the UI and work directly with the database from the frontend. I can't say anything about Supabase (it makes me uneasy), but Hasura is one of my favorite technologies, I recommend it to absolutely everyone.

  • Blitz / Next.js 13 – the former is a very interesting concept of blurring the lines between frontend and backend, the latter allows you to write backend code alongside frontend code.

  One could say that these technologies haven't been popularized long enough to have spawned frontend-oriented full-stack developers, but I consider these technologies merely facilitators of a task that could have been solved without them.

  I still think that we practically don't have frontend full-stack developers because either frontends don't want to deal with the backend, or having started, they dive headfirst into it and don't want to return.

  And also, perhaps, because there aren't enough adequate tutorials to help frontends properly integrate into the backend (no, telling about Nest.js and showing how to make a request to MongoDB is "showing how to work with shitty technologies," not "teaching backend development").

  Why do I think about this often? Because for almost 10 years, project after project, I've been fed up with having to build endpoints for frontends, which in 90% of cases are just SELECT queries, and the most infuriating thing is when they come to you and say: "we need one more field" – and you're already neck-deep in work, and they look at you with honest eyes and wiggle their little paws: "but we can't do it without the backend"...

  Seriously, if they would just learn how to work with SELECT queries, 70% of API work could be lifted from the backs of backend developers (leaving only Code Review).

  I hope the frontend market finally cools down with its frantic release of new JS frameworks and that frontends will finally be required to know how to write BFFs for themselves.

  What do you think, is this possible or is it a utopia and everyone "should do their own thing! long live the union of socialist frontend developers!"?

• @ [ $davids.sh ] · # 1258

  And yes, I don't really believe in full-stack, because it's incredibly difficult to remain a quality developer in both areas for a long enough time.

• @ Arsen IT-K Arakelyan · # 1259

  Perhaps such things exist, but one would have to delve into the super subtleties of different paths, regularly and constantly.

• @ FatShibe · # 1267

  Come on, many backend developers write fine in React/Vue, why would you need some HTMLX?

• @ [ $davids.sh ] · # 1269

  Often there are tasks for a "semi-interactive website," and ideally with SEO as well.

  Yes, for an average backend developer, learning and writing something simple on the frontend is quite easy, but honestly, I really don't want to dive into the frontend if it's possible:

  . Project setup and configuration – pain . Deployment and maintenance of SSR technologies – pain . Test configuration – pain . CI/CD configuration – pain . Basic template and library setup – pain . Debugging client-side errors – pain . If you're not using Node.js, switching to JS – all the pain above is multiplied by 10

  And all of this can be avoided by simply using a template engine + htmx:

  . Out-of-the-box semi-interactivity . You'll stay in your favorite language . Tests are the same as for your language . All infrastructure is understandable . Build is already configured . Debugging is straightforward

  So honestly, considering that I've been doing frontend for 4 years, went through jQuery, Backbone, Angular, Vue, and React, wrote a bunch of my own libraries, and taught advanced frontend courses, my heart doesn't want to write a simple UI for another project using any JS "framework."

  It's a kind of subconscious aversion to such a huge, uncontrollable machine (I'll describe this in a future article).

• @ FatShibe · # 1275

  Completely agree, as a backend dev I still haven't figured out this fucking Webpack and Vite, haven't figured out how to write tests, and so on and so on.

• @ Ksyusha Yuka · # 1276

  What should I read/watch to learn how to make these handles and add margins? We discussed this before, but I forgot.

• @ [ $davids.sh ] · # 1277

  Yes, sorry, I just haven't had time to deal with this issue :(

  I'll try to formulate in a separate post what could be done to move towards the backend.