🥴 Frontend Thalassophobia 🥴

# [ $davids.sh ] · message #226

• @ [ $davids.sh ] · # 1272

  Backend development is like arriving at a piece of land and being asked to build a building (from a small PHP house to a Dubai skyscraper in Go). You study the soil, landscape, and weather conditions, and it turns out you're in pretty much the same situation as before. This means you can start building, brick by brick, using your accumulated experience.

  Without metaphors, on the backend, you'll have: operating systems -> networks -> runtime -> your code – maybe a bit of virtualization (Docker-like) and that's pretty much all the layers you need to know to write super complex programs.

  Moreover, each of these layers has been stable for years, even decades. So, if you learned TCP/IP + Linux + VM + C / C# / Java / ... in 2010, went into hibernation for 10 years, and woke up, you'd only need a couple of months to dig into the new intricacies, and you could start writing modern applications.

  Frontend development, on the other hand, is like being asked to build the same house, given 1000 ready-made house kits to choose from, pieces of almost finished houses (that don't fit together), and you have to build not on land, but in the middle of an ocean teeming with millions of "hidden dangers," an ocean that's half acid and half shit.

  . Browser – This is the runtime (of the browser itself), which has a runtime for an entire language crammed into it (Exibit-style). And each browser has its own runtime, but thank God, at least the JS runtime is now only V8 or WebKit.

  In reality, frontend development happens in a sandbox, following the rules of this sandbox, which are, firstly, a billion in number, and secondly, you can't break them. Any developer who realizes this breaks out in a cold sweat and falls into depression.

  On the backend, the runtime can be written in the same language (e.g., the Go runtime is written in Go), meaning you can read and understand the runtime. In some cases, there's no runtime at all (e.g., Rust).

  . UI Libraries – There are too many of them, they are constantly changing, their internals are very complex, and the most fucked up thing is that they've become an essential part of development. Having gone through js -> jquery -> backbone -> angular 1 -> vue -> angular 2 -> react, I can confidently say: writing without UI libraries is pure hell.

  Yes, there are frameworks on the backend too, but not only are most of them also well-established for years, but you can also get by perfectly fine without them (and I personally consider them an anti-pattern).

  . node_modules – This is a situation where the joke "your mom is so fat" doesn't work, because your node_modules is always fatter.

  How much fucking garbage it pulls with it... frontend has become covered in such a thick layer of libraries that when you try to build even the most minimal project, you realize you have absolutely no control over what's being pulled in.

  On the backend, the language itself might be enough: Go has a built-in HTTP server, logger, and SQL, so in fact, you can whip up a project WITHOUT A SINGLE LIBRARY.

  . Compilers – To build a frontend project, programs have been written that are more complex than any of these frontends... not too long ago, they even invented a separate language to write JS compilers (you know what I'm talking about 😯).

  Yes, there are languages known for their compilers (Java, C), but honestly, they don't even come close to the complexity of building a "Hello world" project for the frontend.

  To summarize

  I feel like I could go on about this for a long time, so in conclusion:

  On the frontend, the level of control drops to basically 0, and you can't regain control because the amount of knowledge required to do so grows exponentially every day.

  On the backend, this control is almost entirely in your hands, allowing for steady, qualitative growth by delving into each specific deterministic depth.

  I think this is one of the reasons why those who moved from frontend to backend don't want to return. For me, that's definitely the case.

• @ Vassiliy ITK Kuzenkov · # 1273

  Overall, you can also build your own mini-bicycle on the front end now and ride it for 5+ years. It seems much calmer there now, or perhaps my environment is such that hype-driven development doesn't work. Among the really cool things that have spread across the industry in the last 3 years are FSD, state managers, and a bunch of convenient CSS features that used to live in preprocessors.

  But in general, the front-end ecosystem is cursed. I'm a full-stack developer with 5+ years of front-end experience, and I try to return there as rarely as possible) only to fiddle with the tooling.

• @ Nikita · # 1274

  Почему фреймворк на бэке — это антипаттерн?

• @ [ $davids.sh ] · # 1278

  Because it's not difficult to get all the same things without losing anything.

  A framework is good when you are just learning to structure the backend of an application yourself, or when you plan to hire a team of mostly junior developers.

  With at least one experienced developer, any team can assemble the tools they need for themselves and create an internal "framework" that meets their needs.

  Such internal "frameworks" can even be distributed across multiple teams, and everything is tailored to the specific needs of the project and infrastructure peculiarities.

• @ [ $davids.sh ] · # 1279

  Of the interesting "frameworks" I've seen, there are, for example, Akka or Dapr

  But firstly, it goes far beyond a simple code structure, and secondly, if you've reached the need for such complex solutions, then I would either be on a team with someone who knows the guts of these solutions, or have someone capable of replicating such solutions, but tailored to the specific task.

  Most often, we've had to simply study how they are structured internally and adapt them to our needs.

• @ Vassiliy ITK Kuzenkov · # 1280

  There's also a case for "fast and furious." It always takes some time for glue between the libs. For a typical web app, nothing has come out better than RoR yet).

• @ Artur G · # 1281

  The framework ties you down. At first, processes seem to go well, but then everything turns into a mess. And there's no going back. And it's like everyone is crying quietly.

• @ Artur G · # 1282

  In my feeling, nothing is changing at all. Some projects appear, but they are of the "new API" for the old kind.

  It's easy to gain control, but no one wants it.

• @ Artur G · # 1283

  The same FSD, essentially, it's the same layered architecture with all the problems, but colleagues seem to have a veil over their eyes.

• @ Dmitry Shvalyov · # 1284

  25 years in frontend - flight is normal.

• @ [ $davids.sh ] · # 1287

  What I meant by rapid changes: any technology goes through stages where (1) it starts gaining popularity, (2) people start pulling it into production, (3) it becomes established there and job openings for it start appearing.

  If we take any backend language, then for many, many years each of them has had established technologies, which means you have a general idea of what to expect at a new workplace and can deepen your knowledge from project to project.

  With JS, the situation is that you have 4 UI rendering libraries (React, Vue, Angular, Svelte), each with its own version of Next.js or another custom SSR engine, 5-6 state managers, 5 project bundlers, which each team will have some peculiarities with.

  And, of course, it's hard to find less standardized code than in frontend: everyone has their own approach, and each approach has a lot of "exceptions."

  And so, when you've worked on a project with React + Redux for 2-3 years, when you go looking for a job, you'll find that there are far fewer such vacancies because people have started jumping to something else.

  And very importantly: on the one hand, these changes are often "from the frying pan into the fire," because conceptually they are all similar, BUT due to the reasons mentioned in the article, each of them has so many pitfalls that to say "now I know Svelte" you'll have to work with it to learn about the non-obvious crap they don't mention in the documentation.

• @ [ $davids.sh ] · # 1288

  Wow, that's powerful.

  It would be interesting to hear how you see frontend from your perspective, what you still find in it, and where middles can potentially move.

• @ Dmitry Shvalyov · # 1289

  I need to think about it. But I really don't envy those who are just starting in frontend right now – it's hell and a hellish hell. It's a huge darkness of technologies that have been piled up over the years, it's a darkness of technologies, cases, and solutions that are already outdated or starting to become outdated, and you need to understand this. It's a large number of redundant technologies and methodologies that are called differently, but in fact are the same thing (without examples, just feelings). I'm already starting to feel this strongly myself, because for the last 5-6 years I've been working on large corporate projects where technologies practically don't change, and a lot is slipping away from me, and every day the prospect of catching up becomes scarier. In general, modern frontend is a constant chase with a speeding train – you fall behind a little, and new frameworks have already come out that you know nothing about! But on the other hand, you don't always and everywhere need to constantly catch up with this train; in the corporate sector, new technologies are introduced slowly, and you can always work with legacy for years (for example, with React with classes), and this won't mean you're a bad developer. The same applies to CSS; for those who don't like programming, you can be a cool and valuable layout specialist. Again, a middle developer doesn't need to move anywhere – a senior is more about team management and less about actual programming (but it depends on the company, of course), if there's an opportunity to increase pay and grow horizontally rather than vertically) But this is purely based on feelings.

• @ Dmitrij IT-Kachalka Malakhov · # 1292

  As a seasoned frontend developer who has dabbled in lightweight full-stack development, based on my experience with various projects, I can say that the whole race for new tools and solutions looks like "plain old FOMO."

  Let's look at a few examples:

  1. You've been working on a corporate project for years, and you're scared that a lot of new things have come out on the market and you have no idea how to catch up. Do you need to catch up now? If you're on the same project, then no, your experience with it will be more important than knowing all the new stuff. When you move to a new job, it's unlikely that everything there will be new. There will be a minimum you'll need to get up to speed with, like React hooks (and how many years have they been around already?), and the rest will be learned during onboarding. It's impossible to know everything.

  2. If you're a lead, it's useful to know new things, at least to understand whether it's worth bringing it into the project, whether it will provide an advantage, or if it's just more nonsense. And to be able to reasonably dissuade juniors who want to implement everything new. Perhaps this is one of the few cases where staying up-to-date is useful.

  Otherwise, work with what you're familiar with, and don't create problems for yourself by learning new things if you don't need to. You don't need to know Svelte, Solid, or other new technologies if you're writing in React.

• @ Dmitry Shvalyov · # 1293

  Who are the "greens" trying to push all the new stuff? 🤔

• @ Dmitrij IT-Kachalka Malakhov · # 1294

  The main proponents of hype-driven development are usually mid-level developers, but it varies.

• @ Dmitry Shvalyov · # 1295

  Great. It used to be easier to get into things. I remember when jQuery first came out and they started shoving it everywhere – first cautiously, and then at breakneck speed into everything that moved (and didn't move).

  A couple of years ago, I tried to wrap my head around GraphQL. It's a good thing, but when I started digging into it, I decided it wouldn't be that easy to get away with, and most likely, it's not needed in 9 out of 10 cases. Then came Vue, which I was lucky enough to completely bypass without even touching it.

  Now there's hype around Next.js. But these days, these are very substantial things, and it's unlikely you can just take and shove them into a working project just because it's trendy!