10 ms·

I've worked in a few roughly-the-same-size (~50 engineers) web development shops. It's always the same. Doesn't matter if it's React, Angular, Class based compo

I've worked in a few roughly-the-same-size (~50 engineers) web development shops. It's always the same. Doesn't matter if it's React, Angular, Class based components, Functional components with hooks, Just Some HTML, PHP, Rails views, etc. The frontend just collects the cruft of a product organization changing course very frequently. There are always a dozen half-finished fix-the-world ideas conflicting with each other, half-finished move-to-new-framework initiatives. I just mean to say that when I hear "it's because React" or "it's because rails views", any other of the infinite variations of this, I kind of just tune out. Some part of your organizations chaos is going to reflect in code, and honestly I'd rather it be in a big ball of frontend than in the data models, infrastructure, etc.

kristopolous 4y ago
They mostly encourage bad practice by design and people do what these tools give an affordance for which is why the results are broken.
- bobthepanda 4y ago
  People can write bad things in every language. "It takes a lot of skill to write Java in any language." is a pithy quote for a reason. The issue is usually frontend pedagogy or the lack of it. Maybe things have changed but when I graduated undergrad CS in 2017 the extent of frontend being taught in my school by professors was "hand write some HTML, maybe some PHP if you're lucky". I've never met anyone who learned frontend anything in school to a degree that matters, so everyone is either learning from other junior devs on the job, from blog posts that are often wrong, or from a backend engineer who was pressed into learning frontend. Yes, JS has a very tortured history coming from the fact that it was not intended to be the long-term development language for web interactivity from the start, but we also don't really teach how to do it properly.
  - kristopolous 4y ago
    woah woah hold on there young one This isn't that. My hostile working definition of a framework is something that . breaks core assumptions about a language or system . limits what a user is permitted to do . increases complexities by adding new abstractions . has non-specific specifications by using unclear and imprecise language At the end you are hardly writing software. Instead you're deep into a world of new abstractions and are fundamentally limited by these abstractions. Frameworks work at a subconcious level. They permit the users to be constantly busy as they chaperone codebases which would otherwise have long term stability all while staking the claim that it's the fastest and easiest solution. Because frameworks exist primarily in a product space it's worth looking at their value proposition. Frameworks essentially act as a modern facilitator to what Frederick Winslow Talor called "Soldiering" in the text "Scientific Management". Essentially this means "the evasion of work or duty", the workers you wish to provide to have a vested interest in their own well-being and do not benefit from working above the defined rate of work when it will not increase their remuneration. Normally a manager would have every reason to dismiss these programmers. To combat this natural inclination, a proper framework makes sure this is impossible by making them unfirable. Given a product: . Systems should not continue to function without the programmer . Code has to constantly be rewritten in order to achieve the same ends Also it permits the users to go on constant employer funded vacations to conferences and training sessions. From a professional programmer's point of view, the primary goals of any framework are to provide the users with the following: . Job security by ensuring brittle applications . Endless tasks by ensuring endless complexity . A sense of elitism and entitlement . No expectations of deliverables . Be vague enough so blame can get shifted if things break By making every project asymptotically impossible to deliver vaporware, the ideal framework ensures that people are always doing something while at the same time nothing ever gets done. The old is dying and the new cannot be born; in this interregnum they're on salary so they make it last as long as possible. In trades where there's no guilds or unions, there's a tendency to create career protection through other forms of tribal qualification systems or arcane knowledge. Making things intentionally complicated so that only a select few people can comprehend them is a common way to capture and exercise power. People adopt the patterns because they want to have the perceived protective properties of the obscurities. Worlds of irrelevant relations and materially meaningless abstractions are essentially how fields such as fortune telling and astrology continue unabated. The form becomes the function and the elaborations its aesthetic. ... Btw, this is a collections of excerpts from a 40 page document I have on the psychology and function of frameworks on how the most popular ones service human emotion that I've been working on off and on for a while.
  - DC-3 4y ago
    > Maybe things have changed but when I graduated undergrad CS in 2017 the extent of frontend being taught in my school by professors was "hand write some HTML, maybe some PHP if you're lucky" And rightly so, because frontend web development is not Computer Science.
  - Swizec 4y ago
    > Maybe things have changed but when I graduated undergrad CS in 2017 the extent of frontend being taught in my school by professors was "hand write some HTML, maybe some PHP if you're lucky" Here's a secret nobody told you: You don't need to learn frontend specifics. All the same lessons from business software engineering apply. I not-graduated comp sci in 2012 and have been building webapps since before jQuery was cool. It's nothing special. The biggest problems are always the same: data and domain modeling, managing complexity, teamwork, and state consistency. If your comp sci degree didn't teach you how to apply solutions to those problems in any context – frontend, backend, iOS, firmware, desktop app, Android, or data pipeline – then it was a worthless degree and you should get your money back. The point of comp sci is to learn about the ideas behind the scenes, not about specific frameworks.
    - bobthepanda 4y ago
      Eh, to some degree you do get a starting point in uni for various things. You’ll learn basic models for systems or databases as part of core requirements. If a web course exists, it’s most likely optional and out of date. Web is certainly a different context, and some people struggle to pick it up. There’s no authoritative book like the C Programming Language, and the web is full of wrong information that sometimes comes above more authoratitve sources like MDN in Google results.
      - mmcdermott 4y ago
        If we're talking language level (even in C, you'd usually be using other libraries and APIs even if it's just POSIX or curses), I'd argue that "JavaScript: The Good Parts: The Good Parts" is probably the most authoritative book out there.
      - Swizec 4y ago
        > Web is certainly a different context I mean it's a thin or fat client talking to a fat or thin data source over a network. "We" have been building systems like that since the 1950's.
        4y ago
