5 ms·

> separation of concerns I learned it and started developing this way taking separation of concerns as dogma and now I look back and wonder why we ever did it

> separation of concerns I learned it and started developing this way taking separation of concerns as dogma and now I look back and wonder why we ever did it that way.

sodapopcan 5y ago
The thing is that this was never "separation of concerns", it was always "separation of languages". There were cross cutting concerns across each language (CSS doing layout, styling, animations; JS doing business logic, animations, layout, styling; etc). Mixing your JS/Other Language/CSS/HTML into components is a separation of concerns that really matters: separation of business/application concerns. Having everything you need that works together to solve a problem in place is very powerful (not to mention convenient).
- tomc1985 5y ago
  The separation of languages is a natural byproduct of each language being specific to its domain. HTML does layout. CSS does styling. JS does frontend functionality. Server enforces business logic, controllers, and the data model. It's clean, clear-cut, easy for IDE's to parse, and everything is in its place. Dogma or not I still prefer everything in its place vs trying to watch my IDE twist itself in knots trying to figure out which language to use for a given context. To say nothing of all the little eccentricities in the JS engines' reimplemented parsers.
  - friedman23 5y ago
    > HTML does layout. CSS does styling. JS does frontend functionality. Server enforces business logic, controllers, and the data model. In practice nothing works out like this. JS and HTML are tightly coupled, the frontend ends up needing to enforce business logic as well for usability reasons, etc. > trying to watch my IDE twist itself in knots trying to figure out which language to use for a given context This is not an actual issue.
    - tomc1985 5y ago
      > In practice nothing works out like this. It does and can. Sorry your team sucks > This is not an actual issue. Yes, it is. Why would I bring it up if it wasn't?
      - friedman23 5y ago
        >It does and can. Sorry your team sucks My team doesn't suck I work with some of the best in the business. > Why would I bring it up if it wasn't? No idea, I say it's not an issue because it's not. Millions of people work in react with typescript and have 0 issue working with html, javascript, and css in one ide. I didn't have to put in a lot of effort to configure my IDE either. So this idea that ides can't handle this workload is completely bogus and you are lying though your teeth or just ignorant.
        tomc1985 5y ago
        Your IDE. Which if I had to guess is VS Code. Which not everyone uses. And neither does everyone use typescript. And if some of the best in the business can't (or won't) keep separation of concerns, then I can't help but chuckle to myself at the mess they're creating. How many levels of metaprogramming do you have to do? Most IDEs start to falter around the third or so. I've been assigned to shit that is Ruby writing HTML containing Javascript writing even more HTML in React's bullshit not-HTML dialect. And yes my IDE chokes. And if that project's designers weren't fucking insane it wouldn't have to, but I digress because modern tooling is a fucking joke. Typescript... pah. Crutches for people who suck at JS. Besides, the "best in the business" are out there writing embedded C code or zerodays or format codecs. Not writing web apps
  - sodapopcan 5y ago
    You clearly read past my comment so I can’t really respond to to this.

> separation of concerns I learned it and started developing this way taking separation of concerns as dogma and now I look back and wonder why we ever did it that way.

sodapopcan 5y ago

The thing is that this was never "separation of concerns", it was always "separation of languages". There were cross cutting concerns across each language (CSS doing layout, styling, animations; JS doing business logic, animations, layout, styling; etc). Mixing your JS/Other Language/CSS/HTML into components is a separation of concerns that really matters: separation of business/application concerns. Having everything you need that works together to solve a problem in place is very powerful (not to mention convenient).

tomc1985 5y ago
The separation of languages is a natural byproduct of each language being specific to its domain. HTML does layout. CSS does styling. JS does frontend functionality. Server enforces business logic, controllers, and the data model. It's clean, clear-cut, easy for IDE's to parse, and everything is in its place. Dogma or not I still prefer everything in its place vs trying to watch my IDE twist itself in knots trying to figure out which language to use for a given context. To say nothing of all the little eccentricities in the JS engines' reimplemented parsers.
- friedman23 5y ago
  > HTML does layout. CSS does styling. JS does frontend functionality. Server enforces business logic, controllers, and the data model. In practice nothing works out like this. JS and HTML are tightly coupled, the frontend ends up needing to enforce business logic as well for usability reasons, etc. > trying to watch my IDE twist itself in knots trying to figure out which language to use for a given context This is not an actual issue.
  - tomc1985 5y ago
    > In practice nothing works out like this. It does and can. Sorry your team sucks > This is not an actual issue. Yes, it is. Why would I bring it up if it wasn't?
    - friedman23 5y ago
      >It does and can. Sorry your team sucks My team doesn't suck I work with some of the best in the business. > Why would I bring it up if it wasn't? No idea, I say it's not an issue because it's not. Millions of people work in react with typescript and have 0 issue working with html, javascript, and css in one ide. I didn't have to put in a lot of effort to configure my IDE either. So this idea that ides can't handle this workload is completely bogus and you are lying though your teeth or just ignorant.
      - tomc1985 5y ago
        Your IDE. Which if I had to guess is VS Code. Which not everyone uses. And neither does everyone use typescript. And if some of the best in the business can't (or won't) keep separation of concerns, then I can't help but chuckle to myself at the mess they're creating. How many levels of metaprogramming do you have to do? Most IDEs start to falter around the third or so. I've been assigned to shit that is Ruby writing HTML containing Javascript writing even more HTML in React's bullshit not-HTML dialect. And yes my IDE chokes. And if that project's designers weren't fucking insane it wouldn't have to, but I digress because modern tooling is a fucking joke. Typescript... pah. Crutches for people who suck at JS. Besides, the "best in the business" are out there writing embedded C code or zerodays or format codecs. Not writing web apps
- sodapopcan 5y ago
  You clearly read past my comment so I can’t really respond to to this.