4 ms·

As mentionned already, and as Pete Hunt famously talked about in "Rethinking Best Practices" (you can find it on youtube), you want to separate -concerns-, not

by shados 10y ago

As mentionned already, and as Pete Hunt famously talked about in "Rethinking Best Practices" (you can find it on youtube), you want to separate -concerns-, not technologies. Often there is a 1:1 between those things, but not in modern web development. So we've seen a push toward components that mix technologies, but separate concerns. And it's been great.

andybak 10y ago
This is a great explanation. People learnt that mixing behavior and presentation was bad but that was a specific case of a more general rule. In fact - "separation of concerns" is itself a specific example of an even more general rule which is something like "Make code easy to reason about" or "reduce side-effects" or similar. It's hard to give advice that doesn't sound hand-wavy and empty without getting specific. But as soon as you get specific you exclude alternative solutions to the same core problem. Programming is largely about managing complexity and there are many ways to achieve that. But learning how is a subtle art indeed.
- spion 10y ago
  We usually take all software design principles at a face value and rarely think about the reasons why we have them in the first place. The reason why we need software design principles is because software changes. Software design principles are methods of organising software that make it easier to implement changes. When it comes to changes it seems that the golden rule that makes things easier for humans is: things that vary together should be together (and things that tend to vary separately should be separate). Its interesting to think about why this is the case, but I'll skip that and take it as an axiom. There was an article (which I can't recall the URL of) that argued how all the SOLID principles stem from this basic rule. Single responsibility principle: it follows directly from the above rule: A class should have only one reason to change (keep things that could change separately separate) Open/closed principle: Interfaces should vary significantly less than their implementations, so that both producers and consumers of those interfaces can vary independently of each other. e.g. Shape can have a method draw that takes a canvas interface: now we can vary both the canvas implementation and the different shapes independently. Interface segregation principle: don't put too many things in an interface, they might vary differently. Make separate interfaces based on consumer types since change in consumers are more likely to affect changes in the interfaces they use, and having one interface for two types of consumers means two separate sources of change that vary differently. Map / filter vs for loops is simply this principle applied in the small. The code to initialize an empty data structure, iterate through all the elements applying a function and then store the resutls in the data structure is always the same. The only thing that changes is the function that defines the transformation. Since its a concept that is very common and never changes, it should be separated from the transformation itself (which changes often and depends on the problem domain) and be given a common name (map) It then follows easily that separating the component template from the code that manages component state doesn't really help. Its fine in server-side languages where the template is simply the final function in the data transformation pipeline for that request, with multiple potential views on the same data (html, json, xml etc). However, on the client side most of our code manages changing state closely tied to the DOM based view: for example, the sort column and sort direction of a table, or the current item selection, etc. The kind of state we keep is directly tied with how we present things (sortable table? => sort column and sort order; expandable tree? => expanded/contracted state for all branches, etc). As our view/component requirements change, the state we keep for it (and the way we manage it) also changes. And since things that vary together should be together...
deleted 10y ago
[deleted]
gambler 10y ago
This is just rhetoric. The notion of separation between information, presentation and behavior couldn't be any more fundamental. But instead of developing this idea any further most web developers had traditionally settled for something "easy" and complicated (i.e. JQuery that dictates all of the three things I mentioned). In the long run, the SPA craze will backfire, big time. Rect components are not semantic and not declarative. There is no way to examine them without executing code. This is an elephant in the room most fronted developers willfully ignore right now.
- edoceo 10y ago
  I like the typo: react => rect and the inevitable rekt
- andybak 10y ago
  I'm with you on 'declarative' but I'm always sceptical about 'semantic'. Its meaning is vague, its benefits somewhat ethereal and its actual existence in the real world a matter of rumour and speculation. If you can pin down your definition then I'd be able to provide a more concrete opinion. > The notion of separation between information, presentation and behavior couldn't be any more fundamental. Fundamental to whom? Outside of web development this separation was never fundamental - see the post above regarding "separation of concerns" - which is a much better candidate for a "fundamental principle"