dpweb 4y ago
I'm trying to select a good framework and coming from long before react, having a tough time finding why shouldn't use just custom elements with no framework. Which is already built in. customElements.define('my-element', class MyElement extends HTMLElement { ... }) I can manage state within the component, app state in window.state. Coding up a simple reactivity is really pretty straight forward. Now, for this feature and that - maybe not - but do we need all those features. Programmers like to write code, so every framework always gets bigger and more complicated. I understand and respect the problem react is trying to solve, I just don't see it as much different than the js world before async/await and fetch, etc.. callback hell - which I saw as much more prickly issues.
- eek2121 4y ago
  Compatibility for starters: https://caniuse.com/custom-elementsv1 https://caniuse.com/custom-elementsv1
- erikpukinskis 4y ago
  If we’re talking about class-based components then I agree with you. React doesn’t do much… maybe some performance benefits, and maybe you can avoid some complex DOM manipulation here and there, but with the extra abstraction required that all might be a wash. But with functional components I think React gives you something substantially more debuggable than an object instance with random method calls that manipulate the DOM. React functional components (with hooks) mandate a very specific control flow that probably halves the debugging surface for any given bug, saving time. You do have to exercise restraint when incorporating third party libraries, but if you can do that it can be a very rapid development environment.
  - dpweb 4y ago
    Any good articles I can check out that go into this in depth, or should I just check out the tutorials/documentation? Thanks
  - jrochkind1 4y ago
    I'm not sure if I'm following, are you saying that class-based components (whether React or not) could be characterized as "an object instance with random method calls that manipulate the DOM", and thus React functional components offer an advantage to them?
taeric 4y ago
It really is hard to understate how damaging the half-finished ideas in the code base can be. To the point that I often prefer to stay on something I don't like, if I'm not positive I can finish moving completely off of it.
- babyshake 4y ago
  > It really is hard to understate how damaging the half-finished ideas in the code base can be. People get promoted for all the shiny new things they do, not for the discipline they show in only focusing on what really matters.
  - mjr00 4y ago
    > People get promoted for all the shiny new things they do, not for the discipline they show in only focusing on what really matters. Depends on the company and its values. I've been in companies where engineers who don't care about the business/customers were promoted by other engineers who don't care about the business/customers, and yeah, promotions were getting handed out for engineers who did a hacky prototype integration with the latest & greatest NoSQL Big Data GraphQL Blockchain OSS project while solving no actual problems. I've also been other places (Amazon) where customers really are front and center, and spending time on cool engineering projects that serve no customer purpose meant absolutely nothing when you wrote up your promotion doc.
