8 ms·

It's artificially inflated and I'm seeing this in almost all areas, not just frontend. Some of the projects I've seen could have been reduced in size multiple

by mojuba 4y ago

It's artificially inflated and I'm seeing this in almost all areas, not just frontend. Some of the projects I've seen could have been reduced in size multiple times with no effect on the outcome whatsoever. In one instance I rewrote a GUI app and made it 15 times smaller (!), that's my absolute record to date. Been wondering for years, so you need to actually be inventive to add unnecessary complexity, it's not that it comes for free or because of incompetence (though that too of course). And a lot of the times it looks almost as if software engineers do it on purpose, sometimes very creatively at that. Where is this coming from? Is it because we want our work to look important?

andix 4y ago
One of the best examples of this complexity inflation problem I always see is the Redux pattern in frontends. This pattern comes with a lot of overhead, a lot of things that need to line up (Actions, Reducers, Actioncreators, Selectors, ...). And most of the time the applications that use it are completely trivial. If you remove Redux, half of the code is gone, it's faster and easier to understand and extend.
- davedx 4y ago
  To be fair most front-end projects have abandoned redux now. It was for sure boilerplate hell.
  - andix 4y ago
    Tell that to European corporations. Angular + NgRx/NGXS is the de-facto gold standard there.
    - dmix 4y ago
      What were they using before?
    - wildrhythms 4y ago
      I think Observables are much simpler to grok than some hundreds-line multi-file combined reducer/actions amalgamation.
      - andix 4y ago
        I think React hooks are so much easier to write than observables. It provides similar functionality to observables, but without the added complexity.
  - arcturus17 4y ago
    I've been doing some research recently and it continues to be by far the most popular state management framework for React. The fact that there are alternatives doesn't mean that most projects have abandoned it.
    - soft_dev_person 4y ago
      Do these metrics count "no framework" as an option? With hooks, context and separation of concerns, most apps can live very well without any "state management framework" at all.
    - meindnoch 4y ago
      Has it occurred to you that maybe “state management” is not something you need a framework for?
      - Jasp3r 4y ago
        Tell me you're not making complex webapps without telling you're not making complex webapps
        idlewan 4y ago
        The publish-subscribe/observer/mediator pattern is perfectly fine for state management, and doesn't need a framework. At most, a small-ish library, but you can also re-implement it yourself quite easily. Reading your comment, I have the impression you took it as "there shouldn't be any state management necessary", instead of "state management doesn't need a framework" sense.
        ketzo 4y ago
        "State management is complex, so we used a framework to make things easier." "Why use a widely popular, well-documented, battle-tested framework? Just have one of your senior devs build something over the weekend. This will definitely reduce complexity." Like... I get what you're saying. But "build your own" is not a default answer for an extremely complicated software engineering topic (which, yes, state management is!)
  - acemarke 4y ago
    Redux is still by _far_ the most widely used state management library in React apps. By my estimates, around 35-40% of all React apps use Redux, and that's far more than any other state library in the ecosystem: - https://blog.isquaredsoftware.com/2022/07/npm-package-market-share-estimates/ https://blog.isquaredsoftware.com/2022/07/npm-package-market...
    - player2121 4y ago
      True but not for new projects. Legacy software has quite a long life span.
  - spaceman_2020 4y ago
    What are people using now? Good old context?
    - dsego 4y ago
      Things like react-query for syncing with server state (which can be most state in web apps) are getting popular, or smaller hook-oriented stores, like zustand, jotai or recoil for true client-side state.
      - spaceman_2020 4y ago
        Second time today that someone has mentioned React-query to me. Sign that I need to look that up finally
  - hbrn 4y ago
    What's interesting is why was it so widely accepted in the first place. It's not like boilerplate reveals itself at later stages, it's right there from the beginning. I think it tells a lot about the state of the industry.
