9 ms·

> With vanilla JS it's the wild west. In my experience in the corporate world it's just as much the wild west even with using popular frameworks. Frameworks a

> With vanilla JS it's the wild west. In my experience in the corporate world it's just as much the wild west even with using popular frameworks. Frameworks aren't a substitute for discipline or organization.

a_wild_dandan 7y ago
I wonder if those chaotic corporate experiences would've been far worse if not for the frameworks. They're just so useful for significantly constraining the solution space that you can't get too far into the weeds even when lacking discipline/organization.
- DagAgren 7y ago
  This, is my experience, tends to just chase the mess deeper into the architecture, which may not be a good tradeoff.
- corebit 7y ago
  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 7y 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.
  - 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 7y 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
- austincheney 7y ago
  I don't think frameworks make any difference in this regard. The most important thing to remember is that developers are people. Most everyone benefits from direction and guidance without regard for their seniority. Some of that guidance can be automated by applying appropriate limits or certain safeguards to the process, but is generally not something that can be outsourced directly to a tool. I think of that as something akin to letting a television parent your child.
  - kls 7y ago
    They do though, frameworks are just an amalgamations of patterns and practices codified. If you go Vanilla JS you are going to build abstractions on top of it to make your patterns and practices reusable and structured. Given enough time you are going to build a framework that enforces your patterns and practices. So why not just adopt proven ones out of the gate. But verify that they are indeed proven ones before just jumping on a bandwagon. An example I would highlight is, Redux it's great and it has helped a lot of developers that don't know state patterns learn to deal with state, but it only taught them half of what they need to know. The other part of state is not allowing applications to fall into an inconstant state that it should not be in. Redux intentionally ducked this one because state management is a complex task and building a state machine makes the cognitive overhead much more complex but that is what developers following correct patterns should be doing, they should be using a state machine and it is the reason I use XState in my projects over using Redux as it is a full state management solution, that gives me a guarantee that my state is both preserved and consistent. https://timdeschryver.dev/blog/my-love-letter-to-xstate-and-statecharts https://timdeschryver.dev/blog/my-love-letter-to-xstate-and-...
    - austincheney 7y ago
      > Given enough time you are going to build a framework I have heard this argument countless times over the last decade and its not based on anything. I suppose if you have never written code without a framework and for the first time attempt to write some new application it would make sense that your application ends up looking that thing you are familiar with. Beyond that this entire position is absolutely meritless. What I find most frustrating about this sentiment is the lack of originality it codifies. Many JavaScript developers I speak with online are absolutely certain the language is limited to building static pages and SPAs. That's it. And, it absolutely blows my mind that their imagination is so immediately limited. Logically, though, since there is nothing else to build but SPAs and frameworks are great at building SPAs it must not make sense to even not use a framework. That line of thinking leaves me speechless, literally. I just spot responding and walk away.
- lhorie 7y ago
  > you can't get too far into the weeds Oh, but you can. It can go anywhere from realizing that your extensive enzyme-based test suite turned out to be garbage because nobody really grasped the value proposition of snapshots at the beginning of the project, to the entire application aging extremely poorly because it's written in Angular 1 that is a mix of needless directives and jQuery call hacks (both true stories).
- Scarbutt 7y ago
  Github seems to be doing fine with vanilla JS.
ddek 7y ago
You’re write. I’m a tech lead in an ‘enterprise’ team, and the fight against spaghetti is so real. I feel a lot of enterprise devs are older, and more set in their ways. It’a not just teaching them new technology any more - I have to fundamentally shift their approach. All the while being 20 years younger and less ‘experienced’ than them. It’s slow progress. Every time I relax control within a few hours I have to bring it back. One guy today tried to set up a deployment of a prepackaged service that involved building the service (in debug configuration), then running that. I had to explain that deployments out of /bin/Debug is a bit of a red flag. I’m not sure how you can miss that myself, but here we are.
- jtms 7y ago
  *right (unless wordplay was intentional)
- jaywalk 7y ago
  I have to explain to "senior" developers why a deployment process involving keeping the source code on the prod server and building it with Visual Studio on the prod server is not a great idea.
- freeopinion 7y ago
  That has nothing to do with being older. That guy was similarly reckless when they were 20 years younger.