bot41 4y ago
> There are always [] half-finished fix-the-world ideas conflicting with each other, I work in a code base like this. People's suggestion? Introduce React!
Chris_Newton 4y ago
I’ve had similar experiences, but I wonder how much of this is truly inevitable because software development is complicated and requirements often change along the way, and how much is simply bad management. I’ve noticed that over time the prevailing culture in software development has drifted more and more towards “thinking small”. This has certainly been encouraged by the shift to web and mobile apps in an always-connected, always-updatable world. First it was just the code. Short functions, few parameters, shallow nesting. Make everything testable and maintainable! Then it was the commits. Release early, release often, merge WIP straight into master in your CI/CD system. We need fast feedback and short cycles to avoid unnecessary conflicts! Then it was the whole process. Break everything down, do one small thing at once, move it across that Kanban board, next sprint please. We need focus and visible progress! The danger with all of these is the same: they come from good intentions and even have an element of truth behind them, but they can also mean the big picture gets lost. There’s no coherent vision shared by everyone involved. No-one is watching all the extra dependencies that connect the many small parts. Tech debt compounds. Eventually we are forced to acknowledge that there are “challenges” but even then we somehow convince ourselves that those were inevitable, even though they weren’t really there before. Yes, of course our early-merged WIP hidden behind a feature flag in CI is completely different to the feature branch we used to use. Now we know everything builds before it can be merged, even though nothing is really testing that all the different combinations of WIP actually work together, so that’s a big improvement on before. And since obviously we have a reliable, automated process for backing out any unfinished code that doesn’t make the cut later, we’re also much better off than the old situation where we’d just have sidelined that feature branch and never merged into the next level up in the first place! In the real world, this leads to exactly the mess described in the parent comment. There’s no coherent vision for anything big that is shared by everyone involved, no considered and consistent structure for the software architecture or the APIs or the data formats. If we rely on emergent properties that evolve organically, we also run into evolutionary dead-ends, and what survives might work but also be messy. Personally, I don’t really buy the argument that this is inevitable. Five players can make a great jazz band. With 100 players, you probably want an orchestra with a conductor and sheets and the occasional featured soloist. Neither jazz nor orchestration is “better” or “worse” in absolute terms but they are certainly different.
indymike 4y ago
> Some part of your organizations chaos is going to reflect in code, This is reality, and why organizational chaos is so painful for engineers.
exclusiv 4y ago
> Some part of your organizations chaos is going to reflect in code, and honestly I'd rather it be in a big ball of frontend than in the data models, infrastructure, etc. I disagree. I like my frontend to be as dumb as possible. It gets data and reacts to it as simple as possible. Seen too many frontends with a lot of data logic and it becomes extremely brittle, harder to test. These are the ones where the frontend devs are getting data from the API and creating new structures, transforming it, conditionals everywhere, etc. It requires way more discipline to ensure that frontend devs aren't recreating the wheel and writing duplicate code as the app and components evolve, and it's worse for larger codebases of course. They need to build some new component and go - ok I got the data from the API and now I need to do the thing that's already been done by another frontend dev for another component because we've allowed the frontend to be responsible for transforming the data. But if they aren't aware of this, then you get a lot of dupe code. Just have your backend API provide the contract. Setup resources/transformers as needed on the backend instead of littering the frontend with that logic.
- markeibes 4y ago
  Why? What's the difference?
  - BoorishBears 4y ago
    Backend doesn't need to deal with animations, styling, browser support, responsiveness, etc.
  - yurishimo 4y ago
    You’re likely duplicating a lot of business logic between the frontend and backend. You can do it, but if you forgot to update one implementation, it could get ugly fast.
- cercatrova 4y ago
  That's why I like GraphQL, you get exactly the data you request, no transformation necessary.