ssijak 10y ago
Why not separate concerns AND technologies at the same time. Concerns for the logical organisation of the code and technologies for easier editing of the same code.

by shados 10y ago

andybak 10y ago

This is a great explanation. People learnt that mixing behavior and presentation was bad but that was a specific case of a more general rule. In fact - "separation of concerns" is itself a specific example of an even more general rule which is something like "Make code easy to reason about" or "reduce side-effects" or similar. It's hard to give advice that doesn't sound hand-wavy and empty without getting specific. But as soon as you get specific you exclude alternative solutions to the same core problem. Programming is largely about managing complexity and there are many ways to achieve that. But learning how is a subtle art indeed.

spion 10y ago
We usually take all software design principles at a face value and rarely think about the reasons why we have them in the first place. The reason why we need software design principles is because software changes. Software design principles are methods of organising software that make it easier to implement changes. When it comes to changes it seems that the golden rule that makes things easier for humans is: things that vary together should be together (and things that tend to vary separately should be separate). Its interesting to think about why this is the case, but I'll skip that and take it as an axiom. There was an article (which I can't recall the URL of) that argued how all the SOLID principles stem from this basic rule. Single responsibility principle: it follows directly from the above rule: A class should have only one reason to change (keep things that could change separately separate) Open/closed principle: Interfaces should vary significantly less than their implementations, so that both producers and consumers of those interfaces can vary independently of each other. e.g. Shape can have a method draw that takes a canvas interface: now we can vary both the canvas implementation and the different shapes independently. Interface segregation principle: don't put too many things in an interface, they might vary differently. Make separate interfaces based on consumer types since change in consumers are more likely to affect changes in the interfaces they use, and having one interface for two types of consumers means two separate sources of change that vary differently. Map / filter vs for loops is simply this principle applied in the small. The code to initialize an empty data structure, iterate through all the elements applying a function and then store the resutls in the data structure is always the same. The only thing that changes is the function that defines the transformation. Since its a concept that is very common and never changes, it should be separated from the transformation itself (which changes often and depends on the problem domain) and be given a common name (map) It then follows easily that separating the component template from the code that manages component state doesn't really help. Its fine in server-side languages where the template is simply the final function in the data transformation pipeline for that request, with multiple potential views on the same data (html, json, xml etc). However, on the client side most of our code manages changing state closely tied to the DOM based view: for example, the sort column and sort direction of a table, or the current item selection, etc. The kind of state we keep is directly tied with how we present things (sortable table? => sort column and sort order; expandable tree? => expanded/contracted state for all branches, etc). As our view/component requirements change, the state we keep for it (and the way we manage it) also changes. And since things that vary together should be together...

deleted 10y ago

[deleted]

gambler 10y ago

This is just rhetoric. The notion of separation between information, presentation and behavior couldn't be any more fundamental. But instead of developing this idea any further most web developers had traditionally settled for something "easy" and complicated (i.e. JQuery that dictates all of the three things I mentioned). In the long run, the SPA craze will backfire, big time. Rect components are not semantic and not declarative. There is no way to examine them without executing code. This is an elephant in the room most fronted developers willfully ignore right now.

edoceo 10y ago
I like the typo: react => rect and the inevitable rekt
andybak 10y ago
I'm with you on 'declarative' but I'm always sceptical about 'semantic'. Its meaning is vague, its benefits somewhat ethereal and its actual existence in the real world a matter of rumour and speculation. If you can pin down your definition then I'd be able to provide a more concrete opinion. > The notion of separation between information, presentation and behavior couldn't be any more fundamental. Fundamental to whom? Outside of web development this separation was never fundamental - see the post above regarding "separation of concerns" - which is a much better candidate for a "fundamental principle"

ssijak 10y ago

Why not separate concerns AND technologies at the same time. Concerns for the logical organisation of the code and technologies for easier editing of the same code.