3 ms·

> separate templates from view logic (probably the biggest sin) Not a sin. > or, I suspect, don't fully understand Your suspicion is wrong and so pointless I

by luord 8y ago

> separate templates from view logic (probably the biggest sin) Not a sin. > or, I suspect, don't fully understand Your suspicion is wrong and so pointless I'm shocked this comment became the top one for this thread. Usually, pointlessly provocative stuff gets downvoted, as it should. > React's fundamentally paradigm and convention shift. You mean the paradigm shift of mixing HTML and JavaScript in the same hodgepodge? That's what we moved away from in the first place. React brought it back and many people convinced themselves that now it should work. > React is so thin that it's rare to have a "React" problem, now I have vanilla "Javascript" or even "function" problems Ah, this explains it. So deep into the... I don't want to say fanaticism but I can't think of another word, that there's even a preemptive rationalization of the technology's problems. And this comes from someone who, over the last two years of experience, has taught himself to stop hating react by sheer force of will.

sanderjd 8y ago
> You mean the paradigm shift of mixing HTML and JavaScript in the same hodgepodge? Are you talking about JSX? If so, this doesn't ring true to me; it isn't a mixture of HTML and javascript, it's just javascript with an HTML-like macro syntax. I've personally always found that really weird, but it isn't a hodgepodge, it's just normal javascript function calls with a weird syntax.
- luord 8y ago
  > it isn't a mixture of HTML and javascript, it's just javascript with an HTML-like macro syntax. This is a distinction without a difference. The point is that putting HTML and JS logic in the same file is what was usually done in the early days of programming on the web, before separating code from event attributes into their own script tags and files became the norm. All JSX does is the exact same mix in the opposite direction: it's not about JS inside HTML; it's HTML inside JS. And I understand that that's fine for many people -- and I've learned to stop caring -- but I take issue with pretending that it's a "paradigm shift".
  - sanderjd 8y ago
    At risk of repeating myself, it isn't HTML inside JS, it's just JS function calls with a weird HTML-mimicking syntax. You aren't putting "HTML and JS logic in the same file", it's literally all JS. It's like how you could write lisp code with the s-expressions represented with XML: it's not a different thing, it's the same thing with a different syntax. Maybe your point is that you don't like the style of building up HTML strings by composing function calls. If so, fair enough, but I would argue that the jury is very much out on the trade-offs between that approach vs. an interpreter for a template language. React's string-building API is not the only example of this style; for instance lisps seem to do it that way pretty often (probably because sexprs are a quite natural syntax for this). Personally, I find the string-building approach much easier to reason about. It's a more explicit and well-defined problem. Instead of parsing and augmenting an existing string, the implementation just needs to transform some parameters to an output string. As I said, I'm not really a fan of JSX itself because I find it weird (and unnecessary), but I do like the simple string-building API it gets translated into.
    - deleted 8y ago
      [deleted]
stevebmark 8y ago
I feel worried reading this post, because it doesn't seem like you have separated impulsive emotional responses from objectivity, and when I see engineers have this behavior, I believe it masks our ability to asses technology well. For example mixing view logic with view templates, both in the view concern, (and the concept of a DSL), follow computer science principles of domain/concern separation, vs separation of technologies like ("html" and "js", which isn't even fully accurate for JSX), is not a computer science principle, and has no benefit when separated.
- deleted 8y ago
  [deleted]

by luord 8y ago

sanderjd 8y ago

> You mean the paradigm shift of mixing HTML and JavaScript in the same hodgepodge? Are you talking about JSX? If so, this doesn't ring true to me; it isn't a mixture of HTML and javascript, it's just javascript with an HTML-like macro syntax. I've personally always found that really weird, but it isn't a hodgepodge, it's just normal javascript function calls with a weird syntax.

luord 8y ago
> it isn't a mixture of HTML and javascript, it's just javascript with an HTML-like macro syntax. This is a distinction without a difference. The point is that putting HTML and JS logic in the same file is what was usually done in the early days of programming on the web, before separating code from event attributes into their own script tags and files became the norm. All JSX does is the exact same mix in the opposite direction: it's not about JS inside HTML; it's HTML inside JS. And I understand that that's fine for many people -- and I've learned to stop caring -- but I take issue with pretending that it's a "paradigm shift".
- sanderjd 8y ago
  At risk of repeating myself, it isn't HTML inside JS, it's just JS function calls with a weird HTML-mimicking syntax. You aren't putting "HTML and JS logic in the same file", it's literally all JS. It's like how you could write lisp code with the s-expressions represented with XML: it's not a different thing, it's the same thing with a different syntax. Maybe your point is that you don't like the style of building up HTML strings by composing function calls. If so, fair enough, but I would argue that the jury is very much out on the trade-offs between that approach vs. an interpreter for a template language. React's string-building API is not the only example of this style; for instance lisps seem to do it that way pretty often (probably because sexprs are a quite natural syntax for this). Personally, I find the string-building approach much easier to reason about. It's a more explicit and well-defined problem. Instead of parsing and augmenting an existing string, the implementation just needs to transform some parameters to an output string. As I said, I'm not really a fan of JSX itself because I find it weird (and unnecessary), but I do like the simple string-building API it gets translated into.
  - deleted 8y ago
    [deleted]

stevebmark 8y ago

I feel worried reading this post, because it doesn't seem like you have separated impulsive emotional responses from objectivity, and when I see engineers have this behavior, I believe it masks our ability to asses technology well. For example mixing view logic with view templates, both in the view concern, (and the concept of a DSL), follow computer science principles of domain/concern separation, vs separation of technologies like ("html" and "js", which isn't even fully accurate for JSX), is not a computer science principle, and has no benefit when separated.

deleted 8y ago
[deleted]