mzzter 4y ago
relevant codeless code parable: http://thecodelesscode.com/case/123 http://thecodelesscode.com/case/123
draw_down 4y ago
steve_taylor 4y ago
I completely agree. And the thing with different frameworks is they let you scale to varying heights of complexity before you reach those high-level problems. For example, I find that functional components can have more complexity in terms of logic than class components before they become a complete mess. React itself allowed us to go way beyond jQuery before becoming a complete mess. I don’t think there will ever be a framework that saves us from that as long as managers keep doing what managers do.
earthboundkid 4y ago
If you read Programming As If People Mattered from 1992, the frontend mess was true then too.

kristopolous 4y ago

They mostly encourage bad practice by design and people do what these tools give an affordance for which is why the results are broken.

bobthepanda 4y ago
People can write bad things in every language. "It takes a lot of skill to write Java in any language." is a pithy quote for a reason. The issue is usually frontend pedagogy or the lack of it. Maybe things have changed but when I graduated undergrad CS in 2017 the extent of frontend being taught in my school by professors was "hand write some HTML, maybe some PHP if you're lucky". I've never met anyone who learned frontend anything in school to a degree that matters, so everyone is either learning from other junior devs on the job, from blog posts that are often wrong, or from a backend engineer who was pressed into learning frontend. Yes, JS has a very tortured history coming from the fact that it was not intended to be the long-term development language for web interactivity from the start, but we also don't really teach how to do it properly.
- kristopolous 4y ago
  woah woah hold on there young one This isn't that. My hostile working definition of a framework is something that . breaks core assumptions about a language or system . limits what a user is permitted to do . increases complexities by adding new abstractions . has non-specific specifications by using unclear and imprecise language At the end you are hardly writing software. Instead you're deep into a world of new abstractions and are fundamentally limited by these abstractions. Frameworks work at a subconcious level. They permit the users to be constantly busy as they chaperone codebases which would otherwise have long term stability all while staking the claim that it's the fastest and easiest solution. Because frameworks exist primarily in a product space it's worth looking at their value proposition. Frameworks essentially act as a modern facilitator to what Frederick Winslow Talor called "Soldiering" in the text "Scientific Management". Essentially this means "the evasion of work or duty", the workers you wish to provide to have a vested interest in their own well-being and do not benefit from working above the defined rate of work when it will not increase their remuneration. Normally a manager would have every reason to dismiss these programmers. To combat this natural inclination, a proper framework makes sure this is impossible by making them unfirable. Given a product: . Systems should not continue to function without the programmer . Code has to constantly be rewritten in order to achieve the same ends Also it permits the users to go on constant employer funded vacations to conferences and training sessions. From a professional programmer's point of view, the primary goals of any framework are to provide the users with the following: . Job security by ensuring brittle applications . Endless tasks by ensuring endless complexity . A sense of elitism and entitlement . No expectations of deliverables . Be vague enough so blame can get shifted if things break By making every project asymptotically impossible to deliver vaporware, the ideal framework ensures that people are always doing something while at the same time nothing ever gets done. The old is dying and the new cannot be born; in this interregnum they're on salary so they make it last as long as possible. In trades where there's no guilds or unions, there's a tendency to create career protection through other forms of tribal qualification systems or arcane knowledge. Making things intentionally complicated so that only a select few people can comprehend them is a common way to capture and exercise power. People adopt the patterns because they want to have the perceived protective properties of the obscurities. Worlds of irrelevant relations and materially meaningless abstractions are essentially how fields such as fortune telling and astrology continue unabated. The form becomes the function and the elaborations its aesthetic. ... Btw, this is a collections of excerpts from a 40 page document I have on the psychology and function of frameworks on how the most popular ones service human emotion that I've been working on off and on for a while.
- DC-3 4y ago
  > Maybe things have changed but when I graduated undergrad CS in 2017 the extent of frontend being taught in my school by professors was "hand write some HTML, maybe some PHP if you're lucky" And rightly so, because frontend web development is not Computer Science.
