4 ms·

When the parent says view, they're not talking about "a) markup", they're talking about the thing the user is looking at. > b) ids that indicate that a given t

by munro 11y ago

When the parent says view, they're not talking about "a) markup", they're talking about the thing the user is looking at. > b) ids that indicate that a given tag will be replaced with a component With that in mind, your disagreement is contradicted by this statement because logic has just been described to update the view. Logic is necessary to generate a view of the data for the user. With JSX, keeping all of this code closer together that is intrinsically tied together increases cohesion, by definition. Subjectively, this makes it easier to manage UI because one only have too check one place for all the pieces. For further exploration of this idea, check out the intro of this video on separation of concerns vs technology. [1] On a separate point, it sounds like one must imperatively update the UI with Wicket, which is objectively more complex than what React affords, which is stateless UI. Time is removed from the equation, which also makes things easier to reason about. [1] https://www.youtube.com/watch?time_continue=275&v=x7cQ3mrcKaY https://www.youtube.com/watch?time_continue=275&v=x7cQ3mrcKa...

lmm 11y ago
> With that in mind, your disagreement is contradicted by this statement because logic has just been described to update the view. Logic is necessary to generate a view of the data for the user. There is no logic in the "template". No looping, no branching. Only inert ids. There is logic in determining which component replaces each id, but that logic lies in the code, not the template. > it sounds like one must imperatively update the UI with Wicket, which is objectively more complex than what React affords, which is stateless UI. Not so. Wicket clearly separates its state into models, you write UI that depends on a model as a function of that model. It leads to a very declarative/functional style, where the only "magic" is encapsulated and explicitly managed. (You do have to declare which changes update which UI (for performance reasons), but you can make that "always re-render the whole page" if that suits your use case).
- munro 11y ago
  > There is no logic in the "template". No looping, no branching. Only inert ids. There is logic in determining which component replaces each id, but that logic lies in the code, not the template. Again, changing view to mean "template" is a strawman. > Wicket clearly separates its state into models > You do have to declare which changes update which UI (for performance reasons), Separating state isn't the same as no state. Also imperatively updating the UI on state changes is stateful. Which increases complexity, which for most people makes code hard to reason about. > but you can make that "always re-render the whole page" if that suits your use case Anything can be made to do anything, so this point is moot. If this model was trivially applied, would it lead to flickering, lower performance, losing scroll position, losing selection, or losing input focus?
  - lmm 11y ago
    > Again, changing view to mean "template" is a strawman. Call it what you like. The point is that clear separation between logic and markup can be done and is valuable. > Separating state isn't the same as no state. Any web page that has inputs or controls is necessarily stateful - otherwise where does the input go? > Also imperatively updating the UI on state changes is stateful. There's nothing imperative about it. Have you looked seriously at Wicket or are you just throwing buzzwords around?
    - munro 11y ago
      > Call it what you like. The point is that clear separation between logic and markup can be done and is valuable. You concede the original point. To your new point, saying something is valuable doesn't make it valuable. Why? It decreases cohesion, which is not good. > Any web page that has inputs or controls is necessarily stateful - otherwise where does the input go? If this is a serious question, it's too far off any original point to teach you unfamiliar concepts. Learn about what stateless, declaratively, & imperatively UI means so there aren't strawmans, and so you can weigh in on these discussions. > There's nothing imperative about it. Have you looked seriously at Wicket or are you just throwing buzzwords around? Please do not dilute conversations on here by name calling. Imperative & state are basic computer science terms... o_O
      - lmm 11y ago
        > You concede the original point. No. Your original claim was that you need to mix logic and layout. You don't. > If this is a serious question, it's too far off any original point to teach you unfamiliar concepts. Learn about what stateless, declaratively, & imperatively UI means so there aren't strawmans, and so you can weigh in on these discussions. It's not me who needs to learn what those words mean. Either you're just trolling, you don't understand the terms, or you don't understand wicket.
        munro 11y ago
        If you disagree with something I said, please disagree with it directly with reasoning, without name calling, ad hominem, or strawmans, at the exact thread. If I use terms incorrectly, correct me, and better yet, give an ironman of what I was trying to say.

by munro 11y ago

lmm 11y ago

> With that in mind, your disagreement is contradicted by this statement because logic has just been described to update the view. Logic is necessary to generate a view of the data for the user. There is no logic in the "template". No looping, no branching. Only inert ids. There is logic in determining which component replaces each id, but that logic lies in the code, not the template. > it sounds like one must imperatively update the UI with Wicket, which is objectively more complex than what React affords, which is stateless UI. Not so. Wicket clearly separates its state into models, you write UI that depends on a model as a function of that model. It leads to a very declarative/functional style, where the only "magic" is encapsulated and explicitly managed. (You do have to declare which changes update which UI (for performance reasons), but you can make that "always re-render the whole page" if that suits your use case).

munro 11y ago
> There is no logic in the "template". No looping, no branching. Only inert ids. There is logic in determining which component replaces each id, but that logic lies in the code, not the template. Again, changing view to mean "template" is a strawman. > Wicket clearly separates its state into models > You do have to declare which changes update which UI (for performance reasons), Separating state isn't the same as no state. Also imperatively updating the UI on state changes is stateful. Which increases complexity, which for most people makes code hard to reason about. > but you can make that "always re-render the whole page" if that suits your use case Anything can be made to do anything, so this point is moot. If this model was trivially applied, would it lead to flickering, lower performance, losing scroll position, losing selection, or losing input focus?
- lmm 11y ago
  > Again, changing view to mean "template" is a strawman. Call it what you like. The point is that clear separation between logic and markup can be done and is valuable. > Separating state isn't the same as no state. Any web page that has inputs or controls is necessarily stateful - otherwise where does the input go? > Also imperatively updating the UI on state changes is stateful. There's nothing imperative about it. Have you looked seriously at Wicket or are you just throwing buzzwords around?
  - munro 11y ago
    > Call it what you like. The point is that clear separation between logic and markup can be done and is valuable. You concede the original point. To your new point, saying something is valuable doesn't make it valuable. Why? It decreases cohesion, which is not good. > Any web page that has inputs or controls is necessarily stateful - otherwise where does the input go? If this is a serious question, it's too far off any original point to teach you unfamiliar concepts. Learn about what stateless, declaratively, & imperatively UI means so there aren't strawmans, and so you can weigh in on these discussions. > There's nothing imperative about it. Have you looked seriously at Wicket or are you just throwing buzzwords around? Please do not dilute conversations on here by name calling. Imperative & state are basic computer science terms... o_O
    - lmm 11y ago
      > You concede the original point. No. Your original claim was that you need to mix logic and layout. You don't. > If this is a serious question, it's too far off any original point to teach you unfamiliar concepts. Learn about what stateless, declaratively, & imperatively UI means so there aren't strawmans, and so you can weigh in on these discussions. It's not me who needs to learn what those words mean. Either you're just trolling, you don't understand the terms, or you don't understand wicket.
      - munro 11y ago
        If you disagree with something I said, please disagree with it directly with reasoning, without name calling, ad hominem, or strawmans, at the exact thread. If I use terms incorrectly, correct me, and better yet, give an ironman of what I was trying to say.