Sounds like we need a fundamentally different approach to UI...
15 years trying to make everyone separate HTML, JavaScript, CSS – and then
41–50 of 177 posts
Re: 15 years trying to make everyone separate HTML, JavaScript, CSS – and then
#42I kind of want to show him this code to upset him more. I think React is great, especially when using it through ClojureScript.
(defn todo-list []
(let [todos (atom [])
text (atom "")
add-todo #(do
(swap! todos conj @text)
(reset! text ""))]
(fn []
[:form {:on-submit add-todo
:action "javascript:"}
[:input {:type "text"
:value @text
:on-change #(reset! text (.-target.value %))}]
[:button {:type "submit"} "Add"]
[:ul
(for [todo @todos]
^{:key todo} [:li (str todo "!")])]])))Re: 15 years trying to make everyone separate HTML, JavaScript, CSS – and then
#43Earlier quoted context omitted.
This is a really smarmy and ignorant comment - if you tell me that you are an experienced react programmer and therefore understand what you are looking at, then I'll reconsider, but as it stands, your comment is just ignorant.
Why react specifically? My general experience tells me that mixing presentation and logic ends badly, as well as the collective experience of the industry. We've been down this path with just about every GUI technology before but it seems we have to learn it again.
Why react specifically? My general experience tells me that mixing presentation and logic ends badly
If you’re talking about the `todos` list in the tweeted example, I’m afraid you’ve been successfully trolled. In non-toy code, you’d typically hold the underlying state in a separate part of your system rather than the rendering React component, as with any other sanely designed UI. That data would be passed into the React component via `props` so it knew what to render, and the callback function to handle a form submission would also be passed in via `props`, and the React component would have no dependencies on anything else in your system. It’s actually one of the simplest, cleanest and most completely specified interfaces of any modern JS UI library or framework, in my experience.
It is true that a React component can also hold its own state and can use that data in addition to the supplied props when rendering. However, that state is normally reserved for UI-related data that isn’t part of the underlying data model, such as keeping track of a selected item or which page is currently active on a paginated table view. Toy examples like to-do lists sometimes use React component state to hold more general data, because that is simpler in a trivial demonstration than writing separate MVC components or the equivalent, but that’s not how you write idiomatic React code in production systems, and it never has been.
Re: 15 years trying to make everyone separate HTML, JavaScript, CSS – and then
#44Earlier quoted context omitted.
Why react specifically? My general experience tells me that mixing presentation and logic ends badly, as well as the collective experience of the industry. We've been down this path with just about every GUI technology before but it seems we have to learn it again.
Why react specifically? My general experience tells me that mixing presentation and logic ends badly If you’re talking about the `todos` list in the tweeted example, I’m afraid you’ve been successfully trolled. In non-toy code, you’d typically hold the underlying state in a separate part of your system rather than the rendering React component, as with any other sanely designed UI. That data would be passed into the…
Do you know of an example that does things properly? There are a lot of people here defending the code as written.
Re: 15 years trying to make everyone separate HTML, JavaScript, CSS – and then
#45I think the big thing most people miss is that whilst separation-of-concerns is a great idea, trying to make the division line happen between our styles and our logic was a really bad idea, historically. We're much better off having the "dividing lines" be between different UI components and different segments of an application. If I have some really weird custom CSS for some component on a site, I'd much rather have…
It was fine when the UI was basically simple enough to be one or two components. Having 40 different independent "components" is relatively recent, and shows the weakness of the old separation.
> Having 40 different independent "components" is relatively recent, and shows the weakness of the old separation.
Maybe on the web, but we've been creating desktop (and console) applications just as complicated as any web app for a long time, that's where the importance of separation of concerns was first learned.
Re: 15 years trying to make everyone separate HTML, JavaScript, CSS – and then
#46We're building desktop applications with HTML now even when we're using them inside a web site. I'm not surprised that programming patterns start looking like the ones of desktop applications. It has been 10 years since I did one, not counting a couple of small Android apps 5 years ago. I remember UI widgets instantiated in a Java file, not much different from what I saw in this post. The next step could be a Visual Basic like UI designer to arrange widgets. Flexbox would help there. Remember that development for the desktop is a kind of solved problem with some will defined tools. JavaScript, HTML, CSS will get there too.
Re: 15 years trying to make everyone separate HTML, JavaScript, CSS – and then
#47Reading the comments I'm wondering if I'm the only one who noticed that this example does NOT intermingle CSS. This is a view component that keeps track of it's own state. It is 100% encapsulated and by building in events and data bindings it can be composed into more complicated applications. It is in fact separation of concerns. This is only one concern. The UI of a single component. In a full React app the busines…
Yes, given the tweet text I was looking for the css in the image but couldn't find it, I didn't want to bother looking for too long and figured it was just well hidden.
Re: 15 years trying to make everyone separate HTML, JavaScript, CSS – and then
#48Reading the comments I'm wondering if I'm the only one who noticed that this example does NOT intermingle CSS. This is a view component that keeps track of it's own state. It is 100% encapsulated and by building in events and data bindings it can be composed into more complicated applications. It is in fact separation of concerns. This is only one concern. The UI of a single component. In a full React app the busines…
Yea, I'm super confused on how this snippet of code is meant as evidence of un-separated concerns. He even says it contains styling, but it absolutely does not.
Sure, if someone does React incorrectly, they will inter-mingle code that could make working on it painful, but that's true of vanilla HTML/JS/CSS as well.
Having developed using React for a bit now after years of using mostly vanilla JS/jQuery, I would never go back if I can help it. It's much nicer to write code that generates markup rather than code that manipulates markup.
Re: 15 years trying to make everyone separate HTML, JavaScript, CSS – and then
#49Earlier quoted context omitted.
Why react specifically? My general experience tells me that mixing presentation and logic ends badly If you’re talking about the `todos` list in the tweeted example, I’m afraid you’ve been successfully trolled. In non-toy code, you’d typically hold the underlying state in a separate part of your system rather than the rendering React component, as with any other sanely designed UI. That data would be passed into the…
Do you know of an example that does things properly? There are a lot of people here defending the code as written.
What sort of thing did you have in mind? If you look at some of the other tools widely used in conjunction with React, the entire Redux ecosystem is about maintaining application state and systematically updating it in response to whatever events might be interesting in your system. There are libraries like Immutable.js, which like React itself is provided by Facebook, to help manage an immutable underlying data store. I imagine any decent tutorial material about using those together would provide some better examples than the contrived to-do list example from the tweet.
I’d like to repeat here that React doesn’t require that you use that particular style of architecture, and there are plenty of reasonable alternatives. However, hopefully those examples should suffice to demonstrate that separation of underlying state from UI rendering and responding to interactions makes as much sense with React as in other contexts and is widely employed in practice.
Re: 15 years trying to make everyone separate HTML, JavaScript, CSS – and then
#50Earlier quoted context omitted.
This is a really smarmy and ignorant comment - if you tell me that you are an experienced react programmer and therefore understand what you are looking at, then I'll reconsider, but as it stands, your comment is just ignorant.
Why react specifically? My general experience tells me that mixing presentation and logic ends badly, as well as the collective experience of the industry. We've been down this path with just about every GUI technology before but it seems we have to learn it again.
Look again; it doesn't mix presentation and (business) logic. It's all view, with the added bonus of not needing to code state transitions in the view.