- Swizec 4y ago
  > Maybe things have changed but when I graduated undergrad CS in 2017 the extent of frontend being taught in my school by professors was "hand write some HTML, maybe some PHP if you're lucky" Here's a secret nobody told you: You don't need to learn frontend specifics. All the same lessons from business software engineering apply. I not-graduated comp sci in 2012 and have been building webapps since before jQuery was cool. It's nothing special. The biggest problems are always the same: data and domain modeling, managing complexity, teamwork, and state consistency. If your comp sci degree didn't teach you how to apply solutions to those problems in any context – frontend, backend, iOS, firmware, desktop app, Android, or data pipeline – then it was a worthless degree and you should get your money back. The point of comp sci is to learn about the ideas behind the scenes, not about specific frameworks.
  - bobthepanda 4y ago
    Eh, to some degree you do get a starting point in uni for various things. You’ll learn basic models for systems or databases as part of core requirements. If a web course exists, it’s most likely optional and out of date. Web is certainly a different context, and some people struggle to pick it up. There’s no authoritative book like the C Programming Language, and the web is full of wrong information that sometimes comes above more authoratitve sources like MDN in Google results.
    - mmcdermott 4y ago
      If we're talking language level (even in C, you'd usually be using other libraries and APIs even if it's just POSIX or curses), I'd argue that "JavaScript: The Good Parts: The Good Parts" is probably the most authoritative book out there.
    - Swizec 4y ago
      > Web is certainly a different context I mean it's a thin or fat client talking to a fat or thin data source over a network. "We" have been building systems like that since the 1950's.
      - 4y ago

dpweb 4y ago

I'm trying to select a good framework and coming from long before react, having a tough time finding why shouldn't use just custom elements with no framework. Which is already built in. customElements.define('my-element', class MyElement extends HTMLElement { ... }) I can manage state within the component, app state in window.state. Coding up a simple reactivity is really pretty straight forward. Now, for this feature and that - maybe not - but do we need all those features. Programmers like to write code, so every framework always gets bigger and more complicated. I understand and respect the problem react is trying to solve, I just don't see it as much different than the js world before async/await and fetch, etc.. callback hell - which I saw as much more prickly issues.

eek2121 4y ago
Compatibility for starters: https://caniuse.com/custom-elementsv1 https://caniuse.com/custom-elementsv1
erikpukinskis 4y ago
If we’re talking about class-based components then I agree with you. React doesn’t do much… maybe some performance benefits, and maybe you can avoid some complex DOM manipulation here and there, but with the extra abstraction required that all might be a wash. But with functional components I think React gives you something substantially more debuggable than an object instance with random method calls that manipulate the DOM. React functional components (with hooks) mandate a very specific control flow that probably halves the debugging surface for any given bug, saving time. You do have to exercise restraint when incorporating third party libraries, but if you can do that it can be a very rapid development environment.
- dpweb 4y ago
  Any good articles I can check out that go into this in depth, or should I just check out the tutorials/documentation? Thanks
- jrochkind1 4y ago
  I'm not sure if I'm following, are you saying that class-based components (whether React or not) could be characterized as "an object instance with random method calls that manipulate the DOM", and thus React functional components offer an advantage to them?

taeric 4y ago

It really is hard to understate how damaging the half-finished ideas in the code base can be. To the point that I often prefer to stay on something I don't like, if I'm not positive I can finish moving completely off of it.

babyshake 4y ago
> It really is hard to understate how damaging the half-finished ideas in the code base can be. People get promoted for all the shiny new things they do, not for the discipline they show in only focusing on what really matters.
- mjr00 4y ago
  > People get promoted for all the shiny new things they do, not for the discipline they show in only focusing on what really matters. Depends on the company and its values. I've been in companies where engineers who don't care about the business/customers were promoted by other engineers who don't care about the business/customers, and yeah, promotions were getting handed out for engineers who did a hacky prototype integration with the latest & greatest NoSQL Big Data GraphQL Blockchain OSS project while solving no actual problems. I've also been other places (Amazon) where customers really are front and center, and spending time on cool engineering projects that serve no customer purpose meant absolutely nothing when you wrote up your promotion doc.

bot41 4y ago

> There are always [] half-finished fix-the-world ideas conflicting with each other, I work in a code base like this. People's suggestion? Introduce React!

Chris_Newton 4y ago

