13 ms·

90% of my software engineering is fighting with incomprehensible framework magic to automates simple tasks that don't need to be automated, to "save me" from ju

by jseban 4y ago

90% of my software engineering is fighting with incomprehensible framework magic to automates simple tasks that don't need to be automated, to "save me" from just writing some simple code. It's literally rube goldberg all the way, the most over complex contraptions to achieve the simplest of tasks. "You don't want to write "raw" html/js/sql/Java" Uhm I thought that was my job.

ozmodiar 4y ago
This strikes a nerve with me. Lately my work has started taking apart our website and shifting functionality to 3rd party vendors in an effort to limit liability. We're going to end up with something far less versatile, uglier and ironically less secure than what we started with. My focus is shifting to a bunch of API stuff that I just don't find very rewarding.
omginternets 4y ago
I tell every junior colleague two things: 1. There is software engineering, and then there’s working at the digital factory. 2. A good way to set yourself on the path that leads to the former is to get intimately familiar with the HTTP protocol. A good way to start is to reject fancy frameworks, and to get comfortable reading RFCs. Being the guy who really knows HTTP is a powerful career move. Becoming that person almost inevitably kicks off a virtuous cycle that steers bright/motivated devs well clear of writing REST endpoints for the rest of their working lives.
- urthor 4y ago
  It does feel like the barrier to entry for that kind of deep knowledge career is increasing these days. Maybe it's because I live outside the United States, but it seems like it's much harder to build a "pathway" into work that demands that intensive, deep understanding of engineering on computers. At least one that'll pan out in my 9-5. The supply of problems that require deep knowledge vs framework Kung Fu... my impression from ground level is they're tilting more towards GitHub martial arts every year. The supply of companies outside the United States with a deep interest in these topics is sparse, to say the least.
- pc86 4y ago
  I don't think I can really articulate why but this smells a lot like the "real programmers use [neo]vim" or "real developers write C++" kind of gatekeeping that was pretty widespread and even expected/accepted a few decades ago, but really has no place now. Being intimately familiar with HTTP is fine, reading a lot of RFCs is fine, but there are plenty of well respected, well compensated, influential engineers who do neither, and have no need for either one.
  - omginternets 4y ago
    I see what you mean, but you’ll note that I’m neither saying that it’s the only way, nor am I saying that it’s required. What I’m instead doing is trying to cultivate a deep understanding of one’s tools and protocols, which is absolutely the hallmark of a competent engineer. I concede that this may superficially resemble the aberration you describe, but insist that it’s actually very different.
    - blagie 4y ago
      My experience is that to do any kind of engineering and most kinds of science really well, you need to have a deep understanding one layer down and one layer up. The HTTP comment seems off-base. HTTP is neither particularly important or interesting as a protocol. You can spend a half-hour with netcat and have a few conversations with your web server, and you're set. The concept more broadly is spot-on. The "I don't need to know [x] to do my job" crowd is universally mediocre at their job. For a programmer, the set of things one layer down is important, be that cache/memory hierarchies, low-level programming, operating systems, databases, compilers/interpreters, or otherwise. So is one layer up, which is usually business and product understanding. I'll also mention: Mediocrity at one's job is okay. There are plenty of wonderful people who have work-life balance and do interesting things outside of their job, and just want a pay check. There are people happy to be working on systems I'd be miserable working on -- payroll, banking, inventory, etc. -- and I'm glad they're around. A few of them are among my favorite people too.
      - bennysomething 4y ago
- Consultant32452 4y ago
  I find the best path, for me, is to be the guy who knows HTTP pretty well but I don't let anyone else know. Once they find out I know things I get tapped to fix all the old problems instead of build new problems, then I have to leave because the work becomes miserable.
- scarface74 4y ago
  Yes and I tell junior developers the only way to be good is to know assembly language like I had to know. /s
