4 ms·
I was nodding and agreeing right up until he got to the part where he was talking about how he's using Hyperscript as a replacement. Hyperscript's just the sam
by csense 11y ago
I was nodding and agreeing right up until he got to the part where he was talking about how he's using Hyperscript as a replacement. Hyperscript's just the same problematic design with a different syntax.
Mixing HTML and server side code may let you do toy projects quickly, but in the real world it's a great recipe for building an unmaintainable, undifferentiated, monolithic mess.
- matt4077 11y agoSo how exactly do I specify the place where I'd like <date> if I can't do some variation of <span className="date">{date}</span>?
- bigpeopleareold 11y agoThe historical problem with mixing HTML and server-side code has been one of mixing responsibilities. I'd probably still recommend keeping them separate for an HTML/server-side code application, but for frontend work, it takes on a different character. I work on very "functionality-oriented" applications; no dedicated designers here. Having a split between JS view code (example, in the form of Backbone views) and template code is just frustrating to deal with. React addresses the issue by putting the relevant pieces of view code together. The React code should be separate from other code types (whatever you would call it: models, business logic etc.), but that's just like what we are trying to solve with separating server-side + HTML. I still think however, React is controversial. I would be considerate when deciding to use it, because I just don't think it is that important for many applications.