I’ve had similar experiences, but I wonder how much of this is truly inevitable because software development is complicated and requirements often change along the way, and how much is simply bad management. I’ve noticed that over time the prevailing culture in software development has drifted more and more towards “thinking small”. This has certainly been encouraged by the shift to web and mobile apps in an always-connected, always-updatable world. First it was just the code. Short functions, few parameters, shallow nesting. Make everything testable and maintainable! Then it was the commits. Release early, release often, merge WIP straight into master in your CI/CD system. We need fast feedback and short cycles to avoid unnecessary conflicts! Then it was the whole process. Break everything down, do one small thing at once, move it across that Kanban board, next sprint please. We need focus and visible progress! The danger with all of these is the same: they come from good intentions and even have an element of truth behind them, but they can also mean the big picture gets lost. There’s no coherent vision shared by everyone involved. No-one is watching all the extra dependencies that connect the many small parts. Tech debt compounds. Eventually we are forced to acknowledge that there are “challenges” but even then we somehow convince ourselves that those were inevitable, even though they weren’t really there before. Yes, of course our early-merged WIP hidden behind a feature flag in CI is completely different to the feature branch we used to use. Now we know everything builds before it can be merged, even though nothing is really testing that all the different combinations of WIP actually work together, so that’s a big improvement on before. And since obviously we have a reliable, automated process for backing out any unfinished code that doesn’t make the cut later, we’re also much better off than the old situation where we’d just have sidelined that feature branch and never merged into the next level up in the first place! In the real world, this leads to exactly the mess described in the parent comment. There’s no coherent vision for anything big that is shared by everyone involved, no considered and consistent structure for the software architecture or the APIs or the data formats. If we rely on emergent properties that evolve organically, we also run into evolutionary dead-ends, and what survives might work but also be messy. Personally, I don’t really buy the argument that this is inevitable. Five players can make a great jazz band. With 100 players, you probably want an orchestra with a conductor and sheets and the occasional featured soloist. Neither jazz nor orchestration is “better” or “worse” in absolute terms but they are certainly different.

indymike 4y ago

> Some part of your organizations chaos is going to reflect in code, This is reality, and why organizational chaos is so painful for engineers.

exclusiv 4y ago

> Some part of your organizations chaos is going to reflect in code, and honestly I'd rather it be in a big ball of frontend than in the data models, infrastructure, etc. I disagree. I like my frontend to be as dumb as possible. It gets data and reacts to it as simple as possible. Seen too many frontends with a lot of data logic and it becomes extremely brittle, harder to test. These are the ones where the frontend devs are getting data from the API and creating new structures, transforming it, conditionals everywhere, etc. It requires way more discipline to ensure that frontend devs aren't recreating the wheel and writing duplicate code as the app and components evolve, and it's worse for larger codebases of course. They need to build some new component and go - ok I got the data from the API and now I need to do the thing that's already been done by another frontend dev for another component because we've allowed the frontend to be responsible for transforming the data. But if they aren't aware of this, then you get a lot of dupe code. Just have your backend API provide the contract. Setup resources/transformers as needed on the backend instead of littering the frontend with that logic.

markeibes 4y ago
Why? What's the difference?
- BoorishBears 4y ago
  Backend doesn't need to deal with animations, styling, browser support, responsiveness, etc.
- yurishimo 4y ago
  You’re likely duplicating a lot of business logic between the frontend and backend. You can do it, but if you forgot to update one implementation, it could get ugly fast.
cercatrova 4y ago
That's why I like GraphQL, you get exactly the data you request, no transformation necessary.

mzzter 4y ago

relevant codeless code parable: http://thecodelesscode.com/case/123 http://thecodelesscode.com/case/123

draw_down 4y ago

steve_taylor 4y ago

I completely agree. And the thing with different frameworks is they let you scale to varying heights of complexity before you reach those high-level problems. For example, I find that functional components can have more complexity in terms of logic than class components before they become a complete mess. React itself allowed us to go way beyond jQuery before becoming a complete mess. I don’t think there will ever be a framework that saves us from that as long as managers keep doing what managers do.

earthboundkid 4y ago

If you read Programming As If People Mattered from 1992, the frontend mess was true then too.