deleted 4y ago
[deleted]
ecshafer 4y ago
This is what I have always really disliked about many web development frameworks. Their goal is to either a) do things magically in a specific way or b) do so with a bunch of configuration files. Spring comes to mind as a particularly egregious case that does both. Spring does things automatically, until you need to add a configuration file for every change. You need to add this wrapper and this library for this other case. I have always wanted a web development framework that works more like a game development framework. Where you still code everything you need but it doesn't hide the part where you make a window or add a listener. Which makes it a lot easier to find where things are going wrong and how to change the configuration as opposed to go to stack overflow and learn you need to add this dependency which then does things behind the scenes.
- emteycz 4y ago
  Node.js + Express is what you want. I'm not a Go developer, but it seems to me that the Go ecosystem also has what you want.
  - gernb 4y ago
    can you give more details? My understanding is the node + express is really low level providing almost nothing except a set of chainable functions based on routes. To get any actual functionality (storing to databases, authentication, users, sys admin, etc requires writing everything yourself. The reason I like batteries included frameworks is I get all that for free and ideally it's already following best practices so I don't have to worry about security, about account recovery, about versioning new data/features, about scaling, etc
    - chii 4y ago
      > don't have to worry about security, about account recovery, about versioning new data/features, about scaling, etc with the exception of security (i take it you mean authentication), everything else is unlikely to be provided by a framework like spring directly - you'd have to choose something to provide it or write it yourself.
sjaak 4y ago
What are you talking about? What's not to like about the SimpleBeanFactoryAwareAspectInstanceFactory [1]? [1] yes, this exists
- Forge36 4y ago
  That I couldn't find the advanced one or the generic legume factory and ended up having to write my own as the owner wasn't currently accepting pull requests?
- _Algernon_ 4y ago
  https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
krainboltgreene 4y ago
> "You don't want to write "raw" html/js/sql/Java" Uhm I thought that was my job. I mean it isn't your job and it shouldn't be. Your job is to make software handle with consistency some business process or become an extended memory of some business people.
wnolens 4y ago
I've started and quit web dev projects about 4 times in the past 5 years. I'm a distributed systems dev. The complexity of the recommended tool chain is mind boggling (and I consider my day job incredibly complex, of which I have a decade of experience doing). I would have said I hate React. Finally started another project. No frameworks this time. Started with html and single js file until I needed more.. and solved the problems step by step. I'm at the point that I now see the benefits of react, but only by doing it this way could I possibly learn why.
- sprkwd 4y ago
  I have completely given up on web dev these days.
  - commandlinefan 4y ago
    Backend is worse, they’ll make you use the Spring “framework” that makes React look like a dream.
    - AtlasBarfed 4y ago
      A couple annotations and a base application class and you're up and running with a REST service. That's considered hard?
      - presentation 4y ago
        Translated to React: a single render function and you're up and running with a webpage. That's considered hard?
    - mdoms 4y ago
      Spring is a simple MVC framework, it follows the same patterns as similar Ruby, Python, C#, PHP etc frameworks. React very much blazes its own complicated trail.
      - 4y ago
pojzon 4y ago
Company: “We dont want you to write code, because finding ppl who understand the code is hard, while finding ppl who eat generic pulp is easy”
deleted 4y ago
[deleted]
twblalock 4y ago
> "You don't want to write "raw" html/js/sql/Java" Uhm I thought that was my job. It's not your job, any more than a firefighter's job is to be a hose operator, or a nurse's job is to be a syringe operator. Your job is to produce software that meets the requirements of the business, as a member of a larger engineering organization which needs to be able to function well enough to deliver that software. Why are frameworks popular? Because they provide a standardized way for multiple engineers, and multiple engineering teams, to collaborate effectively on the same product -- and they make it easy to hire people who already know the frameworks. If everyone is writing "raw" JS/HTML/SQL/Java/whatever, they are actually building their own individual, unstandardized frameworks. That's not good for supporting software when the author leaves, and it raises the barrier enormously for onboarding new people. Above a certain scale it's just not workable. You can be cynical about this and say that it reduces engineers to interchangeable cogs in a machine. Or, you can understand why things are the way they are, understand how to succeed in this reality, and build a fulfilling career path for yourself by providing value that a mere cog cannot. I've worked with a lot of successful, happy engineers who are not cogs, and what separates them from the others is not coding skill -- it's that they all understand this reality.
- emsy 4y ago
  I don’t think you have a lot of experience with long software projects. The pros of frameworks are outweighed by their cons pretty quickly. This effect is accelerated by shorter support times and an ever growing number of frameworks.
  - tluyben2 4y ago
    Maybe depends what tech you work in? In the Java and .NET sphere things are pretty much stable over many years. We hardly had to do any work to to move our systems (quite large ones) across the same well supported frameworks to new versions the past decades and the fact everyone in these ecosystems know the popular frameworks well and the design patterns, it scales well to many and new people.
  - woojoo666 4y ago
    Do you have any examples of web apps or websites with millions of users, and don't use any frameworks? The only one I can think of is HackerNews, funny enough.
scrozart 4y ago
We use a pretty jank framework at my professional gig, and are thankfully finally beginning to plan a migration to the much better documented framework it rips off. A full rewrite is almost never worth it, but between the already poor and now mostly out of date documentation, and the apparently diminishing community, there's not really a better route. All that said, every other framework I've ever used in my personal projects has fine documentation and community support, including their peripheral deployment tooling. My experience at work seems like an outlier to other tools I see. Comments like the original post and OP make me think everyone is working in legacy systems based on aged tech from the cowboy era.
jchw 4y ago
Writing raw anything is not necessarily your job. However, a lot of people have an interesting view of things like frameworks, ORMs, and other abstractions. To some, it feels like pure all-or-nothing; but what if it didn’t have to be? Even the biggest hater of SQL database abstractions will admit there are reasons why someone would want them. But I wonder if there is an answer somewhere in the middle that could go both ways. For example, sqlc[1] provides basically all of the type safety that overbearing database frameworks might, but it lets you write plain old SQL just as you normally would, and integrates cleanly with your existing migrations solution. It doesn’t solve everything, but I have a feeling more people would like tradeoffs like these: an enormous amount of complexity does exist, to say, parse SQL and emulate DDL transactions for the sake of typing, but it stays entirely in the tool itself, and the resulting code and interfaces are completely simple and obvious code. I believe that there are multiple better middle grounds waiting to be discovered in any given niche where the options currently feel like barely-worth-it trade-offs. [1]: https://sqlc.dev https://sqlc.dev
- jseban 4y ago
  > Even the biggest hater of SQL database abstractions will admit there are reasons why someone would want them. There is only one reason, and it's that people don't understand how to use SQL, and that's because it's not taught in computer science degrees, and this also has strong ties to the battle between sun and oracle. And this makes database developers expensive and hard to hire. There is no reason to use an ORM if you know SQL and database modelling. The relational model is by far the most powerful tool to solve CRUD use cases, which "web development" is, and that's just simply a fact. What the ORM will do for you is automate some boilerplate mapper code, which might be a bit boring to write, but is very simple. And the downside is that it will make all of your database modelling, querying, access etc orders of magnitude more obscure and complex compared to just using SQL. And now you will waste enormous amounts of time fighting with the framework to debug the ORM and find out which kind of weird SQL statements it generates, where you would have complete control over this if you just wrote your own. The obvious solution that would benefit everyone, is to simply train your developers to use SQL, if they don't already know it, and let them take a course if they need to. Not to slap on some stupid framework and make a huge unmanageable mess of the whole system.
wackget 4y ago
As a recently-retired Magento developer of ten years... this speaks to my very soul. I've sworn to never use Magento again.
grishka 4y ago
Yes, this. There's a reason I avoid complex abstraction layers that helpfully "hide" the underlying platform from me. So, yes, in my hobby project that's a server application in Java, I use a simple, easy to understand micro-framework (sparkjava.com), a simple template engine (pebble), and a homebrew SQL query builder on the backend, and vanilla JS (compiled from TypeScript) on the frontend. Every dependency is a liability, especially the kind you can't remove without rewriting your entire project. Adding a library to my project is a very serious thing for me.
beej71 4y ago
I get this sentiment. But I think it's not so much that there's a framework but rather that the framework is an I'll fit for the problem to be solved. So you "fight" with it. In general, it seems like the easier it is to do something in the scope of the framework, the harder it is to bend the framework to do something outside it's scope. We've all seen this with frameworks that make 95% of the work really easy, and the remaining 5% is like pulling teeth. You're bending the thing where it's not meant to be bent. (And that's when new frameworks are made. :) ) But if you go lower, under the framework, it's way more flexible. As a dev, you can explore and create instead of fighting. Which is great. But really we're just on a different turtle. Raw JS has a really hard time with some problems when you try to bend it wrong. Our job is to take the right technologies for the job and make them work, no matter how abstracted they are. The pain is merely from the wrong tool. And, truly, it sucks when you have to do that.
tootie 4y ago
Every time I see a framework how quickly they can bootstrap I now consider that a red flag. The more automagic, the more you can't ever figure out why something goes wrong. It's been said that most products spend 99% of their lifetime in maintenance. If a framework wants to impress me, show me how clear the stack traces and IDE integration are. Show me how crystal clear it is to trace the execution path.
dottedmag 4y ago
I feel you. In my role as a software architect in a small company I've been booting out various "frameworks" and overly invasive libraries, because it turned out they are not delivering much, while requiring attention and forcing us to bend our code to satisfy their demands. First ones to go were various cloud libraries: AWS, Google Cloud, CloudStack. It's a plain REST. I estimate that the code that talks to Google Cloud directly is shorter than it was when the library was involved. Docker went (it's a REST with a few quirks). Kubernetes client went (same). GitHub client went. gPRC went (fortunately we're not required to talk gRPC anywhere except a few endpoints, and it turned out that Protobuf is not hard to implement if you don't have tons of schemas, and gRPC is HTTP/2+Protobuf). Finally I booted Mongo client library, because all we needed is a few requests, and implementation of Mongo wire protocol + BSON ended up costing us ~300 lines of code. Remaining libraries earn their keep: there is cryptography, XPath, JSONPath, compressors, userland IP stack, complex serialization formats. I thank the authors of these libraries, and due to some reason these libraries are also the least complicated and most compatible version-over-version.
- jd_mongodb 4y ago
  When you booted the Mongo client library what did you use in it's place? Were you connecting to a cluster or a single node? Lightweight clients are always interesting because of the trade offs they make.

by jseban 4y ago

ozmodiar 4y ago

This strikes a nerve with me. Lately my work has started taking apart our website and shifting functionality to 3rd party vendors in an effort to limit liability. We're going to end up with something far less versatile, uglier and ironically less secure than what we started with. My focus is shifting to a bunch of API stuff that I just don't find very rewarding.

omginternets 4y ago

I tell every junior colleague two things: 1. There is software engineering, and then there’s working at the digital factory. 2. A good way to set yourself on the path that leads to the former is to get intimately familiar with the HTTP protocol. A good way to start is to reject fancy frameworks, and to get comfortable reading RFCs. Being the guy who really knows HTTP is a powerful career move. Becoming that person almost inevitably kicks off a virtuous cycle that steers bright/motivated devs well clear of writing REST endpoints for the rest of their working lives.

urthor 4y ago
It does feel like the barrier to entry for that kind of deep knowledge career is increasing these days. Maybe it's because I live outside the United States, but it seems like it's much harder to build a "pathway" into work that demands that intensive, deep understanding of engineering on computers. At least one that'll pan out in my 9-5. The supply of problems that require deep knowledge vs framework Kung Fu... my impression from ground level is they're tilting more towards GitHub martial arts every year. The supply of companies outside the United States with a deep interest in these topics is sparse, to say the least.
pc86 4y ago
I don't think I can really articulate why but this smells a lot like the "real programmers use [neo]vim" or "real developers write C++" kind of gatekeeping that was pretty widespread and even expected/accepted a few decades ago, but really has no place now. Being intimately familiar with HTTP is fine, reading a lot of RFCs is fine, but there are plenty of well respected, well compensated, influential engineers who do neither, and have no need for either one.
- omginternets 4y ago
  I see what you mean, but you’ll note that I’m neither saying that it’s the only way, nor am I saying that it’s required. What I’m instead doing is trying to cultivate a deep understanding of one’s tools and protocols, which is absolutely the hallmark of a competent engineer. I concede that this may superficially resemble the aberration you describe, but insist that it’s actually very different.
  - blagie 4y ago
    My experience is that to do any kind of engineering and most kinds of science really well, you need to have a deep understanding one layer down and one layer up. The HTTP comment seems off-base. HTTP is neither particularly important or interesting as a protocol. You can spend a half-hour with netcat and have a few conversations with your web server, and you're set. The concept more broadly is spot-on. The "I don't need to know [x] to do my job" crowd is universally mediocre at their job. For a programmer, the set of things one layer down is important, be that cache/memory hierarchies, low-level programming, operating systems, databases, compilers/interpreters, or otherwise. So is one layer up, which is usually business and product understanding. I'll also mention: Mediocrity at one's job is okay. There are plenty of wonderful people who have work-life balance and do interesting things outside of their job, and just want a pay check. There are people happy to be working on systems I'd be miserable working on -- payroll, banking, inventory, etc. -- and I'm glad they're around. A few of them are among my favorite people too.
    - bennysomething 4y ago
Consultant32452 4y ago
I find the best path, for me, is to be the guy who knows HTTP pretty well but I don't let anyone else know. Once they find out I know things I get tapped to fix all the old problems instead of build new problems, then I have to leave because the work becomes miserable.
scarface74 4y ago
Yes and I tell junior developers the only way to be good is to know assembly language like I had to know. /s

deleted 4y ago

[deleted]

ecshafer 4y ago

This is what I have always really disliked about many web development frameworks. Their goal is to either a) do things magically in a specific way or b) do so with a bunch of configuration files. Spring comes to mind as a particularly egregious case that does both. Spring does things automatically, until you need to add a configuration file for every change. You need to add this wrapper and this library for this other case. I have always wanted a web development framework that works more like a game development framework. Where you still code everything you need but it doesn't hide the part where you make a window or add a listener. Which makes it a lot easier to find where things are going wrong and how to change the configuration as opposed to go to stack overflow and learn you need to add this dependency which then does things behind the scenes.

