9 ms·

Why would you want to bundle styles with your components? There is already a nice separation there, maybe you could give an example use case?

by ds_ 13y ago

catshirt 13y ago
maybe it's nice, but it's nice in the same way we've been separating HTML and JS for years, which React completely disregards. if styles were solved in a similar way i think you'd be able to get rid of the notion of a selector all together (though it would compile down to normal selector based css). also, components would just be easier to grok and more portable.
- ds_ 13y ago
  I can't see the parallels between js/html and css/html. React disregards the js/html because they acknowledge that there never really was proper separation. With css/html, at least to me, it seems like there is a clearer separation. Maybe I'm being shortsighted.
  - catshirt 13y ago
    not short sighted at all. i haven't completely convinced myself yet either. :) i guess the question i struggle with then is, what is so nice about that separation? and, could those problems not also be solved in JS?
    - cnp 13y ago
      Exactly.
- CognitiveLens 13y ago
  Until recently I would disagree that we should find a way to integrate styling into the application code, but I think you make a good point, that styling can be seen as one property of an application component, something that should be coherent with its structure+behavior. As long as the styling code could remain simple to update independently of the business logic, it would be great to have it all part of the same internally-consistent dev system.
  - X4 13y ago
    I see a recurring pattern in here! We all started seeing mixing markup, style and logic before 2000. Pre 2000 was ruled by functional programming and the decade before was ruled by procedual programming. Then we rapidly started to "encapsulate", when OOP boomed. Now "packaging" is the main problem every programming language and OS has to solve. Today we end up implementing lightweight packages, so called components and we think it's a new idea to use statemachines to keep the interdependent component's state coherent. This idea was influenced by the boom of Interpred programming languages. Although 40 years ago, there were programs that only focused on allowing "components", which were "pluggable" modules back then, to be controlled by the DataFlow Pattern [1]. To formalize the main problem of the HTML,CSS and Javascript abstractions, blended into the DOM, we have to recognize that Data (Input) and UI (Output) are bound to States (Data Flows [2]). A solution to these problem is to use the FBP paradigm [3] in the browser engine and to implement the UI as an array of graphs. Usage of vectors allow the use of highly advanced mathematical solutions to be used to apply a optimization much easier than it is possible today, without rewriting the browser engine. For instance creating a UI now just means dragging and dropping items into a pane, which creates a matrix of number sequences that have relations to each other, yes basically a graph. Because the UI and State is deterministic (except for Networks protocols!?), we can use the Knaster–Tarski theorem [4] to solve such DataFlow problems. Using Topological Data Analysis (TDA), we can even get deep level insight into UI & usage patterns that evolve and recur. "Control of the language we use can be used to restrict our thinking. I find that this pattern is proving George Orwell's Newspeak [6] is similar to programming languages today. What do I know, so please correct me when you think that there is no such pattern, or when you think something is wrong in what I said. So that others will profit from it. -- [1] http://en.wikipedia.org/wiki/Dataflow_programming http://en.wikipedia.org/wiki/Dataflow_programming [2] http://en.wikipedia.org/wiki/Dataflow http://en.wikipedia.org/wiki/Dataflow [3] http://en.wikipedia.org/wiki/Flow-based_programming http://en.wikipedia.org/wiki/Flow-based_programming [4] http://en.wikipedia.org/wiki/Knaster%E2%80%93Tarski_theorem http://en.wikipedia.org/wiki/Knaster%E2%80%93Tarski_theorem [5] http://en.wikipedia.org/wiki/List_of_programming_languages_by_type http://en.wikipedia.org/wiki/List_of_programming_languages_b... [6] http://en.wikipedia.org/wiki/Newspeak http://en.wikipedia.org/wiki/Newspeak
    - 13y ago

Why would you want to bundle styles with your components? There is already a nice separation there, maybe you could give an example use case?

by ds_ 13y ago

Why would you want to bundle styles with your components? There is already a nice separation there, maybe you could give an example use case?

catshirt 13y ago

maybe it's nice, but it's nice in the same way we've been separating HTML and JS for years, which React completely disregards. if styles were solved in a similar way i think you'd be able to get rid of the notion of a selector all together (though it would compile down to normal selector based css). also, components would just be easier to grok and more portable.

ds_ 13y ago
I can't see the parallels between js/html and css/html. React disregards the js/html because they acknowledge that there never really was proper separation. With css/html, at least to me, it seems like there is a clearer separation. Maybe I'm being shortsighted.
- catshirt 13y ago
  not short sighted at all. i haven't completely convinced myself yet either. :) i guess the question i struggle with then is, what is so nice about that separation? and, could those problems not also be solved in JS?
  - cnp 13y ago
    Exactly.
CognitiveLens 13y ago
Until recently I would disagree that we should find a way to integrate styling into the application code, but I think you make a good point, that styling can be seen as one property of an application component, something that should be coherent with its structure+behavior. As long as the styling code could remain simple to update independently of the business logic, it would be great to have it all part of the same internally-consistent dev system.
- X4 13y ago
  I see a recurring pattern in here! We all started seeing mixing markup, style and logic before 2000. Pre 2000 was ruled by functional programming and the decade before was ruled by procedual programming. Then we rapidly started to "encapsulate", when OOP boomed. Now "packaging" is the main problem every programming language and OS has to solve. Today we end up implementing lightweight packages, so called components and we think it's a new idea to use statemachines to keep the interdependent component's state coherent. This idea was influenced by the boom of Interpred programming languages. Although 40 years ago, there were programs that only focused on allowing "components", which were "pluggable" modules back then, to be controlled by the DataFlow Pattern [1]. To formalize the main problem of the HTML,CSS and Javascript abstractions, blended into the DOM, we have to recognize that Data (Input) and UI (Output) are bound to States (Data Flows [2]). A solution to these problem is to use the FBP paradigm [3] in the browser engine and to implement the UI as an array of graphs. Usage of vectors allow the use of highly advanced mathematical solutions to be used to apply a optimization much easier than it is possible today, without rewriting the browser engine. For instance creating a UI now just means dragging and dropping items into a pane, which creates a matrix of number sequences that have relations to each other, yes basically a graph. Because the UI and State is deterministic (except for Networks protocols!?), we can use the Knaster–Tarski theorem [4] to solve such DataFlow problems. Using Topological Data Analysis (TDA), we can even get deep level insight into UI & usage patterns that evolve and recur. "Control of the language we use can be used to restrict our thinking. I find that this pattern is proving George Orwell's Newspeak [6] is similar to programming languages today. What do I know, so please correct me when you think that there is no such pattern, or when you think something is wrong in what I said. So that others will profit from it. -- [1] http://en.wikipedia.org/wiki/Dataflow_programming http://en.wikipedia.org/wiki/Dataflow_programming [2] http://en.wikipedia.org/wiki/Dataflow http://en.wikipedia.org/wiki/Dataflow [3] http://en.wikipedia.org/wiki/Flow-based_programming http://en.wikipedia.org/wiki/Flow-based_programming [4] http://en.wikipedia.org/wiki/Knaster%E2%80%93Tarski_theorem http://en.wikipedia.org/wiki/Knaster%E2%80%93Tarski_theorem [5] http://en.wikipedia.org/wiki/List_of_programming_languages_by_type http://en.wikipedia.org/wiki/List_of_programming_languages_b... [6] http://en.wikipedia.org/wiki/Newspeak http://en.wikipedia.org/wiki/Newspeak
  - 13y ago