- surfmike 7y ago
  You mean as opposed to Release? Or something else?
vinniejames 7y ago
The problem in corporate is too many developers trying to do things all at once 10 different ways, without anyone pushing to maintain consistency
- president 7y ago
  Maybe this is just a problem where I work (large enterprise SV company) but a big issue is that a lot of engineers know better but they do a shit job because they are looking to deliver ASAP so they get brownie points for finishing a task quickly. These people are just looking to get promoted fast and they will have jumped ship long before they are held responsible for the maintenance burden of their spaghetti code. At the same time, people who actually take the time to write maintainable code get the shaft because they appear to be unproductive and are "blocking" progress. Of course, a good manager can see through this but good managers are rare where I work.
  - dajomu 7y ago
    This could be read the other way too. In my experience there is a spectrum from reckless to needlessly perfectionist, neither of which approaches are very helpful. Being focused on delivery is not necessarily a bad thing. But then I've mostly worked in small startups, so perhaps it's different elsewhere.
rukuu001 7y ago
In my experience any team anywhere can turn any codebase into soup! Strong tech leadership that provides good examples, institutes code reviews, establishes & follows standards etc is where nice code bases come from (even in tiny teams)
mmcnl 7y ago
Ofcourse they are, I know a good bit of React and I can get a good understanding of any reasonably sized React project within a short amount of time _because_ it's a React project. People may still be people and do weird stuff, but that's a given in anything you do.
ulisesrmzroche 7y ago
A framework enforces some organization by its very nature, even the barebone ones. Otherwise they usually break. Plus, the popular ones will have a community that sets some standards, example, off the top of my head: python significant white space Frameworks are not a substitute for engineering standards but anyone whose really interested in that, pay the bills interested, first thing they do is look for frameworks
pailhead 7y ago
In my experience this is not the case if you have experienced leads and architects. Just using a framework for the sake of using a framework can be just as bad or worse.
edem 7y ago
I came here for this comment, thank you sir.
Drew_ 7y ago
The difference now is it's only a "wild west" as far as app structure goes. Developers still need to put a lot of thought into component composition and app state to maintain a quality code base. Previously you had to do all of that AND put a lot of thought into how to update the UI correctly and efficiently. New approaches and frameworks removed the complexity of that last step.

a_wild_dandan 7y ago

I wonder if those chaotic corporate experiences would've been far worse if not for the frameworks. They're just so useful for significantly constraining the solution space that you can't get too far into the weeds even when lacking discipline/organization.

DagAgren 7y ago
This, is my experience, tends to just chase the mess deeper into the architecture, which may not be a good tradeoff.
corebit 7y ago
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 7y 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.
- 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 7y 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
austincheney 7y ago
I don't think frameworks make any difference in this regard. The most important thing to remember is that developers are people. Most everyone benefits from direction and guidance without regard for their seniority. Some of that guidance can be automated by applying appropriate limits or certain safeguards to the process, but is generally not something that can be outsourced directly to a tool. I think of that as something akin to letting a television parent your child.
- kls 7y ago
  They do though, frameworks are just an amalgamations of patterns and practices codified. If you go Vanilla JS you are going to build abstractions on top of it to make your patterns and practices reusable and structured. Given enough time you are going to build a framework that enforces your patterns and practices. So why not just adopt proven ones out of the gate. But verify that they are indeed proven ones before just jumping on a bandwagon. An example I would highlight is, Redux it's great and it has helped a lot of developers that don't know state patterns learn to deal with state, but it only taught them half of what they need to know. The other part of state is not allowing applications to fall into an inconstant state that it should not be in. Redux intentionally ducked this one because state management is a complex task and building a state machine makes the cognitive overhead much more complex but that is what developers following correct patterns should be doing, they should be using a state machine and it is the reason I use XState in my projects over using Redux as it is a full state management solution, that gives me a guarantee that my state is both preserved and consistent. https://timdeschryver.dev/blog/my-love-letter-to-xstate-and-statecharts https://timdeschryver.dev/blog/my-love-letter-to-xstate-and-...
  - austincheney 7y ago
    > Given enough time you are going to build a framework I have heard this argument countless times over the last decade and its not based on anything. I suppose if you have never written code without a framework and for the first time attempt to write some new application it would make sense that your application ends up looking that thing you are familiar with. Beyond that this entire position is absolutely meritless. What I find most frustrating about this sentiment is the lack of originality it codifies. Many JavaScript developers I speak with online are absolutely certain the language is limited to building static pages and SPAs. That's it. And, it absolutely blows my mind that their imagination is so immediately limited. Logically, though, since there is nothing else to build but SPAs and frameworks are great at building SPAs it must not make sense to even not use a framework. That line of thinking leaves me speechless, literally. I just spot responding and walk away.
