31–40 of 177 posts
Now, have I told you all about intercooler.js...
Why would an integrated component not include it's logic plus presentation? Putting logic here and presentation there immediately leads to the need for a mechanism to ensure that this version of the presentation is matched with that version of the logic. The real objection seems to be "I'm smart and I don't like it", not some considered explanation of what the inherent reason is to separate logic and presentation. Th…
> Why would an integrated component not include it's logic plus presentation? Typically this makes it hard to test the logic. That's the big reason why logic and presentation were separated in the first place. > Putting logic here and presentation there immediately leads to the need for a mechanism to ensure that this version of the presentation is matched with that version of the logic. In the past this was handled…
Why?
You have your underlying data model, and any associated constraints and business logic built around that data. This can be tested using whatever tools you normally like to use.
Independent of that, you have how you want to render some or all of that data in some particular way, which is the part React handles. There are tools for testing this as well, though in practice I rarely use them as I don’t like to have any complicated logic at this level in my design anyway.
If you do need to do some non-trivial work to get from the underlying data to the processed data that is used for rendering — perhaps selecting the top five items from a set by some criteria, or combining some conditions to see whether a control should be enabled or disabled — you can build an intermediate layer that sits between the underlying raw data and the rendering logic. Again, this is a typical architecture for large-scale UIs that has nothing specifically to do with React, and again, the code can be tested with your preferred tools.
In short, contrary to the tweet, we aren’t actually writing code like that in real projects built using React.
What this image doesn't show: Refactor safety. When I can include my CSS as modules into my components (which, by the way, is still separated, only now it's completely isolated from demonic CSS side-effects), and when I can TEST my HTML (read that again: TEST my HTML, again, easily separatable meaningfully by utilizing a pure-function mechanism), and when I can use something like Flowtype to identify structures in my…
A bit too strong.
Imagine Markdown becomes wildly popular and the majority of the Internet's content is now available in Markdown.
As more content becomes available, we expand Markdown to include forms to get bidirectional communication.
There are some layouts and styles that can't be done in markdown, so we add stylesheets. Can't exactly write them in Markdown, so we have to come up with a new language.
Then people want to form validation or augment the UI in more dynamic ways, because hey, this is the platform. So we add a turning-complete language. Can't be Markdown of course, so we make a scripting-language for Markdown.
---
HTML wasn't made for flappy bird; it was made for text markup. But practicality beats purity over and over and eventually people want to use the super-compatible browser platform with easy distribution model for everything.
No one sinned; we just wound up here through a lot of inventions, accidents, and opportunities.
If I have some really weird custom CSS for some component on a site, I'd much rather have said CSS be embedded in the code for that one odd component - and scope-limited so it doesn't affect anything else (at my workplace we've got a common practice where any sass we write is usually scoped to only ever affect children of specific dom classes, and we use this to make sure it affects "its own kind of component, and never anything else".
I've been through the hell of having totally segregated CSS, and trying to hunt down where "that one weird styling rule" is coming from is a real mess.
There's also the fact that very often CSS really has to be data driven; if I'm doing a bar chart on some page and I'm using rectangular divs to represent the individual chart series, the only way I know of to set their height, client-side, is via javascript. React is quite nice because I can guarantee the presence of required dom elements for something like this, and even restructure them on the fly, and have a number of guarantees about avoiding race conditions, which I don't get via something like jQuery.
It is amazing how much react resembles php and classic asp from 15 years ago. I guess that's what happens when you don't hire anyone over 30.
Bitter over 30 year-old? (I'm 43 btw so not trying to be ageist, just asking what seems like an obvious question) It does look similar but it is night and day different beyond the superficial appearance. Are you actually trying to say that the in-browser experience in web apps from 15 years ago were in the same ballpark as even simple single page javascript apps from today? That is laughable. So something must be dif…
Yes I'm bitter that the same errors we made with desktop apps in the 90's (and possibly earlier) are being repeated.
> Are you actually trying to say that the in-browser experience in web apps from 15 years ago were in the same ballpark as even simple single page javascript apps from today?
Yes. The biggest difference is the amount of postbacks, the state handling has moved client side.
In my 15 years I've come to realize that HTML code-generation via JavaScript (or now TypeScript actually) is vastly superior to any type of templating (like JSP, JSF, Velocity, Mustache). Both ways (templating v.s. straight generation) have exactly one sort of 'level of indirection' so they are on the same order of complexity, but generating HTML rather than templating it is a billion times more powerful, so it is ju…
The linked tweet is nothing but a troll and everyone fell for it. I seriously don't understand why people want to hate on js so hard where they just contrive trite and inaccurate one-liners like this.
I 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…
Having 40 different independent "components" is relatively recent, and shows the weakness of the old separation.