- ilrwbwrkhv 4y ago
  All this complexity is actually a counter reaction to frontend developers not being considered to be real developers. They went overboard trying to prove that they are.
  - andix 4y ago
    I think there is some truth in that thought. If they spend some of their energy into learning a backend technology, this would be much better spent effort. From my experience frontend-only developers are often very limited in their programming skills. Frontend development has its own complicated challenges, but usually the programming part is quite trivial compared to backend. And a lot of logic inside frontends would be better off in the backend (Full Stack developer speaking here).
  - booleandilemma 4y ago
    See: microfrontends
  - wellanyway 4y ago
    Savage, but a very interesting take.
- mojuba 4y ago
  Same for MVC/MVVM and Co specifically on mobile. These things were created to teach beginners a few important concepts, mainly separation of concerns. MVC/MVVM work well on toy sample projects with 2-3 pages but can ruin a larger project. Somehow wherever I'm seeing MVVM applied there's also messy, buggy, impenetrable code around it. I don't think it's a coincidence.
  - mpweiher 4y ago
    MVVM: yes, in most cases. There are some cases where it's a godsend, but most of the uses I have seen are ... not entirely sane. But MVC? That's pretty minimal in terms of what you're going to do anyway if you have functionality (model) and will be interacting with it (view). Controllers are often misunderstood, and in the case of Apple massively misapplied (Massive View Controllers).
    - marcosdumay 4y ago
      It doesn't help that there are dozens of different definitions of MVC running around. The very clearly uses one that is different from yours. The thing is that, whatever definition you use, you should have almost all of your code in one of those layers, a small minority on another, and shouldn't even remember exactly how to change the other (unless you start many projects). If that's not the case, your code architecture is working against you.
    - jim180 4y ago
      Agreed on that controllers are often misunderstood. I saw them to become both: a view and a model at the same time. :(
      - mpweiher 4y ago
        What's important to realise is that the elements in MVC are roles not entities. So for example Views in Cocoa actually fulfil both the View and (largely) the Controller role. Which is why ViewControllers confused me greatly when they came out. Like they confuse most of the Apple-ecosystem code out there these days. While I do understand how they got there, that doesn't make it better...
- acemarke 4y ago
  Hi, I'm a Redux maintainer. I'll definitely agree that Redux _has_ been overused. But it's also worth understanding _why_ Redux was created in the first place and why it got so popular. As a brief recap: the first major wave of JS MVC frameworks had major flaws. Angular's dirty checking didn't scale and was impossible to debug. Backbone's event-based system led to events ricocheting around the app with no way to trace what would happen when a given value changed. Additionally, manual DOM manipulation made it hard to manage ongoing changes to the UI over time. This led to Facebook designing React to let devs write encapsulated components with predictable output and behavior, but React didn't have a solution for larger global state. Facebook later announced a "Flux Architecture" concept that tried to make larger app state updates predictable through centralization. The React community ran with this idea and produced dozens of Flux-inspired libraries. Redux took the ideas from several of those Flux libraries, and applied Functional Programming principles, with the goal of making it easier to understand when, where, why, and how your state is being updated and changing over time. The community then adopted Redux because A) it was the best of all the Flux implementations, B) it _did_ address the issues people were running into around state management, C) it was designed to work well with React, and D) it also incidentally helped work around limitations in React's original Context API. (I've talked about the original intent and purpose extensively in my blog posts and conference talks [0] [1].) After that, yes, Redux _did_ get shoved into many applications that didn't need it, in the same way that React has been used for many sites that didn't necessarily require that setup. So, we've always recommended that people actually take the time to evaluate the specific problems they need to solve in their app, and make an informed decision on whether Redux is an appropriate solution for those problems [2]. Beyond that, we've specifically designed and built our official Redux Toolkit package [3] [4] to eliminate the old "boilerplate" concerns. "Modern Redux" with Redux Toolkit and React-Redux hooks is _much_ easier to learn and use than the original Redux patterns, and we get highly positive feedback on a daily basis from folks who enjoy using RTK. We also built an "RTK Query" data fetching and caching API [5], as data fetching is the most common thing that apps need to do today. [0] https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-1/ https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta... [1] https://blog.isquaredsoftware.com/series/presentations https://blog.isquaredsoftware.com/series/presentations [2] https://redux.js.org/tutorials/essentials/part-1-overview-concepts#when-should-i-use-redux https://redux.js.org/tutorials/essentials/part-1-overview-co... [3] https://redux.js.org/introduction/why-rtk-is-redux-today https://redux.js.org/introduction/why-rtk-is-redux-today [4] https://blog.isquaredsoftware.com/2022/06/presentations-modern-redux-rtk/ https://blog.isquaredsoftware.com/2022/06/presentations-mode... [5] https://redux-toolkit.js.org/rtk-query/overview https://redux-toolkit.js.org/rtk-query/overview
- JoeyJoJoJr 4y ago
  The problem has always been immutable state. JavaScript doesn’t have ergonomic constructs to handle immutable state very well. IMO, immutability shouldn’t even be enforced by the view rendering layer. Immutability in React is enforced to cater to the needs of React’s implementation, and not the needs of the developer. It should be a choice by the developer whether or not they store their state in immutable data structures. Hooks are marketed as a means to make React into more of a framework, but the reality is that they are an attempt to smooth over the problems surrounding immutable state. Solid js also doesn’t solve this problem, even if it has more ergonomic ways of dealing with the problem. Digging deeper, it seems to me that attempting to subvert the standard behaviour of the DOM will always produce a leaky abstraction, and it negates the benefits of working on a standardised platform.
wellanyway 4y ago
This. While engaging in flame wars about React I have noticed that all of them start with a peculiar definition of done that, lo and behold, necessitates not only React but whatever feature if the month they are busy ductaping to it. What we need is an honest conversation about what USERS think about spa apps, flat design, etc while holding very obviously interested parties from skewing the narratiwe.
- chiefalchemist 4y ago
  This. No user wakes up and says, "I gots to find me a UI built with React* today, or I'm going to cry." Ever. Users. Don't. Care. We keep adding tech and tools and experiences - if you asked users - aren't improving all that much. * Or whatever technolgy being championed.
  - ketzo 4y ago
    I dunno. Lots of users seem to wake up and say “Gimme a UI with rich interactions, super low latency, offline support, and real-time sync.” Even for B2B “back-of-office” software, the standards for software usability are really high, especially for new entrants. Those kinda features are hard without a pretty complex frontend. Not saying those things are always necessary, or that people don’t add bells and whistles where they aren’t wanted.
    - myth2018 4y ago
      > I dunno. Lots of users seem to wake up and say “Gimme a UI with rich interactions, super low latency, offline support, and real-time sync I'm inclined to disagree. One of the most successful web apps I know is a CGI (not FastCGI) app written in Pascal and containing some 30-yo code. 100% of users I met are happy but they don't even know why. "It's good", they say. I believe their underlying reasons are: - the app is extremely fast. Full screen reloads are not a matter anymore with broadband internet. - client side code is light enough to run well in crappy, old windows-based PCs running internet explorer - lots of reports and features. The vendor's team has time to develop them since they are not busy trying to centralize stuff, fighting w/ CSS properties and other stupidities.
MilStdJunkie 4y ago
It's all over techcomms too: GML / Scribe aaalllllll the way to DocBook, then DITA and S1000D. And people run to adopt those thick specs, in spite of there being zero supporting data that they in any way reduce cost . . or do anything useful[1] at all. Watch that adjective "useful". I see it as Scientist/Technician vs Prophet/Priest. These two pairs are solutions to a problem: the world isn't doing what I say. They can both work, or at least do better than random. The difference is that the former can explain why, and the latter can't. The cool thing about not explaining? It makes the Prophet the only person who can evaluate the work. They have vision into the solution, and it appears only to them. The bad thing about Prophets? If you've quantified the solution, then it can be falsified and replicated. Wait a second . . how hard can it be to quantify a solution? It's actually really hard - particularly in things like natural language (tech comms) and visual arts (yes, front end is viz art, FIGHT ME :D). Some industries have blown up their prophets to such towering heights that they will set fire to clients and money and any other quantitative measure of value . . all in search of that One Truth (content re-use and so-called "single sourcing", I am looking at you, but I'm not even going to tease the elephant in the room that is AS9100) People in insecure positions will always seek to turn their Technician position into a Priest position, even if they need to find some Prophet to cling to. And eventually, they might get a chance to be a Prophet too. It's like an MLM for your mind. [1] "Structured content is the future!" Oh, is it now? How's that been working out for you last checks watch twenty years? "Hierarchical organizations are required for finding stuff!" Do you know, I think I remember the Internet Outline google publishes ever second /s. Ah, "useful".
fckgnad 4y ago
It's very easy to see why this happens. Because nobody actually knows what they're doing. There is no logical/mathematical theory around program design. We have no idea if we're improving in optimization, staying the same or even going backwards. For the shortest distance between two points, we have a theory that defines the best distance: A line. That's an easy target to hit. For the best way to design and organize our programs... there is no theory. It's all made up and opinionated. Without a theory we can never truly know. Thus we are doomed to forever move in a flat circle creating framework after framework and endlessly having progress move horizontally while wasting effort creating isomorphic patterns without ever knowing if the new pattern is better or worse. Until the day we have a mathematical theory around program organization that can say Design A is 2.3 times more optimal then Design B. Then on that day... this madness will stop. But until that day we're all stuck in an endless limbo mouse wheel mind fuck. I look at front end and I suspect that out of all software technologies, front end is one of the few fields that is actually moving backwards. I'd estimate 0.01x less optimal every year then I predict at a delta of 0.5x less optimal from an inflection point it starts to oscillate back towards the natural equilibrium again. Then when it hits equilibrium it will oscillate in the opposite direction again. Endless. Python is likely one of the most stable technologies imo. It's definitely not remotely close to the MOST optimal state but it's nested too comfortably in a local optima and it will likely be stuck there forever.
nokya 4y ago
"Where is this coming from? Is it because we want our work to look important?" I am intimately convinced it could play a role, at two layers. First, at the framework layer itself: the plethora of propositions seems symptomatic of our approach to dealing with things we don't like. When confronted to the choice of walking the extra mile to improve and contribute to an existing language/framework, or building your own new thing that focuses on solving your own problem, my guess is that the more senior architects (esp. those working at licorns or GAFAMs) will choose the latter option, thus resulting in an increased offer. Also, let's not forget, being the author of a successful language or framework sounds cool. Second, at the user layer (architect at random corp): this individual is increasingly convinced that working with the latest silicon valley approved framework will work wonders on her/his resume. I am confronted to new software architectures on a weekly basis as a result of my job and the choices of framework/language X as opposed to Y often follows a common pattern: some architect thinks that segmenting a system into as many components/technologies as possible somehow always makes it more reliable at the end. If I owned a software company, I'd immediately get rid of anyone showing these behaviors. But I have to admit: the bigger the mess, the more hours I can bill :)
- EMM_386 4y ago
  > some architect thinks that segmenting a system into as many components/technologies as possible somehow always makes it more reliable at the end. If I owned a software company, I'd immediately get rid of anyone showing these behaviors. But I have to admit: the bigger the mess, the more hours I can bill :) I recently greenlit a project that uses the latest Angular, C# REST APIs and a SQL server. It's clean, it works, it's performant, it's logical and it's maintainable. And as long as I'm still here, it's staying that way :)
  - lukeramsden 4y ago
    (note: I agree with your approach, just making a point) > that uses the latest Angular But what's the migration plan for the next time Angular goes through a massive ecosystem migration and suddenly you're staring down the barrel of being massively out of date, or investing anywhere from days to months of work running just to stay in place? This is what actually seems to be the problem to me, not just in frontend either: very little is stable, and you end up piling hacks upon hacks just to try and stay up to date. People also pick new tech after being burned by previous tech doing these massive ecosystem-wide migrations and seeing how painful it is. I wish I knew the solution :)