emteycz 4y ago
Node.js + Express is what you want. I'm not a Go developer, but it seems to me that the Go ecosystem also has what you want.
- gernb 4y ago
  can you give more details? My understanding is the node + express is really low level providing almost nothing except a set of chainable functions based on routes. To get any actual functionality (storing to databases, authentication, users, sys admin, etc requires writing everything yourself. The reason I like batteries included frameworks is I get all that for free and ideally it's already following best practices so I don't have to worry about security, about account recovery, about versioning new data/features, about scaling, etc
  - chii 4y ago
    > don't have to worry about security, about account recovery, about versioning new data/features, about scaling, etc with the exception of security (i take it you mean authentication), everything else is unlikely to be provided by a framework like spring directly - you'd have to choose something to provide it or write it yourself.

sjaak 4y ago

What are you talking about? What's not to like about the SimpleBeanFactoryAwareAspectInstanceFactory [1]? [1] yes, this exists

Forge36 4y ago
That I couldn't find the advanced one or the generic legume factory and ended up having to write my own as the owner wasn't currently accepting pull requests?
_Algernon_ 4y ago
https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

krainboltgreene 4y ago

> "You don't want to write "raw" html/js/sql/Java" Uhm I thought that was my job. I mean it isn't your job and it shouldn't be. Your job is to make software handle with consistency some business process or become an extended memory of some business people.

wnolens 4y ago

I've started and quit web dev projects about 4 times in the past 5 years. I'm a distributed systems dev. The complexity of the recommended tool chain is mind boggling (and I consider my day job incredibly complex, of which I have a decade of experience doing). I would have said I hate React. Finally started another project. No frameworks this time. Started with html and single js file until I needed more.. and solved the problems step by step. I'm at the point that I now see the benefits of react, but only by doing it this way could I possibly learn why.

sprkwd 4y ago
I have completely given up on web dev these days.
- commandlinefan 4y ago
  Backend is worse, they’ll make you use the Spring “framework” that makes React look like a dream.
  - AtlasBarfed 4y ago
    A couple annotations and a base application class and you're up and running with a REST service. That's considered hard?
    - presentation 4y ago
      Translated to React: a single render function and you're up and running with a webpage. That's considered hard?
  - mdoms 4y ago
    Spring is a simple MVC framework, it follows the same patterns as similar Ruby, Python, C#, PHP etc frameworks. React very much blazes its own complicated trail.
    - 4y ago

pojzon 4y ago

Company: “We dont want you to write code, because finding ppl who understand the code is hard, while finding ppl who eat generic pulp is easy”

deleted 4y ago

[deleted]

twblalock 4y ago

> "You don't want to write "raw" html/js/sql/Java" Uhm I thought that was my job. It's not your job, any more than a firefighter's job is to be a hose operator, or a nurse's job is to be a syringe operator. Your job is to produce software that meets the requirements of the business, as a member of a larger engineering organization which needs to be able to function well enough to deliver that software. Why are frameworks popular? Because they provide a standardized way for multiple engineers, and multiple engineering teams, to collaborate effectively on the same product -- and they make it easy to hire people who already know the frameworks. If everyone is writing "raw" JS/HTML/SQL/Java/whatever, they are actually building their own individual, unstandardized frameworks. That's not good for supporting software when the author leaves, and it raises the barrier enormously for onboarding new people. Above a certain scale it's just not workable. You can be cynical about this and say that it reduces engineers to interchangeable cogs in a machine. Or, you can understand why things are the way they are, understand how to succeed in this reality, and build a fulfilling career path for yourself by providing value that a mere cog cannot. I've worked with a lot of successful, happy engineers who are not cogs, and what separates them from the others is not coding skill -- it's that they all understand this reality.

emsy 4y ago
I don’t think you have a lot of experience with long software projects. The pros of frameworks are outweighed by their cons pretty quickly. This effect is accelerated by shorter support times and an ever growing number of frameworks.
- tluyben2 4y ago
  Maybe depends what tech you work in? In the Java and .NET sphere things are pretty much stable over many years. We hardly had to do any work to to move our systems (quite large ones) across the same well supported frameworks to new versions the past decades and the fact everyone in these ecosystems know the popular frameworks well and the design patterns, it scales well to many and new people.
- woojoo666 4y ago
  Do you have any examples of web apps or websites with millions of users, and don't use any frameworks? The only one I can think of is HackerNews, funny enough.

scrozart 4y ago

We use a pretty jank framework at my professional gig, and are thankfully finally beginning to plan a migration to the much better documented framework it rips off. A full rewrite is almost never worth it, but between the already poor and now mostly out of date documentation, and the apparently diminishing community, there's not really a better route. All that said, every other framework I've ever used in my personal projects has fine documentation and community support, including their peripheral deployment tooling. My experience at work seems like an outlier to other tools I see. Comments like the original post and OP make me think everyone is working in legacy systems based on aged tech from the cowboy era.

jchw 4y ago

Writing raw anything is not necessarily your job. However, a lot of people have an interesting view of things like frameworks, ORMs, and other abstractions. To some, it feels like pure all-or-nothing; but what if it didn’t have to be? Even the biggest hater of SQL database abstractions will admit there are reasons why someone would want them. But I wonder if there is an answer somewhere in the middle that could go both ways. For example, sqlc[1] provides basically all of the type safety that overbearing database frameworks might, but it lets you write plain old SQL just as you normally would, and integrates cleanly with your existing migrations solution. It doesn’t solve everything, but I have a feeling more people would like tradeoffs like these: an enormous amount of complexity does exist, to say, parse SQL and emulate DDL transactions for the sake of typing, but it stays entirely in the tool itself, and the resulting code and interfaces are completely simple and obvious code. I believe that there are multiple better middle grounds waiting to be discovered in any given niche where the options currently feel like barely-worth-it trade-offs. [1]: https://sqlc.dev https://sqlc.dev

jseban 4y ago
> Even the biggest hater of SQL database abstractions will admit there are reasons why someone would want them. There is only one reason, and it's that people don't understand how to use SQL, and that's because it's not taught in computer science degrees, and this also has strong ties to the battle between sun and oracle. And this makes database developers expensive and hard to hire. There is no reason to use an ORM if you know SQL and database modelling. The relational model is by far the most powerful tool to solve CRUD use cases, which "web development" is, and that's just simply a fact. What the ORM will do for you is automate some boilerplate mapper code, which might be a bit boring to write, but is very simple. And the downside is that it will make all of your database modelling, querying, access etc orders of magnitude more obscure and complex compared to just using SQL. And now you will waste enormous amounts of time fighting with the framework to debug the ORM and find out which kind of weird SQL statements it generates, where you would have complete control over this if you just wrote your own. The obvious solution that would benefit everyone, is to simply train your developers to use SQL, if they don't already know it, and let them take a course if they need to. Not to slap on some stupid framework and make a huge unmanageable mess of the whole system.

wackget 4y ago

As a recently-retired Magento developer of ten years... this speaks to my very soul. I've sworn to never use Magento again.

grishka 4y ago

Yes, this. There's a reason I avoid complex abstraction layers that helpfully "hide" the underlying platform from me. So, yes, in my hobby project that's a server application in Java, I use a simple, easy to understand micro-framework (sparkjava.com), a simple template engine (pebble), and a homebrew SQL query builder on the backend, and vanilla JS (compiled from TypeScript) on the frontend. Every dependency is a liability, especially the kind you can't remove without rewriting your entire project. Adding a library to my project is a very serious thing for me.

beej71 4y ago

I get this sentiment. But I think it's not so much that there's a framework but rather that the framework is an I'll fit for the problem to be solved. So you "fight" with it. In general, it seems like the easier it is to do something in the scope of the framework, the harder it is to bend the framework to do something outside it's scope. We've all seen this with frameworks that make 95% of the work really easy, and the remaining 5% is like pulling teeth. You're bending the thing where it's not meant to be bent. (And that's when new frameworks are made. :) ) But if you go lower, under the framework, it's way more flexible. As a dev, you can explore and create instead of fighting. Which is great. But really we're just on a different turtle. Raw JS has a really hard time with some problems when you try to bend it wrong. Our job is to take the right technologies for the job and make them work, no matter how abstracted they are. The pain is merely from the wrong tool. And, truly, it sucks when you have to do that.

