5 ms·

My experience is that velocity slows because devs get so lost in all the accidental complexity of these frameworks and their hidden lifecycles (that they only b

My experience is that velocity slows because devs get so lost in all the accidental complexity of these frameworks and their hidden lifecycles (that they only barely grasp from their 1 tutorials worth of experience) that their velocity of delivering real business value plummets. We are much less productive than a decade ago.

whatarethembits 7y ago
In my experience, a framework atleast provides some ropes to hold onto while traversing the mess. Currently I'm stuck with a codebase with almost no documentation of a mess of legacy and new code with layers and layers of developers' opinions on top. The only way I'm able to figure anything is out is by tracing remnants of a light framework that's in place. I'm able to read the framework documentation and slowly unravel it, without it it'd be an even more monumental task! I googled/linkedin developers that have worked on this codebase for the past decade and most of them appear to have this "rockstar developer" thing going on. They are opinionated, had heated debates (from what I'm told), and often rolled their own solutions whenever possible. Now we see the result of these geniuses doing their thing. Just use a framework please, your homegrown solution is sucks. I guarantee it.
- freeopinion 7y ago
  React was somebody's homegrown solution. Same for Vue, Angular, Svelte and every other framework.
  - frandroid 7y ago
    Yeah. But they got selected by the ecosystem because they were GREAT homegrown solutions. While Angular was an accidental success, it seems that Facebook really grasped early on what was happening with React, (we all benefited from the Angular experience, warts and all) and really put in the resources necessary to make React successful, for the benefit of all.
    - orange8 7y ago
      > they got selected by the ecosystem because they were GREAT homegrown solutions While React has lots of great ideas, good marketing and the facebook brand is really what boosted its popularity. Popular does not necessarily mean great. There must be some other great homegrown frameworks out there, but we have never heard of them, since they did not start out as a facebook or google homegrown framework. > it seems that Facebook really grasped early on what was happening with React, This just is not accurate. React has also evolved a lot since its inception, they've just been careful about maintaining backwards compatibility compared to angular.
      - frandroid 6y ago
        One does not preclude the other.
    - kls 7y ago
      The only way I benefited from Angular was when all the companies who let the front-end dev come lately's talk them into using it; realized they had been sold a bill off goods and needed someone to get them out of their Angular mess. I made a good living off of getting people out of Angular 1's mess. The reality is Angular 1 was poor, it was so poor that the developers decided that they has missed the mark so much that they needed a complete rewrite to make a good product. Why people stuck with them after that is beyond me. I can still vividly remember taking over my first angular project and realizing that the devs that built it where so green that they had misused common concepts and terminology like what scope means and what state means and had conflated the two into a mess. Angular was bad and it's ashamed that it's hype pretty much relegated better toolkits like Dojo and MooTools to the dustbin of history.
- orange8 7y ago
  > Currently I'm stuck with a codebase with almost no documentation of a mess of legacy and new code with layers and layers of developers' opinions on top. If it was originally built using a framework, what framework do you think that would be? And would it still be in active development and evolving today? How do you integrate new code in a legacy or evolving framework? My experience of this says it is not really a framework vs no-framework problem, but a problem of how to keep an applications code base healthy in a world of ever changing and evolving features, developers, frameworks and technologies. I think thats the real problem you are dealing with here, and not "hot-shot developer from 10 years back didn't use the coolest stack of that time". And it is the problem you were hired to solve. If everything was working perfectly with no new features required to be added to the legacy code base, they simply wouldn't need you.
- rawoke083600 7y ago
  Ja 100% ! Ppl will argue with you and they will argue the exception not the average experience. Sure there are code messes with frameworks. I feel that ppl argue Jquery with multiple ppl and a good size project is better, just havent had enough pain. You can x my argument by 2 if its a project you join and didnt start.
nicoburns 7y ago
Did you ever work on a JQuery codebase? (JQuery was an almost 1:1 mapping to browser APIs, do it's more or less equivalent to vanillaJS). Codebases based on modern frameworks, especially React, are much less complex than codebases based on the old approach. Back then you'd get lost in the weeds of DOM manipulation, and it'd be hard to see the big picture at all. In my experience most of the incidental complexity in modern apps comes from inexperienced devs doing things that simply didn't need to be done in the first place. Very little of it comes from the frameworks.
- yitianjian 7y ago
  I also feel modern web apps are just much more complex than those from the jQuery era. So codebases have to do a lot more. It's hard to find a 1:1 mapping, as we just didn't expect as much out of the web in those days.
  - TedDoesntTalk 7y ago
    Complete BS. Not true at all. the jquery era had ajax with dynamic dom updates, dynamic svg, css, and many things we have today except for websockets, web usb, mic, camera, and other devices. the difficulty was more around each browser implementing things differently. and css was a nightmare. just to center something horizontally or vertically (or both) took patience.
    - girvo 7y ago
      It’s not “Complete BS.” — just because we had those features does not mean most businesses used them to the same extent we do today. I was deep in the front-end weeds in 2007 and onwards, and while I may have been doing some neat stuff then, the complexity pales in comparison to the sheer amount of business logic that now lives client-side.
      - TedDoesntTalk 6y ago
        That's because you have 13 more years of experience now. Or you like to revise history.
frandroid 7y ago
> (that they only barely grasp from their 1 tutorials worth of experience) If you're going to staff your entire corporate dev team with a bunch of green developers, yeah, things will be nasty. That's not the frameworks' fault though, that's just a straw man.
- pailhead 7y ago
  Agreed. Framework or no framework, general software development principles should still apply. Need experienced leads and architects

whatarethembits 7y ago

In my experience, a framework atleast provides some ropes to hold onto while traversing the mess. Currently I'm stuck with a codebase with almost no documentation of a mess of legacy and new code with layers and layers of developers' opinions on top. The only way I'm able to figure anything is out is by tracing remnants of a light framework that's in place. I'm able to read the framework documentation and slowly unravel it, without it it'd be an even more monumental task! I googled/linkedin developers that have worked on this codebase for the past decade and most of them appear to have this "rockstar developer" thing going on. They are opinionated, had heated debates (from what I'm told), and often rolled their own solutions whenever possible. Now we see the result of these geniuses doing their thing. Just use a framework please, your homegrown solution is sucks. I guarantee it.

freeopinion 7y ago
React was somebody's homegrown solution. Same for Vue, Angular, Svelte and every other framework.
- frandroid 7y ago
  Yeah. But they got selected by the ecosystem because they were GREAT homegrown solutions. While Angular was an accidental success, it seems that Facebook really grasped early on what was happening with React, (we all benefited from the Angular experience, warts and all) and really put in the resources necessary to make React successful, for the benefit of all.
  - orange8 7y ago
    > they got selected by the ecosystem because they were GREAT homegrown solutions While React has lots of great ideas, good marketing and the facebook brand is really what boosted its popularity. Popular does not necessarily mean great. There must be some other great homegrown frameworks out there, but we have never heard of them, since they did not start out as a facebook or google homegrown framework. > it seems that Facebook really grasped early on what was happening with React, This just is not accurate. React has also evolved a lot since its inception, they've just been careful about maintaining backwards compatibility compared to angular.
    - frandroid 6y ago
      One does not preclude the other.
  - kls 7y ago
    The only way I benefited from Angular was when all the companies who let the front-end dev come lately's talk them into using it; realized they had been sold a bill off goods and needed someone to get them out of their Angular mess. I made a good living off of getting people out of Angular 1's mess. The reality is Angular 1 was poor, it was so poor that the developers decided that they has missed the mark so much that they needed a complete rewrite to make a good product. Why people stuck with them after that is beyond me. I can still vividly remember taking over my first angular project and realizing that the devs that built it where so green that they had misused common concepts and terminology like what scope means and what state means and had conflated the two into a mess. Angular was bad and it's ashamed that it's hype pretty much relegated better toolkits like Dojo and MooTools to the dustbin of history.
orange8 7y ago
> Currently I'm stuck with a codebase with almost no documentation of a mess of legacy and new code with layers and layers of developers' opinions on top. If it was originally built using a framework, what framework do you think that would be? And would it still be in active development and evolving today? How do you integrate new code in a legacy or evolving framework? My experience of this says it is not really a framework vs no-framework problem, but a problem of how to keep an applications code base healthy in a world of ever changing and evolving features, developers, frameworks and technologies. I think thats the real problem you are dealing with here, and not "hot-shot developer from 10 years back didn't use the coolest stack of that time". And it is the problem you were hired to solve. If everything was working perfectly with no new features required to be added to the legacy code base, they simply wouldn't need you.
rawoke083600 7y ago
Ja 100% ! Ppl will argue with you and they will argue the exception not the average experience. Sure there are code messes with frameworks. I feel that ppl argue Jquery with multiple ppl and a good size project is better, just havent had enough pain. You can x my argument by 2 if its a project you join and didnt start.

nicoburns 7y ago

Did you ever work on a JQuery codebase? (JQuery was an almost 1:1 mapping to browser APIs, do it's more or less equivalent to vanillaJS). Codebases based on modern frameworks, especially React, are much less complex than codebases based on the old approach. Back then you'd get lost in the weeds of DOM manipulation, and it'd be hard to see the big picture at all. In my experience most of the incidental complexity in modern apps comes from inexperienced devs doing things that simply didn't need to be done in the first place. Very little of it comes from the frameworks.

yitianjian 7y ago
I also feel modern web apps are just much more complex than those from the jQuery era. So codebases have to do a lot more. It's hard to find a 1:1 mapping, as we just didn't expect as much out of the web in those days.
- TedDoesntTalk 7y ago
  Complete BS. Not true at all. the jquery era had ajax with dynamic dom updates, dynamic svg, css, and many things we have today except for websockets, web usb, mic, camera, and other devices. the difficulty was more around each browser implementing things differently. and css was a nightmare. just to center something horizontally or vertically (or both) took patience.
  - girvo 7y ago
    It’s not “Complete BS.” — just because we had those features does not mean most businesses used them to the same extent we do today. I was deep in the front-end weeds in 2007 and onwards, and while I may have been doing some neat stuff then, the complexity pales in comparison to the sheer amount of business logic that now lives client-side.
    - TedDoesntTalk 6y ago
      That's because you have 13 more years of experience now. Or you like to revise history.

frandroid 7y ago

> (that they only barely grasp from their 1 tutorials worth of experience) If you're going to staff your entire corporate dev team with a bunch of green developers, yeah, things will be nasty. That's not the frameworks' fault though, that's just a straw man.

pailhead 7y ago
Agreed. Framework or no framework, general software development principles should still apply. Need experienced leads and architects