by mojuba 4y ago

andix 4y ago

One of the best examples of this complexity inflation problem I always see is the Redux pattern in frontends. This pattern comes with a lot of overhead, a lot of things that need to line up (Actions, Reducers, Actioncreators, Selectors, ...). And most of the time the applications that use it are completely trivial. If you remove Redux, half of the code is gone, it's faster and easier to understand and extend.

davedx 4y ago
To be fair most front-end projects have abandoned redux now. It was for sure boilerplate hell.
- andix 4y ago
  Tell that to European corporations. Angular + NgRx/NGXS is the de-facto gold standard there.
  - dmix 4y ago
    What were they using before?
  - wildrhythms 4y ago
    I think Observables are much simpler to grok than some hundreds-line multi-file combined reducer/actions amalgamation.
    - andix 4y ago
      I think React hooks are so much easier to write than observables. It provides similar functionality to observables, but without the added complexity.
- arcturus17 4y ago
  I've been doing some research recently and it continues to be by far the most popular state management framework for React. The fact that there are alternatives doesn't mean that most projects have abandoned it.
  - soft_dev_person 4y ago
    Do these metrics count "no framework" as an option? With hooks, context and separation of concerns, most apps can live very well without any "state management framework" at all.
  - meindnoch 4y ago
    Has it occurred to you that maybe “state management” is not something you need a framework for?
    - Jasp3r 4y ago
      Tell me you're not making complex webapps without telling you're not making complex webapps
      - idlewan 4y ago
        The publish-subscribe/observer/mediator pattern is perfectly fine for state management, and doesn't need a framework. At most, a small-ish library, but you can also re-implement it yourself quite easily. Reading your comment, I have the impression you took it as "there shouldn't be any state management necessary", instead of "state management doesn't need a framework" sense.
        ketzo 4y ago
        "State management is complex, so we used a framework to make things easier." "Why use a widely popular, well-documented, battle-tested framework? Just have one of your senior devs build something over the weekend. This will definitely reduce complexity." Like... I get what you're saying. But "build your own" is not a default answer for an extremely complicated software engineering topic (which, yes, state management is!)