tootie 4y ago

Every time I see a framework how quickly they can bootstrap I now consider that a red flag. The more automagic, the more you can't ever figure out why something goes wrong. It's been said that most products spend 99% of their lifetime in maintenance. If a framework wants to impress me, show me how clear the stack traces and IDE integration are. Show me how crystal clear it is to trace the execution path.

dottedmag 4y ago

I feel you. In my role as a software architect in a small company I've been booting out various "frameworks" and overly invasive libraries, because it turned out they are not delivering much, while requiring attention and forcing us to bend our code to satisfy their demands. First ones to go were various cloud libraries: AWS, Google Cloud, CloudStack. It's a plain REST. I estimate that the code that talks to Google Cloud directly is shorter than it was when the library was involved. Docker went (it's a REST with a few quirks). Kubernetes client went (same). GitHub client went. gPRC went (fortunately we're not required to talk gRPC anywhere except a few endpoints, and it turned out that Protobuf is not hard to implement if you don't have tons of schemas, and gRPC is HTTP/2+Protobuf). Finally I booted Mongo client library, because all we needed is a few requests, and implementation of Mongo wire protocol + BSON ended up costing us ~300 lines of code. Remaining libraries earn their keep: there is cryptography, XPath, JSONPath, compressors, userland IP stack, complex serialization formats. I thank the authors of these libraries, and due to some reason these libraries are also the least complicated and most compatible version-over-version.

jd_mongodb 4y ago
When you booted the Mongo client library what did you use in it's place? Were you connecting to a cluster or a single node? Lightweight clients are always interesting because of the trade offs they make.