lhorie 7y ago
> you can't get too far into the weeds Oh, but you can. It can go anywhere from realizing that your extensive enzyme-based test suite turned out to be garbage because nobody really grasped the value proposition of snapshots at the beginning of the project, to the entire application aging extremely poorly because it's written in Angular 1 that is a mix of needless directives and jQuery call hacks (both true stories).
Scarbutt 7y ago
Github seems to be doing fine with vanilla JS.

ddek 7y ago

You’re write. I’m a tech lead in an ‘enterprise’ team, and the fight against spaghetti is so real. I feel a lot of enterprise devs are older, and more set in their ways. It’a not just teaching them new technology any more - I have to fundamentally shift their approach. All the while being 20 years younger and less ‘experienced’ than them. It’s slow progress. Every time I relax control within a few hours I have to bring it back. One guy today tried to set up a deployment of a prepackaged service that involved building the service (in debug configuration), then running that. I had to explain that deployments out of /bin/Debug is a bit of a red flag. I’m not sure how you can miss that myself, but here we are.

jtms 7y ago
*right (unless wordplay was intentional)
jaywalk 7y ago
I have to explain to "senior" developers why a deployment process involving keeping the source code on the prod server and building it with Visual Studio on the prod server is not a great idea.
freeopinion 7y ago
That has nothing to do with being older. That guy was similarly reckless when they were 20 years younger.
surfmike 7y ago
You mean as opposed to Release? Or something else?

vinniejames 7y ago

The problem in corporate is too many developers trying to do things all at once 10 different ways, without anyone pushing to maintain consistency

president 7y ago
Maybe this is just a problem where I work (large enterprise SV company) but a big issue is that a lot of engineers know better but they do a shit job because they are looking to deliver ASAP so they get brownie points for finishing a task quickly. These people are just looking to get promoted fast and they will have jumped ship long before they are held responsible for the maintenance burden of their spaghetti code. At the same time, people who actually take the time to write maintainable code get the shaft because they appear to be unproductive and are "blocking" progress. Of course, a good manager can see through this but good managers are rare where I work.
- dajomu 7y ago
  This could be read the other way too. In my experience there is a spectrum from reckless to needlessly perfectionist, neither of which approaches are very helpful. Being focused on delivery is not necessarily a bad thing. But then I've mostly worked in small startups, so perhaps it's different elsewhere.

rukuu001 7y ago

In my experience any team anywhere can turn any codebase into soup! Strong tech leadership that provides good examples, institutes code reviews, establishes & follows standards etc is where nice code bases come from (even in tiny teams)

mmcnl 7y ago

Ofcourse they are, I know a good bit of React and I can get a good understanding of any reasonably sized React project within a short amount of time _because_ it's a React project. People may still be people and do weird stuff, but that's a given in anything you do.

ulisesrmzroche 7y ago

A framework enforces some organization by its very nature, even the barebone ones. Otherwise they usually break. Plus, the popular ones will have a community that sets some standards, example, off the top of my head: python significant white space Frameworks are not a substitute for engineering standards but anyone whose really interested in that, pay the bills interested, first thing they do is look for frameworks

pailhead 7y ago

In my experience this is not the case if you have experienced leads and architects. Just using a framework for the sake of using a framework can be just as bad or worse.

edem 7y ago

I came here for this comment, thank you sir.

Drew_ 7y ago

The difference now is it's only a "wild west" as far as app structure goes. Developers still need to put a lot of thought into component composition and app state to maintain a quality code base. Previously you had to do all of that AND put a lot of thought into how to update the UI correctly and efficiently. New approaches and frameworks removed the complexity of that last step.