- acemarke 4y ago
  Redux is still by _far_ the most widely used state management library in React apps. By my estimates, around 35-40% of all React apps use Redux, and that's far more than any other state library in the ecosystem: - https://blog.isquaredsoftware.com/2022/07/npm-package-market-share-estimates/ https://blog.isquaredsoftware.com/2022/07/npm-package-market...
  - player2121 4y ago
    True but not for new projects. Legacy software has quite a long life span.
- spaceman_2020 4y ago
  What are people using now? Good old context?
  - dsego 4y ago
    Things like react-query for syncing with server state (which can be most state in web apps) are getting popular, or smaller hook-oriented stores, like zustand, jotai or recoil for true client-side state.
    - spaceman_2020 4y ago
      Second time today that someone has mentioned React-query to me. Sign that I need to look that up finally
- hbrn 4y ago
  What's interesting is why was it so widely accepted in the first place. It's not like boilerplate reveals itself at later stages, it's right there from the beginning. I think it tells a lot about the state of the industry.
ilrwbwrkhv 4y ago
All this complexity is actually a counter reaction to frontend developers not being considered to be real developers. They went overboard trying to prove that they are.
- andix 4y ago
  I think there is some truth in that thought. If they spend some of their energy into learning a backend technology, this would be much better spent effort. From my experience frontend-only developers are often very limited in their programming skills. Frontend development has its own complicated challenges, but usually the programming part is quite trivial compared to backend. And a lot of logic inside frontends would be better off in the backend (Full Stack developer speaking here).
- booleandilemma 4y ago
  See: microfrontends
- wellanyway 4y ago
  Savage, but a very interesting take.
mojuba 4y ago
Same for MVC/MVVM and Co specifically on mobile. These things were created to teach beginners a few important concepts, mainly separation of concerns. MVC/MVVM work well on toy sample projects with 2-3 pages but can ruin a larger project. Somehow wherever I'm seeing MVVM applied there's also messy, buggy, impenetrable code around it. I don't think it's a coincidence.
- mpweiher 4y ago
  MVVM: yes, in most cases. There are some cases where it's a godsend, but most of the uses I have seen are ... not entirely sane. But MVC? That's pretty minimal in terms of what you're going to do anyway if you have functionality (model) and will be interacting with it (view). Controllers are often misunderstood, and in the case of Apple massively misapplied (Massive View Controllers).
  - marcosdumay 4y ago
    It doesn't help that there are dozens of different definitions of MVC running around. The very clearly uses one that is different from yours. The thing is that, whatever definition you use, you should have almost all of your code in one of those layers, a small minority on another, and shouldn't even remember exactly how to change the other (unless you start many projects). If that's not the case, your code architecture is working against you.
  - jim180 4y ago
    Agreed on that controllers are often misunderstood. I saw them to become both: a view and a model at the same time. :(
    - mpweiher 4y ago
      What's important to realise is that the elements in MVC are roles not entities. So for example Views in Cocoa actually fulfil both the View and (largely) the Controller role. Which is why ViewControllers confused me greatly when they came out. Like they confuse most of the Apple-ecosystem code out there these days. While I do understand how they got there, that doesn't make it better...
acemarke 4y ago
Hi, I'm a Redux maintainer. I'll definitely agree that Redux _has_ been overused. But it's also worth understanding _why_ Redux was created in the first place and why it got so popular. As a brief recap: the first major wave of JS MVC frameworks had major flaws. Angular's dirty checking didn't scale and was impossible to debug. Backbone's event-based system led to events ricocheting around the app with no way to trace what would happen when a given value changed. Additionally, manual DOM manipulation made it hard to manage ongoing changes to the UI over time. This led to Facebook designing React to let devs write encapsulated components with predictable output and behavior, but React didn't have a solution for larger global state. Facebook later announced a "Flux Architecture" concept that tried to make larger app state updates predictable through centralization. The React community ran with this idea and produced dozens of Flux-inspired libraries. Redux took the ideas from several of those Flux libraries, and applied Functional Programming principles, with the goal of making it easier to understand when, where, why, and how your state is being updated and changing over time. The community then adopted Redux because A) it was the best of all the Flux implementations, B) it _did_ address the issues people were running into around state management, C) it was designed to work well with React, and D) it also incidentally helped work around limitations in React's original Context API. (I've talked about the original intent and purpose extensively in my blog posts and conference talks [0] [1].) After that, yes, Redux _did_ get shoved into many applications that didn't need it, in the same way that React has been used for many sites that didn't necessarily require that setup. So, we've always recommended that people actually take the time to evaluate the specific problems they need to solve in their app, and make an informed decision on whether Redux is an appropriate solution for those problems [2]. Beyond that, we've specifically designed and built our official Redux Toolkit package [3] [4] to eliminate the old "boilerplate" concerns. "Modern Redux" with Redux Toolkit and React-Redux hooks is _much_ easier to learn and use than the original Redux patterns, and we get highly positive feedback on a daily basis from folks who enjoy using RTK. We also built an "RTK Query" data fetching and caching API [5], as data fetching is the most common thing that apps need to do today. [0] https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-1/ https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta... [1] https://blog.isquaredsoftware.com/series/presentations https://blog.isquaredsoftware.com/series/presentations [2] https://redux.js.org/tutorials/essentials/part-1-overview-concepts#when-should-i-use-redux https://redux.js.org/tutorials/essentials/part-1-overview-co... [3] https://redux.js.org/introduction/why-rtk-is-redux-today https://redux.js.org/introduction/why-rtk-is-redux-today [4] https://blog.isquaredsoftware.com/2022/06/presentations-modern-redux-rtk/ https://blog.isquaredsoftware.com/2022/06/presentations-mode... [5] https://redux-toolkit.js.org/rtk-query/overview https://redux-toolkit.js.org/rtk-query/overview
JoeyJoJoJr 4y ago
The problem has always been immutable state. JavaScript doesn’t have ergonomic constructs to handle immutable state very well. IMO, immutability shouldn’t even be enforced by the view rendering layer. Immutability in React is enforced to cater to the needs of React’s implementation, and not the needs of the developer. It should be a choice by the developer whether or not they store their state in immutable data structures. Hooks are marketed as a means to make React into more of a framework, but the reality is that they are an attempt to smooth over the problems surrounding immutable state. Solid js also doesn’t solve this problem, even if it has more ergonomic ways of dealing with the problem. Digging deeper, it seems to me that attempting to subvert the standard behaviour of the DOM will always produce a leaky abstraction, and it negates the benefits of working on a standardised platform.

wellanyway 4y ago

This. While engaging in flame wars about React I have noticed that all of them start with a peculiar definition of done that, lo and behold, necessitates not only React but whatever feature if the month they are busy ductaping to it. What we need is an honest conversation about what USERS think about spa apps, flat design, etc while holding very obviously interested parties from skewing the narratiwe.

chiefalchemist 4y ago
This. No user wakes up and says, "I gots to find me a UI built with React* today, or I'm going to cry." Ever. Users. Don't. Care. We keep adding tech and tools and experiences - if you asked users - aren't improving all that much. * Or whatever technolgy being championed.
- ketzo 4y ago
  I dunno. Lots of users seem to wake up and say “Gimme a UI with rich interactions, super low latency, offline support, and real-time sync.” Even for B2B “back-of-office” software, the standards for software usability are really high, especially for new entrants. Those kinda features are hard without a pretty complex frontend. Not saying those things are always necessary, or that people don’t add bells and whistles where they aren’t wanted.
  - myth2018 4y ago
    > I dunno. Lots of users seem to wake up and say “Gimme a UI with rich interactions, super low latency, offline support, and real-time sync I'm inclined to disagree. One of the most successful web apps I know is a CGI (not FastCGI) app written in Pascal and containing some 30-yo code. 100% of users I met are happy but they don't even know why. "It's good", they say. I believe their underlying reasons are: - the app is extremely fast. Full screen reloads are not a matter anymore with broadband internet. - client side code is light enough to run well in crappy, old windows-based PCs running internet explorer - lots of reports and features. The vendor's team has time to develop them since they are not busy trying to centralize stuff, fighting w/ CSS properties and other stupidities.

MilStdJunkie 4y ago

It's all over techcomms too: GML / Scribe aaalllllll the way to DocBook, then DITA and S1000D. And people run to adopt those thick specs, in spite of there being zero supporting data that they in any way reduce cost . . or do anything useful[1] at all. Watch that adjective "useful". I see it as Scientist/Technician vs Prophet/Priest. These two pairs are solutions to a problem: the world isn't doing what I say. They can both work, or at least do better than random. The difference is that the former can explain why, and the latter can't. The cool thing about not explaining? It makes the Prophet the only person who can evaluate the work. They have vision into the solution, and it appears only to them. The bad thing about Prophets? If you've quantified the solution, then it can be falsified and replicated. Wait a second . . how hard can it be to quantify a solution? It's actually really hard - particularly in things like natural language (tech comms) and visual arts (yes, front end is viz art, FIGHT ME :D). Some industries have blown up their prophets to such towering heights that they will set fire to clients and money and any other quantitative measure of value . . all in search of that One Truth (content re-use and so-called "single sourcing", I am looking at you, but I'm not even going to tease the elephant in the room that is AS9100) People in insecure positions will always seek to turn their Technician position into a Priest position, even if they need to find some Prophet to cling to. And eventually, they might get a chance to be a Prophet too. It's like an MLM for your mind. [1] "Structured content is the future!" Oh, is it now? How's that been working out for you last checks watch twenty years? "Hierarchical organizations are required for finding stuff!" Do you know, I think I remember the Internet Outline google publishes ever second /s. Ah, "useful".

fckgnad 4y ago

It's very easy to see why this happens. Because nobody actually knows what they're doing. There is no logical/mathematical theory around program design. We have no idea if we're improving in optimization, staying the same or even going backwards. For the shortest distance between two points, we have a theory that defines the best distance: A line. That's an easy target to hit. For the best way to design and organize our programs... there is no theory. It's all made up and opinionated. Without a theory we can never truly know. Thus we are doomed to forever move in a flat circle creating framework after framework and endlessly having progress move horizontally while wasting effort creating isomorphic patterns without ever knowing if the new pattern is better or worse. Until the day we have a mathematical theory around program organization that can say Design A is 2.3 times more optimal then Design B. Then on that day... this madness will stop. But until that day we're all stuck in an endless limbo mouse wheel mind fuck. I look at front end and I suspect that out of all software technologies, front end is one of the few fields that is actually moving backwards. I'd estimate 0.01x less optimal every year then I predict at a delta of 0.5x less optimal from an inflection point it starts to oscillate back towards the natural equilibrium again. Then when it hits equilibrium it will oscillate in the opposite direction again. Endless. Python is likely one of the most stable technologies imo. It's definitely not remotely close to the MOST optimal state but it's nested too comfortably in a local optima and it will likely be stuck there forever.

nokya 4y ago

"Where is this coming from? Is it because we want our work to look important?" I am intimately convinced it could play a role, at two layers. First, at the framework layer itself: the plethora of propositions seems symptomatic of our approach to dealing with things we don't like. When confronted to the choice of walking the extra mile to improve and contribute to an existing language/framework, or building your own new thing that focuses on solving your own problem, my guess is that the more senior architects (esp. those working at licorns or GAFAMs) will choose the latter option, thus resulting in an increased offer. Also, let's not forget, being the author of a successful language or framework sounds cool. Second, at the user layer (architect at random corp): this individual is increasingly convinced that working with the latest silicon valley approved framework will work wonders on her/his resume. I am confronted to new software architectures on a weekly basis as a result of my job and the choices of framework/language X as opposed to Y often follows a common pattern: some architect thinks that segmenting a system into as many components/technologies as possible somehow always makes it more reliable at the end. If I owned a software company, I'd immediately get rid of anyone showing these behaviors. But I have to admit: the bigger the mess, the more hours I can bill :)

EMM_386 4y ago
> some architect thinks that segmenting a system into as many components/technologies as possible somehow always makes it more reliable at the end. If I owned a software company, I'd immediately get rid of anyone showing these behaviors. But I have to admit: the bigger the mess, the more hours I can bill :) I recently greenlit a project that uses the latest Angular, C# REST APIs and a SQL server. It's clean, it works, it's performant, it's logical and it's maintainable. And as long as I'm still here, it's staying that way :)
- lukeramsden 4y ago
  (note: I agree with your approach, just making a point) > that uses the latest Angular But what's the migration plan for the next time Angular goes through a massive ecosystem migration and suddenly you're staring down the barrel of being massively out of date, or investing anywhere from days to months of work running just to stay in place? This is what actually seems to be the problem to me, not just in frontend either: very little is stable, and you end up piling hacks upon hacks just to try and stay up to date. People also pick new tech after being burned by previous tech doing these massive ecosystem-wide migrations and seeing how painful it is. I wish I knew the solution :)