The same thing lures people in every time. You sit down, open a single file and type for 5 minutes and you've got a baby web app. Whee! The pain comes later. So much pain.
This was exactly my thought, and it's not like I'm even that old. We should know better by now. I went from writing PHP in high school that looked exactly like this, to using Python CGI and then finally Flask to write (I think) very modular, maintainable web applications.
Now several years later I'm inheriting Nodejs and [flavor of the month] Javascript framework projects from coworkers that look like the PHP video sharing site I wrote in 10th grade using XAMPP.
I feel like I have (or everyone else has) contracted some sort of amnesia. Didn't we already hash this out guys?
I've been lucky enough in the general case to either be in charge of system design or have very thoughtful coworkers who are well aware of the burden of technical debt.
Unfortunately I can't babysit every other team and have occasionally inherited some real abominations. Often times it has been worth spending the ~week in man hours to immediately rewrite them to avoid the constant time suck of maintaining spaghetti code down the line.
Often they are a kernel of simple functionality buried in thousands of lines of code smeared across a random assortment of files that can actually be replaced fairly simply once you've sussed out what they're actually supposed to be doing.
While old school PHP might look like this it is not the same thing by far. The code in this screenshot is a stateful component and is supposed to encapsulate all the logic on how it should be displayed in one place.
It is close to a view in a MVC framework than true old-school spagetti code.
But unlike a view component in an MVC framework the stateful components can update themselves automatically when data changes much more elegantly than they could in older systems.
Granted some people write React and include business logic in their components but you're not really supposed to do it that way.
Curious on your take; for a component, why do I need the virtual dom diffing?
If I'm working on a component level, it's already granular enough where I can easily understand the changes that need to be made and I can just update those DOM elements myself (e.g. Oh, I should add this class here and update my shopping cart total).
The DOM diffing for small components seems so... heavy handed. "Don't worry React, I got this.."
For a solo project I think React doesn't offer quite as much benefit (although I think I am faster in it). But for team projects the team members can stop worrying about where the data comes from and just worry about their component.
In your shopping cart example, say the project manager decides they want to display how may of an item you have in your cart next to the item in the catalog. Then a feature is added to remove items from any page by having a dropdown on the cart logo.
So is it the responsibility of the person writing the cart dropdown to update the catalog listing or the responsibility of the person writing the catalog listing to know about the drop-down?
In React you only need to bind to the data. If the data changes and your DOM then changes as a result then you update. You don't need to know why or how it changed.
As far as the virtual DOM being perhaps heavy handed. It is a performance optimization and not really a core concept. The React team found it was faster to update only the parts of the DOM that changed rather than redraw the entire screen and came up with a clever way to do that without having to know the implementation details of each component.
Contrast that with the naive approach (using innerHTML) which would make even a "update the character count every time a key is pressed" UI grind to a halt.
(I’m not the person you replied to, but I’ll offer some thoughts anyway.)
for a component, why do I need the virtual dom diffing?
React allows you to build relatively large and complicated DOM trees by composing smaller components, and it is designed so you can then (re)render the entire tree as a single operation when any relevant underlying state changes, without having to manage (re)rendering each individual component within that tree manually.
This is useful because now you only need to define one absolute way to render from a given set of underlying data. You no longer need to give a relative specification for all possible transitions from one state to another, which can be a huge reduction in complexity and edge cases if you’re working on a large, complicated UI.
However, other things being equal, rerendering your entire DOM tree on the slightest change in the underlying data would become painfully slow for any system that isn’t very small. That is partly because there are costs to regenerating the DOM tree itself, as with any template-based system. However, the tightest bottleneck in today’s browsers is usually the consequential costs that result from updating the DOM in terms of regenerating layout and so on.
The virtual DOM diffing is essentially a performance optimisation that lets you mitigate those consequential costs, because now only the parts of the DOM that actually change as a result of changes in the underlying data will lead to rerendering in the browser and the costs that incurs. In other words, virtual DOM diffing isn’t the point of React, declarative/absolute rendering is, but the former is what makes the latter fast enough to be viable.
As an aside, React’s answer to the other half of the performance problem, the cost of regenerating the entire DOM tree, is the `shouldComponentUpdate` function. That lets components, including child components deep within a large tree, perform any quick tests they can to determine whether their rendered output will actually change, and to skip the rerendering if not.
That leads on to various other ideas that have become popular in connection with React, such as using immutable data models for the underlying data. With immutable underlying data, a shallow comparison between a couple of object references that can be performed in moments acts as a “dirty check”.
However, you don’t have to use React in that way. Some people are wary of relying too much on `shouldComponentUpdate`, which inherently violates the “single source of truth” principle and risks introducing bugs if its assumptions differ from those of the same component’s `render` method. Others find the arguments for building your entire data store around immutable objects, which itself carries a hefty performance overhead, less compelling.
There are certainly other reasonable architectures you could choose for supplying the underlying data to React components and triggering rerendering when that data changes, including more traditional designs where view components observe the underlying data model in some way and trigger their own rerendering on any relevant change. Going down this path is effectively using React as a reasonably efficient and composable template rendering engine, so you can still have the advantages of absolute rendering logic, and you bypass some of the potential performance problems caused by doing large-scale rerenders with React, but in return you take back some of the responsibility to set up explicit dependencies between your view components and the data they depend on. As ever, there are trade-offs, and usually there will be multiple quite different designs that will do a decent job as long as you understand their pros and cons.
ReactJS is currently the fastest, most scalable frontend solution available so compared to all that has come before it, it can seem heavy handed. But if you want to build highly scalable apps like Facebook, Instagram, Pinterest, Reddit and Twitter mobile, then losing easy speed gains with every one of the hundreds to thousands of components you build is unacceptable.
The problem is that 99.99% of developers aren't (writing Twitter etc) but they still apply techniques used by unicorns to handle their own very exceptional needs.
We should always be wary of applying skyscraper building techniques when building a house or a shed.
I honestly bet that 99.99% of people who read Hacker News could write their applications with a drop of jQuery and some basic ES6 code.
I have nothing bad to say about these frameworks, more caution that we don't apply techniques needed at scale to small scale products.
> I feel like I have (or everyone else has) contracted some sort of amnesia. Didn't we already hash this out guys?
Maybe we're backtracking on the idiocy we started on around PHP times? The whole "separation of concerns" thing that went to such extremes as to become a cargo cult? I offer two observations:
- presentation is often very much content at the same time (that's why websites end up cluttered with divs that have no semantic meaning and serve no other purpose than being CSS hooks)
- separation of concerns was about not putting business code in views, not about having views without any code; you need code to drive views (and yes, template languages are Turing-complete, so they count as code too)
Agreed. Take the example of people hating XML and trying to reinvent everything good XML already had with JSON and JSON Schema. http://json-schema.org/
My biggest peeve with XML is there's no concrete way to represent a piece of XML in code, it's in my opinion TOO flexible. You can express something as an attribute, a child, multiple children of the same element, a value of a child, etc. It doesn't translate cleanly to any kind of object structure in terms of code. And it goes in reverse too.
Now, there are standards like SOAP, etc... In the end, JSON and some clear docs for an API is usually easier to reason with than any of the boatloads of cruft that came along with XML. Not to mention the much larger transmission size.
I am not sure if you had chance to play with JAXB, it maps xml very cleanly to java objects. I mean you can have the whole darn thing define inheritance and it would generate the corresponding relation in Objects too.
IMO It just needs to be given some consideration before rejecting as old bloated piece of crap.
That's because originally SGML/HTML/XML attributes were for (mostly) presentational details, but this role was shifted to CSS. The resulting combination does indeed look arbitrary, especially with CSS's total lack of mental discipline (but let's not be too harsh here).
In judging whether something should be represented as element text or as attribute, ask yourself whether that something is content or metadata. In a context where this distinction doesn't make sense, markup (SGML, XML, HTML) probably doesn't make sense either.
Markup isn't and never was intended for representing arbitrary data - it is for representing text with optional markup, and is designed for end-users and content authors, not necessarily web developers.
As for representing XML in code, there was E4X which allowed you to represent XML literals in Javascript (Firefox and rhino had it a couple years ago, but it kindof wasn't convincing). Keep in mind that Javascript was invented as a language to manipulate a DOM in the first place, so there you have your canonical representation of markup in Javascript.
Looking at the other comments, I realize you're looking for object/XML mapping. My opinion is that this is pointless (and I'm guilty of applying it back in the SOAP days, too), because objects are co-inductive data structures based on the types of programming languages, whereas XML is based on grammars eg. a description of a class of sequences of content tokens.
Sure you can represent objects, ie. a memory dump of a running program, as XML, but what's the point?
Could represent the same object structure, for example. JSON is a pretty clean mapping to objects/properties/arrays, with less chance of confusion, or alternate interpretations.
It couldn't. That would mean a different thing and would be the abuse of what XML should be used for.
Whether something is inside an element or is a property of said element has important semantical meaning. But not just that, with XML you can implicitly represent ordering, whitespace and type information with much less boilerplate.
So the argument for JSON is basically boils down to: "Javascript has horrible type support and doesn't support OOP. JSON models that experience better."
I guess that's what happens when you don't hire anyone over 30.
Writing as someone comfortably over 30, I don’t see the problem here (edit: meaning having something that looks like HTML and something that looks like JS in the same place).
If you need to generate content dynamically for a web page based on some underlying business logic and data, you need some sort of rendering logic that determines how to fill in the blanks in your generic pattern using your current specific information. This has been true for every template system and framework since forever.
Personally, I don’t much like putting the logic right there in the JSX, as the `map` does in the tweeted example. I think one of the nicer things about the way React and JSX work is that you do have the full power of JS to write your rendering logic, and you can build up a part of the rendered output separately and then compose the overall output from the individual parts without needing to put a lot of extra logic in there. But that’s just my personal preference, and others might reasonably disagree.
The challenges with building larger applications in PHP — or in JavaScript, for that matter — have more often been about not having good tools in the language to build cleanly separated, modular designs. That side of things has improved somewhat with time, and will probably always be less than ideal because of the legacy baggage these languages now carry, but in any case the big problems were never really about an artificial separation of HTML, CSS and JS, and including JSX within JS code when using React is little different to embedding conditional logic in any other template language used by any other programming language or library.
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.
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.
Your point here is one of my biggest struggles in trying to adopt react. I have looked at many of the toy examples and haven't seen a clean implementation of a non-toy. I've built a couple small things with it and haven't seen a clear path to how I'd implement something in my day job that I currently do in a Backbone app. I don't really feel like I need something like redux, so what am I to do? Continue building components that hold their own data? What is the way in react?
If you want to experiment, my advice would be to start by just using React as a template-rendering system that lets you conveniently build larger and more complex components by composing smaller and simpler ones and that can automatically change whatever is already in your DOM to whatever new DOM content you come up with when rerendering. At this stage, you can take advantage of React’s greatest strengths, but you don't need any bells and whistles like Redux or Immutable or MobX or whatever other state management libraries you’ve come across.
One thing I would recommend right from the start is storing your application state somewhere outside your React components, even if it’s just in plain JavaScript objects. When you’re ready to render a DOM tree, pass that data into the top-level React component via props. Have that top-level component in turn pass any relevant part(s) of its input data to any child component(s) that need that data for their own rendering.
Likewise, I would recommend defining the functions to handle any interesting events outside your React components. You can then pass any callbacks you might need in via props on your components as well.
If you try that sort of design out a few times with non-trivial apps, you’ll soon start to see common patterns where introducing other tools might be helpful, and at that point you’ll have a better understanding of what some of those other libraries do and which combinations of related libraries might be useful for your particular needs.
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.
Look again; it doesn't mix presentation and (business) logic.
Unfortunately, the example from the tweet really does: the storage and manipulation of the to-do list itself is right there, mixed in with the rendering component. I think it’s a bad example of how to write UI code using React, because while it’s concise and it works, the techniques it shows lack flexibility and don’t scale well, and they’re not how you’d actually write a larger app’s UI that renders using React.
> I guess that's what happens when you don't hire anyone over 30
It's comments like these while people don't hire anyone over 30. Rather than provide thoughtful critique of the platform the response is "This looks like something I saw 20 years ago and it didn't work then so it won't work now, I'm not even going to look at it!"
Speaking as someone who is over 30... before you criticize something, understand it. For example, this code is nothing like PHP spaghetti code for reasons I listed in other comments among others I'm sure I didn't think of.
I see it very often. People like "we did this 30 years ago. I guess what is old is new again. Hahaha" But I've lived through it... like many of you... I've gone from CGI scripts written in C++ when you couldn't even guarantee a browser had Javascript to PHP, to Ruby, etc etc etc, blah blah blah. But after all that, and a Computer Science degree, I gave React an honest look and while it's not perfect. It is worth a look.
And how often are the presentation and logic changed in isolation of each other... they aren't separate concerns at many levels. The concern is sepearated in React at a component level... how a component is rendered is just as important as how it raises/accepts changes outside of itself, and often interacts.
Also, having JSX in my JS is much easier to deal with than remembering some abstract DSL for how to iterate through children in a template language. It's no more goofy.
Anywhere from never to always. A Pure logic change shouldn't need a ui change. At some companies the ui and logic are different responsibilities (this used to be common). Other times there will be multiple UIs for the same logic.
This has been going on forever. 3-tier client-server code bases had problems separating "presentation logic" and "business logic" because often they're very very closely connected.
React runs on the client. It runs the logic needed on the client. And there has always been some logic required on the client, otherwise you end up refreshing the screen for every.single.validation. which is a total PITA.
Given that there's some logic running on the client, then maybe running more of it there would be a good thing. This is the principle behind SPA's after all, and they've turned out to be a Good Thing generally. Not suitable for every use case, mind. So do we then need a separate Logic Layer for logic that isn't to do with Presentation? Where do we draw that line given that the whole thing is running on the client? How do we keep the thing clean and stop bits of logic being run on random button events?
React makes perfect sense when you look at it as an answer to the problem of "how do I add logic to my presentation layer and not end up in a mess of spaghetti code?"
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 different right?? Derisive condescending comments like yours prevent the conversation from figuring out what the positive is and ultimately keep the conversation stuck in the all too common and boring whining about javascript which has infected HN.
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.
But are they really the same... a common prescription for state management with react is to use something like flux or redux. State management solutions that have worked out well for gaming platforms to this day. Not the MVC patterns that bring a lot of complexities that make cross cutting concerns that much more difficult.
This is emphatically NOT the same as the desktop apps in the 90's.
The problem is that while true web apps experience might have improved, the web as the whole degraded a lot since everyone is treating everyting as the app, whn in reality majority should be just a static content sites. Now you download 4MB of crap just to see 2KB of text.
I started my career "professionally" with Cold Fusion 3 or 4 about 16ish years ago, and left it behind for PHP4, and so on, once I had to start paying for my own hosting.
I realized a couple months ago how incredibly similar JSX is to Cold Fusion - At least CF4. It's nearly identical in some respects.
Interestingly enough, I am over 30, and my day job is to both write new React code, new modern php code, and to maintain some "classic" php code that intermingles logic, SQL, HTML, CSS, and javascript in one horrible disaster.
So I think I can say with some confidence that everything you have written is completely nonsense.
> It is amazing how much react resembles php and classic asp from 15 years ago.
Actually, React was written by developers, who may or may not be over 30, who have a very solid understanding of PHP (Facebook) and sort to replicate their discipline and success with PHP on the client.
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 code DESPITE the type limitations of Javascript, and when I can do it performantly and brainlessly _EVEN IN_ the slapdash "platform" of The Browser (TM), yes, this is a _huge_ step forward. Don't blame the people who decided to do something about the shittiness of Tim Berners-Lee's overly-verbose and unmaintainable HyperText Markup Language for a solution that doesn't look as pretty as Python.
> shittiness of Tim Berners-Lee's overly-verbose and unmaintainable HyperText Markup Language
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.
You're accusing TBL for "demonic" CSS (seriously?) which he didn't invent? You should ask yourself why you're attempting to use a document delivery platform into an app delivery platform for shitty apps that nobody wants anyway.
Separation of concern or technology? A well structured React application is much easier to understand than something where you need to keep 3 files in your mind at once.
It used to be a separation of conterns. HTML for structure, CSS for presentation, JS for some bells and whistles.
Now, when everyone forgot what the web was about and see it just and app platform that does not really apply.
The images of the 2000 line long JS and CSS monoliths didn't fit into a tweet. :-)
Seperation should be by the responsibilities a component, not by language. So the trend to components in frontend dev is right despite some unfamiliar mangling of html and js.
Reading 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 business logic will be in controllers and models that don't themselves contain view/UI code.
But because an HTML like syntax was chosen to represent view hierarchy we draw a red flag because it looks like we are mixing HTML with Javascript. But that was only ever a red flag because HTML semantically was hypertext representing data and relationships.
Having tried React in earnest (and yes, I know people will have counter-anecdotes) I can say that being able to components my web application leads to more testable code, easier delegating of workload across teams (each team member only needs to know the interface of a component to use it), and better code reuse. It is beautiful (albeit busy looking).
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.
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.
Tbh how is the one concern not the Fact they use 'let'. Gross.
Fun fact: types, line numbers, and BS keywords like 'let' 'var' and * *&uint32, are only constructs of the language authors mind... a visualization of how he thinks. And are completely optional to a language (given a slightly more flexible parsercompiler)
As an aside, is anyone else a a bit worried about is the massive use of destructuring assignment and rest operators and whatnot? I see it a more in React/Redux code than anywhere else.
I really like how it can reduce a number of tasks to less code, but it's the most common thing that trips me up when I read React or 'ESNext' codebases. It feels like ternary operators on steroids, with all advantages and disadvantages magnified.
It's a comfort thing, for sure. I've only started writing more with destructuring assignment recently (it's part of our code style guide at my new company), and it's doing things like forcing me not to use a different variable name for something that's already been defined. It's also forcing me to do more FP (since our stylguide also forces usage of `const`), which has actually made my code my more readable and maintainable (consistent naming, single-responsibility in functions, etc). Once you get used to the new syntax, it's a breeze to read and understand.
Well, once you understand a statement like this anyway:
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 just better.
To prove my point: Here's the code for the Audio Player in meta64.
No one can possibly argue that an HTML template for that would be easier to read, than the TypeScript I've written. I think the way meta64 uses Polymer, TypeScript, generated-HTML, etc is the ideal architecture for the modern app.
BTW: I just picked a random example of my generated code from meta64. I do agree the CSS embedded in that would be better as a CSS class. I am not arguing for dynamically created CSS, but only dynamically created HTML (i.e. no templates). My point was that if you have clean code, you can make your HTML-code-generation look almost like the HTML itself, or be 'as readable' as it would be if it were an HTML template. Readability is the key here. That's all that counts. If you can achieve that in JS/TS then it beats a template approach easy, because of its power in terms of OOP, reuse, etc, which templates are just awkward with.
Yeah - this, a thousand times, this. This is one of the biggest wins we've had recently over just about every prior web authoring approach - and my experience goes back to the PHP days.
Thanks, it actually wasn't a great example to make my point because that file contains actually a few things I do try to avoid, but it does demonstrate that "generated HTML" doesn't have to be ugly and hard to read, using TypeScript or even JavaScript if you have a consistent architecture for how it's done.
but they generate different JavaScript. The way it's written will give each instance its own reference to the function. The "build(): string" above will add the function to the prototype, which is shared by all instances.
I'm not sure whether the code takes advantage of this difference in some way or not. If not, it's just a slightly more awkward and less efficient way of defining a method.
That strange syntax with the arrow function is only needed so that the 'this' inside the function behaves the way one would expect it to in normal OOP language. It 'captures' the this for the object itself (like C++ would, etc). But that 'build()' function is what constructs a string that is the content for the dialog.
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.
The wider context is that these components are typically built within an organised class structure enabled by ES2015, and operate within an organised component lifecycle as defined by react. Integration of logic with presentation and code into a single component makes a great deal of sense to me - all I hear are haters griping from the sidelines about how it looks like PHP.
> 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 by compilers and tests.
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.
Inlining styles and lots of javascript looks pretty awful to me, but I don't mind binding actions directly to the UI elements they are associated with, so long as it is declarative (like anchor tags and forms do already)
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.
This is about react more than js specifically. There are plenty of javascript templating libraries that offer better separation between presentation and logic.
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 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.
> 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.
Yes, but where do you separate these concerns... Do you put view rendering and raising events in separate files? From my own experience in reviewing other people's code, it depends, but usually no. I mean, you can use MVC as separation pattern, but there's also MVVM and many other patterns that place the walls in different places.
I'm pretty happy with how React/Redux works compared to what came before... separating file structure by directories of features, and components/actions/reducers that represent them is much easier than looking in one spot for all my view templates with a goofy DSL abstraction, and another directory for the actual event binding.
It's great that you don't need Clojurescript or even JSX to do that. You can write plain ES5 and get the same result. And it would stay readable for most.
We'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.
This is a complaint I've heard often about React, and usually it's by someone that's never actually tried it (myself included before I first used it). But it's a visceral response. Until you sit down and give it a go, it's hard to believe that we had the separation of concerns wrong. Separation of concerns refers to responsibilities, not languages.
If you're building a static website, sure, you probably don't need React - the old tools and techniques handle that use case well. But if you're building a webapp, something with complex, dynamic client-side behaviour, it doesn't make sense to pretend that CSS, HTML and JS aren't already heavily coupled by the nature of what you're building. React just embraces that idea, rather than pretending it doesn't exist.
The reality of modern apps is that JS is going to transform your HTML and CSS at runtime, and most of the bugs you'll end up tracking down will be related to it being transformed in ways you weren't expecting. React's component model and declarative rendering are far more effective at addressing this problem than any other tool I've tried.
Completely agreed... I've been building web based apps for over two decades now. React is the first framework that feels "right"... there are some things that could be better, It's so much better than what came before. Angular brought me so many WTF moments, I can't even begin to mention them all, even ng2+. With React there's been a handful, usually with a useful error that made sense.
So much effort has been done with React to work with the broader JS community and its' direction as opposed to against it. ES6 class syntax, simple render function components, modules. React doesn't need much to get started, and it's unprescripted enough that just a few tools can round it out, with heavier and lighter options.
I don't want to go back, and frankly, I'd rather have JSX in my JS than go back to weird template DSLs ever again.
>This is a complaint I've heard often about React, and usually it's by someone that's never actually tried it (myself included before I first used it). But it's a visceral response. Until you sit down and give it a go, it's hard to believe that we had the separation of concerns wrong.
We didn't. And React doesn't change that either. React components are not logic code, they are UI code, and that has always went with view concerns (loop this times, show this button or that button depending on state, etc).
In the Desktop GUI space, where they don't have our HTML madness, do you think their UI components are not using code? Buttons, drop-downs, etc are not appearing by magic, they are created by code that does things like: draw a line of x length and y color, then another perpendicular to that, etc, then loop and draw some stripes, etc. That's the case even in Smalltalk, where MVC was invented. That still matches with "separation of concerns" -- which is about not mixing your BUSINESS logic with your UI code, not about not having code in your UI rendering.
In fact, compared to the classical way (foreach and other kinds of template instructions embedded in template strings, from PHP's Twig to Angular) it's even cleaner, because even though JSX looks like HTML it's actually compiled to Javascript instructions it's not just some ad-hoc language hidden in template tags to be interpreted at runtime.
And separation of concerns also applies to UI elements (encapsulation, re-use, etc) something which "logic free" templates like Mustache and so also miss (or, well, make harder -- of course if you try hard enough you can always fit a square peg in a round hole).
I've worked some with both WinForms and WPF, and so far I kinda like XAML. And is you're not only working in the windows world, I hear there's a similar-in-spirit JavaScript/HTML framework being used for "new hotness" style applications. Called "electron" or something like that I think?
Electron is that thing that bundles the whole web browser with your application so that you can write your usual web code and have it look like a desktop app.
I can't comprehend the very idea of "template languages". Especially in PHP, because PHP itself is a decent template language by design. But even outside - they always evolve the same. They start as a "lightweight" way to avoid putting code into view templates, but then they slowly accrue conditionals, loops, local variables, half-assed tools for defining functions, and before you know, your "no code allowed" template language becomes a Turing-complete and pretty crappy replication of PHP.
And all of that is orthogonal to the main insanity of this whole era - stitching HTML from strings. HTML is a structured tree format, and should be built out as a tree. Gluing strings together is the source of oh so many errors and security vulnerabilities...
And after you replicated PHP you come to the conclusion the templating language is as slow as hell. So you think: maybe we would need a compiler so we can cache the templates.
The question ofcourse is: why would people rather use:
And I think this goes deep. People are looking for more human ways to express themselves. And PHP is not a very beautiful language. So maybe my first example looks more 'human' than the PHP example.
Which at this point just differs in delimiters (<? and ?> instead of { and }) from the template language.
I don't have an opinion on this "more human way" to express oneself, but it seems that it would connect this case with the reason people seem to prefer curly braces to parenthesis in code too.
Which is, IMO, the main problem with using PHP (or any other from of plain string concatenation) as a templating language. Escaping everything (and security in general) should be the default, not something that you have to opt into at every turn.
I've never understood why people use templating engines in PHP. I've been an on again off again user of PHP for atleast 7 years now, and I've never understood it for exactly the reasons you outlined.
Plus React still encourages the traditional separation:
- Model is props/state.
- View is render().
- Controller is everything else (lifecycle, handlers, etc.)
IMHO it's also best-practice to separate view from presentation using CSS modules for component-level styles, and sprinkling namespaced classes here and there so that the component can be styled externally using application-level CSS.
We didn't get the separation of concerns wrong. React is the same we've been doing for 15 years, but we finally understood we had to modularize and encapsulate it to encourage reusability and true separation of concerns.
I'm never going back to traditional code that violates the single-responsibility principle. I'm never going back to manual DOM mutation. Give me modular, namespaced, declarative HTML+CSS+JS and I'll stop using React.
> Until you sit down and give it a go, it's hard to believe that we had the separation of concerns wrong.
Well, we had - the whole "separate content from presentation" thing was a cargo cult. Before the recent wave of JS frameworks, the standard website was littered with tons of div elements, almost all of which had zero semantic meaning, and existed only as CSS hooks and/or a hipster replacement for tables. And it was like nobody stopped to ask if all those divs aren't breaking the "separation of concerns" rule - or even if the rule made sense in the first place (it didn't; "presentation" often delivers as much information as "content" itself).
I don't know of any other industry so blinded by fads than web development.
I always thought it was a little silly to religiously persecute script-tags at the bottom of an html page for single-use event hooks and listeners and initialization logic. Instead I was told best practices were to split that one-off code out into another file, bundle it up with a bunch of other unrelated garbage, minify it, and link the whole kit and kaboodle in.
Meanwhile, when you need to go edit the logic operating on some element later, you end up grepping through your code base for ids, classnames, element types, whatever, trying to figure out where that bit of code that operates on that element got to, often several directories in the file structure away from the markup.
That's just silly. Ultimately every tool outputs a 'string' that gets sent to the browser.
What matters is how this happens, and there's a huge difference between React's approach and '<div class="whoops"><?php echo $some_unescaped_dangerous_thing ?></div>'
We could extrapolate this trajectory and take a page out of lisp history. Why don't we just let a "web page" be an s-expression delivered by http and run within a sandbox?
If you look at what the racket team has done for their documentation system "scribble", it is pretty clear that we can engineer whatever modularity we require for the purpose at hand given that generality.
Well, yeah. Forgive me, because I never know, here, if I am talking to my grand-son or my grand-pa, but "Separation of concerns", as an idea, came up when we thought that HTML/JS/CSS was about describing web-sites, for, for example, the NYT vs the WSJ, not for an applet or Swing replacement.
Separating content (including, maybe, semantics too) from presentation (branding, look&feel) makes sense when you are talking about web-pages. I don't even know how the idea transmogrified into a point-of-contention on SPAs.
It's quite funny when you think about it: "Look, Ma! I can build a fully functioning GUI out of type-setting elements and sticks!"
...but I agree with many of these comments; I thought it was odd (to be charitable) but after using it find it to be quite nice. Redux is what I see over used (imo) and at times almost an antipattern
The abstraction chosen by React makes a lot of sense to how my brain works. If one is bothered by the mixture of HTML/JS/CSS(where in the example?) there's always code generation.
I've been using preact with tsx and inline styles. Every component Is a es6 module that declares it's imports and exports. I have a theme.ts containing my theme variables. There are watchable models. Only views contain tsx and css as js. Views import a controller and mediate events to them. Controllers know nothing about the view and they are the only ones that can modify the model.
My application contains a single index.html with entry point to my js bundle, empty body tag and no css.
Everything is loaded as needed, encapsulated as modules. The simplicity is just amazing .
The way I think about it is react like thinking offers me the most semantic compression in my code.
I tried getting Preact to work with webpack and TypeScript, but I ran into issues with aliasing (which AFAIK isn't possible in TypeScript). How did you solve this issue?
(I use webpack because it now supports tree-shaking)
If you're curious where this came from, it's actually a Preact component (props and state being passed to render() is the tell-tale sign), taken from its homepage: https://preactjs.com/
The thing about Fuchs is that he's a very smart guy, who is deeply embedded in the modern JS world, and is absolutely aware of what that code is doing, why it looks the way it does, why the trend in frameworks has moved the way it has, just how many times the argument he's using has been advanced already, and how thoroughly it's been trashed over the years.
He knows that what he's said has been said a thousand times before, and he knows that every time it's said a bunch of people will reply with "separation of concerns, not seperation of technology", and he knows that's a very valid counterargument which can't be refuted in a tweet, which means he also knows how pointless this is. Which in turn means that he's not doing this to start a discussion, but just to get a rise out of people. Giving him the benefit of the doubt, he might actually have an interesting point to add to the debate...but we'll never know, since he thinks a better use of his time is trolling React developers than actually making his case for...whatever it might be.
Edit: Scroll through Fuchs' twitter feed right now; he's basically just non-stop trolling. "This is why we can’t have nice things" "Q: What is React? A: It’s PHP, but on the client." "I can see how react is awesome if you build todo apps that do nothing. :)" Then when noting how a million people are disagreeing with him: "I think that means that I’m on to something." No attempt at dialogue, no acknowledgement that there might be alternative viewpoints. Almost every tweet is another dollop of smug arrogance.
It must be nice to have so much confidence that you never have to stop and wonder if there might be something new you don't yet know.
React only got released 3 years ago. How could it be "trashed over the years"? Over what years? It barely qualifies for the plural.
I seriously wonder sometimes if javascript programmers live in dog years.
React apps haven't been in production long, we're only just entering the maintenance phase, now is exactly when we will start seeing the problems with mingling code + UI as the code gets forgotten, opened again, modified, added to and bloats.
How many years do you need to come up with a counter-argument, or adress the issues claimed for the alternatives (by the React authors and community)? Three years might not be old for a technology, but it seems like a lot of time to actually respond and flesh out this argument. If that really was the author's interest.
Not really, it took almost a decade for people to believe that splitting up PHP or ASP pages into modules and UI was easier to maintain.
HTML + CSS started in the 90s but it wasn't until the late 00s until strict CSS/HTML separation was regularly practiced.
It takes proper experience and years of work to understand why these splits are useful. And React was literally released 3 years, 2 months ago. We're not even taking into account adoption time or anything.
How quickly we forget the past I guess.
Unless we're talking in javascript years again...
EDIT: I actually forget my perspective at times. I have 10+ years experience, I saw all this for real, I worked with HTML with inline style="" tags + style tags in pages + with old-school ASP of pages with loads of inline code (yes, not ASP.Net, ASP) + PHP + VBScript + IE6 + on-element javascript + all the craziness.
It was a nightmare to find out what did what. Everything turned confusing very quickly. You never knew quite what did what.
I don't disagree with the statement about the importance of experience.
But I don't see that that point is relevant here. Here is someone who claims to have gained that experience and learned from it, and now at least gives the impression of aiming to share that knowledge. But that's not what he's doing. He's completely ignoring the fact that there have been many, many responses to the issue he's raising, and maybe he has some good refutation of those responses based on his experience and wisdom, but in that case he does not share it. It just comes off as arrogant and polemic in my opinion.
So, yes, experience takes time and is perhaps sometimes the best possible way to learn. But given that you claim to have that experience and therefore some wisdom that is relevant, then it shouldn't take three years to state that. If that is your goal.
And if it is literally impossible to formulate the experience and wisdom that you do have into something that can be communicated and taught, yes, then of course every future generation is bound to repeat the same mistakes. How could they not?
> He's completely ignoring the fact that there have been many, many responses to the issue he's raising, and maybe he has some good refutation of those responses based on his experience and wisdom, but in that case he does not share it. It just comes off as arrogant and polemic in my opinion.
I've started to get so pissed off every time I read about 'separation of concerns' whenever React is discussed. I had the same misgivings at first, but all it took was a short explanation of how 'concerns' is not necessarily about splitting html/js/css.
I've never read a single convincing argument to counter it except perhaps YAGNI, for some small projects (which even Redux-creator wrote about). It's almost always a throwaway comment about how silly front-end is these days, or an argument based on a lack of understanding of how React works.
Separating html/js/css is one of the first things many of us learned. The fact that a massive number of us are okay with React probably means something.
Mostly I'm just wondering why people bother. If you've got some serious concerns, express them. If they make sense, I'll happily change my ways and discard React. But what do you gain from essentially implying that a huge section of developers are idiots without arguing why.
Don't get me wrong, there's plenty of questionable stuff going on in front-end-land, but React has a level of mindshare so big that disagreeing demands a proper justification other than 'we always did it this way and this new thing looks a bit like the old thing we were told to avoid'.
What perhaps boggles my mind the most about this is how many seem to freak out about the fact that there's "Javascript in the render function", but they are happy to write their markup in some templating language (especially if it's server-side).
Even disregarding the discussion of which concerns exactly are supposed to be separated and why, this seems to be perfectly inconsistent to me. It's as if their rule is "there should never be markup in a .js file or <script> tag", but other logic is perfectly fine, as long as the templating language is not JS. Or maybe I'm missing something they're saying.
Thank you for this, now I finally understand front-end web development. Everything is calculated in dog years, but this fact was not documented at all!
e.g: Major Angular releases every 6 months sounds bonkers, but updates every 3.5 dog years would be satisfactory to all but the most dogged fault-finders.
> React only got released 3 years ago. How could it be "trashed over the years"? Over what years? It barely qualifies for the plural.
Yes. Three years. Plural. This has been debated for three years; that's why I said "years". Are you suggesting I should have said some other time period?
> we're only just entering the maintenance phase
Yes, I am maintaining some React code; some of it has been in maintenance mode for almost two years now. I also maintain some Backbone code, some jQuery spaghetti, a couple of Knockout projects, and an enormous MVC-ish PHP app; I've got a pretty good grip on the various ways people have written web apps over the last few years and what maintaining them is like.
> now is exactly when we will start seeing the problems with mingling code + UI
No, because there are no problems with mingling "code" and "UI" so long as all of it is presentational. What's critical is ensuring separation of concerns, which you fail to do when you mix business logic with the presentational logic.
Saying "it's all javascript so it must be related!" is how you end up with unmaintainable Backbone code. (And to be fair, you can do that with React too, but that's got nothing to do with what the screenshot was decrying. And it's actually harder to screw it up with React than Backbone, in my experience, and I have experienced both.)
Keep in mind: Many of the people who disagree with you have many, many years of experience and a deep understanding of software engineering principles and what does and does not lead to maintainable code. That doesn't mean React/JSX is perfect, but it does mean that you aren't going to get very far with snide comments. The obvious criticism of JSX is that separation of concerns is important, and the obvious defense is that JSX enables very effective separation of concerns. And that criticism and defense were first made, yes, years ago. Any further progress needs new arguments.
Ninja edit: And yes, I too have written original ASP code, and worked on "DHTML" sites, and wrote hideous inline JS to try and make rollovers work in IE6, and tried to reverse engineer the broken JS that MS Frontpage automatically injected into the pages it creates, and a bunch more besides. I too know the urge to yell at people to get off my lawn. Just because it's new doesn't mean it's always wrong though...
You very well know that "Over the years" doesn't mean "in the last year or 2".
I'm merely observing that neophiliac programmers tend to massively over-exaggerate how long things have been around. And how much experience they have in that tech.
I have never seen him as "a very smart guy". The OSS projects he have built are not that complex. But he is persistent and vocal. And yes, he really likes to troll.
And would you say the experience is pleasant? Is it a format that you would choose above all other formats? Rhetoric condensed to 140 characters and displayed in whatever order Twitter felt like showing it in?
The whole separating HTML, JS & CSS has never felt right to me. Just because it's in different files doesn't mean it's not entangled. Moving to self-contained components without any external dependencies has completely changed the way I code web.
Separating makes sense for websites with gradual improvement. You can disable JavaScript and have usable website. You can disable CSS and have usable website. Some features won't be available, it might be not that pretty, but it'll function.
Now with web applications it's not necessary makes sense to separate some concerns. Functionality, design, markup — it's all glued together, like it or not. Remove CSS and there won't be anything but bunch of pointless divs. Remove JavaScript and it'll be just a garbage.
176 comments
[ 4.4 ms ] story [ 138 ms ] threadIts like the payday loan of technical debt.
Now several years later I'm inheriting Nodejs and [flavor of the month] Javascript framework projects from coworkers that look like the PHP video sharing site I wrote in 10th grade using XAMPP.
I feel like I have (or everyone else has) contracted some sort of amnesia. Didn't we already hash this out guys?
It's fashion, like anything else.
Unfortunately I can't babysit every other team and have occasionally inherited some real abominations. Often times it has been worth spending the ~week in man hours to immediately rewrite them to avoid the constant time suck of maintaining spaghetti code down the line.
Often they are a kernel of simple functionality buried in thousands of lines of code smeared across a random assortment of files that can actually be replaced fairly simply once you've sussed out what they're actually supposed to be doing.
It is close to a view in a MVC framework than true old-school spagetti code.
But unlike a view component in an MVC framework the stateful components can update themselves automatically when data changes much more elegantly than they could in older systems.
Granted some people write React and include business logic in their components but you're not really supposed to do it that way.
If I'm working on a component level, it's already granular enough where I can easily understand the changes that need to be made and I can just update those DOM elements myself (e.g. Oh, I should add this class here and update my shopping cart total).
The DOM diffing for small components seems so... heavy handed. "Don't worry React, I got this.."
React means composable components, the browser implementation uses DOM diffing.
In your shopping cart example, say the project manager decides they want to display how may of an item you have in your cart next to the item in the catalog. Then a feature is added to remove items from any page by having a dropdown on the cart logo.
So is it the responsibility of the person writing the cart dropdown to update the catalog listing or the responsibility of the person writing the catalog listing to know about the drop-down?
In React you only need to bind to the data. If the data changes and your DOM then changes as a result then you update. You don't need to know why or how it changed.
As far as the virtual DOM being perhaps heavy handed. It is a performance optimization and not really a core concept. The React team found it was faster to update only the parts of the DOM that changed rather than redraw the entire screen and came up with a clever way to do that without having to know the implementation details of each component.
Contrast that with the naive approach (using innerHTML) which would make even a "update the character count every time a key is pressed" UI grind to a halt.
for a component, why do I need the virtual dom diffing?
React allows you to build relatively large and complicated DOM trees by composing smaller components, and it is designed so you can then (re)render the entire tree as a single operation when any relevant underlying state changes, without having to manage (re)rendering each individual component within that tree manually.
This is useful because now you only need to define one absolute way to render from a given set of underlying data. You no longer need to give a relative specification for all possible transitions from one state to another, which can be a huge reduction in complexity and edge cases if you’re working on a large, complicated UI.
However, other things being equal, rerendering your entire DOM tree on the slightest change in the underlying data would become painfully slow for any system that isn’t very small. That is partly because there are costs to regenerating the DOM tree itself, as with any template-based system. However, the tightest bottleneck in today’s browsers is usually the consequential costs that result from updating the DOM in terms of regenerating layout and so on.
The virtual DOM diffing is essentially a performance optimisation that lets you mitigate those consequential costs, because now only the parts of the DOM that actually change as a result of changes in the underlying data will lead to rerendering in the browser and the costs that incurs. In other words, virtual DOM diffing isn’t the point of React, declarative/absolute rendering is, but the former is what makes the latter fast enough to be viable.
As an aside, React’s answer to the other half of the performance problem, the cost of regenerating the entire DOM tree, is the `shouldComponentUpdate` function. That lets components, including child components deep within a large tree, perform any quick tests they can to determine whether their rendered output will actually change, and to skip the rerendering if not.
That leads on to various other ideas that have become popular in connection with React, such as using immutable data models for the underlying data. With immutable underlying data, a shallow comparison between a couple of object references that can be performed in moments acts as a “dirty check”.
However, you don’t have to use React in that way. Some people are wary of relying too much on `shouldComponentUpdate`, which inherently violates the “single source of truth” principle and risks introducing bugs if its assumptions differ from those of the same component’s `render` method. Others find the arguments for building your entire data store around immutable objects, which itself carries a hefty performance overhead, less compelling.
There are certainly other reasonable architectures you could choose for supplying the underlying data to React components and triggering rerendering when that data changes, including more traditional designs where view components observe the underlying data model in some way and trigger their own rerendering on any relevant change. Going down this path is effectively using React as a reasonably efficient and composable template rendering engine, so you can still have the advantages of absolute rendering logic, and you bypass some of the potential performance problems caused by doing large-scale rerenders with React, but in return you take back some of the responsibility to set up explicit dependencies between your view components and the data they depend on. As ever, there are trade-offs, and usually there will be multiple quite different designs that will do a decent job as long as you understand their pros and cons.
If you don't do DOM diffing for small components then you have to keep control of the whole logic state AND view state of your app.
Complete diffing allows for automatic one way bindings and easier to reason UIs.
It's like functional programming.
We should always be wary of applying skyscraper building techniques when building a house or a shed.
I honestly bet that 99.99% of people who read Hacker News could write their applications with a drop of jQuery and some basic ES6 code.
I have nothing bad to say about these frameworks, more caution that we don't apply techniques needed at scale to small scale products.
Maybe we're backtracking on the idiocy we started on around PHP times? The whole "separation of concerns" thing that went to such extremes as to become a cargo cult? I offer two observations:
- presentation is often very much content at the same time (that's why websites end up cluttered with divs that have no semantic meaning and serve no other purpose than being CSS hooks)
- separation of concerns was about not putting business code in views, not about having views without any code; you need code to drive views (and yes, template languages are Turing-complete, so they count as code too)
Now, there are standards like SOAP, etc... In the end, JSON and some clear docs for an API is usually easier to reason with than any of the boatloads of cruft that came along with XML. Not to mention the much larger transmission size.
IMO It just needs to be given some consideration before rejecting as old bloated piece of crap.
In judging whether something should be represented as element text or as attribute, ask yourself whether that something is content or metadata. In a context where this distinction doesn't make sense, markup (SGML, XML, HTML) probably doesn't make sense either.
Markup isn't and never was intended for representing arbitrary data - it is for representing text with optional markup, and is designed for end-users and content authors, not necessarily web developers.
As for representing XML in code, there was E4X which allowed you to represent XML literals in Javascript (Firefox and rhino had it a couple years ago, but it kindof wasn't convincing). Keep in mind that Javascript was invented as a language to manipulate a DOM in the first place, so there you have your canonical representation of markup in Javascript.
Sure you can represent objects, ie. a memory dump of a running program, as XML, but what's the point?
XML translates great to an object tree in many object oriented language.
Which is why it's so great to describe documents and static UIs.I agree though that it's not a great choice for a REST API.
Whether something is inside an element or is a property of said element has important semantical meaning. But not just that, with XML you can implicitly represent ordering, whitespace and type information with much less boilerplate.
So the argument for JSON is basically boils down to: "Javascript has horrible type support and doesn't support OOP. JSON models that experience better."
unless you are using some lisp-2 dialect
Writing as someone comfortably over 30, I don’t see the problem here (edit: meaning having something that looks like HTML and something that looks like JS in the same place).
If you need to generate content dynamically for a web page based on some underlying business logic and data, you need some sort of rendering logic that determines how to fill in the blanks in your generic pattern using your current specific information. This has been true for every template system and framework since forever.
Personally, I don’t much like putting the logic right there in the JSX, as the `map` does in the tweeted example. I think one of the nicer things about the way React and JSX work is that you do have the full power of JS to write your rendering logic, and you can build up a part of the rendered output separately and then compose the overall output from the individual parts without needing to put a lot of extra logic in there. But that’s just my personal preference, and others might reasonably disagree.
The challenges with building larger applications in PHP — or in JavaScript, for that matter — have more often been about not having good tools in the language to build cleanly separated, modular designs. That side of things has improved somewhat with time, and will probably always be less than ideal because of the legacy baggage these languages now carry, but in any case the big problems were never really about an artificial separation of HTML, CSS and JS, and including JSX within JS code when using React is little different to embedding conditional logic in any other template language used by any other programming language or library.
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.
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.
If you want to experiment, my advice would be to start by just using React as a template-rendering system that lets you conveniently build larger and more complex components by composing smaller and simpler ones and that can automatically change whatever is already in your DOM to whatever new DOM content you come up with when rerendering. At this stage, you can take advantage of React’s greatest strengths, but you don't need any bells and whistles like Redux or Immutable or MobX or whatever other state management libraries you’ve come across.
One thing I would recommend right from the start is storing your application state somewhere outside your React components, even if it’s just in plain JavaScript objects. When you’re ready to render a DOM tree, pass that data into the top-level React component via props. Have that top-level component in turn pass any relevant part(s) of its input data to any child component(s) that need that data for their own rendering.
Likewise, I would recommend defining the functions to handle any interesting events outside your React components. You can then pass any callbacks you might need in via props on your components as well.
If you try that sort of design out a few times with non-trivial apps, you’ll soon start to see common patterns where introducing other tools might be helpful, and at that point you’ll have a better understanding of what some of those other libraries do and which combinations of related libraries might be useful for your particular needs.
Unfortunately, the example from the tweet really does: the storage and manipulation of the to-do list itself is right there, mixed in with the rendering component. I think it’s a bad example of how to write UI code using React, because while it’s concise and it works, the techniques it shows lack flexibility and don’t scale well, and they’re not how you’d actually write a larger app’s UI that renders using React.
It's comments like these while people don't hire anyone over 30. Rather than provide thoughtful critique of the platform the response is "This looks like something I saw 20 years ago and it didn't work then so it won't work now, I'm not even going to look at it!"
Speaking as someone who is over 30... before you criticize something, understand it. For example, this code is nothing like PHP spaghetti code for reasons I listed in other comments among others I'm sure I didn't think of.
I see it very often. People like "we did this 30 years ago. I guess what is old is new again. Hahaha" But I've lived through it... like many of you... I've gone from CGI scripts written in C++ when you couldn't even guarantee a browser had Javascript to PHP, to Ruby, etc etc etc, blah blah blah. But after all that, and a Computer Science degree, I gave React an honest look and while it's not perfect. It is worth a look.
Also, having JSX in my JS is much easier to deal with than remembering some abstract DSL for how to iterate through children in a template language. It's no more goofy.
React runs on the client. It runs the logic needed on the client. And there has always been some logic required on the client, otherwise you end up refreshing the screen for every.single.validation. which is a total PITA.
Given that there's some logic running on the client, then maybe running more of it there would be a good thing. This is the principle behind SPA's after all, and they've turned out to be a Good Thing generally. Not suitable for every use case, mind. So do we then need a separate Logic Layer for logic that isn't to do with Presentation? Where do we draw that line given that the whole thing is running on the client? How do we keep the thing clean and stop bits of logic being run on random button events?
React makes perfect sense when you look at it as an answer to the problem of "how do I add logic to my presentation layer and not end up in a mess of spaghetti code?"
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 different right?? Derisive condescending comments like yours prevent the conversation from figuring out what the positive is and ultimately keep the conversation stuck in the all too common and boring whining about javascript which has infected HN.
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.
This is emphatically NOT the same as the desktop apps in the 90's.
I realized a couple months ago how incredibly similar JSX is to Cold Fusion - At least CF4. It's nearly identical in some respects.
And I've been around before PHP was a thing.
So I think I can say with some confidence that everything you have written is completely nonsense.
> It is amazing how much react resembles php and classic asp from 15 years ago.
Yes, it's amazing how it's nothing at all alike.
I have arguments against that but I'll keep them to myself because your sentence isn't really relevant to the original discussion.
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 code DESPITE the type limitations of Javascript, and when I can do it performantly and brainlessly _EVEN IN_ the slapdash "platform" of The Browser (TM), yes, this is a _huge_ step forward. Don't blame the people who decided to do something about the shittiness of Tim Berners-Lee's overly-verbose and unmaintainable HyperText Markup Language for a solution that doesn't look as pretty as Python.
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.
Nobody wants Gmail, Facebook, or Google Docs.
Seperation should be by the responsibilities a component, not by language. So the trend to components in frontend dev is right despite some unfamiliar mangling of html and js.
Very well said! I'm quoting this one.
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 business logic will be in controllers and models that don't themselves contain view/UI code.
But because an HTML like syntax was chosen to represent view hierarchy we draw a red flag because it looks like we are mixing HTML with Javascript. But that was only ever a red flag because HTML semantically was hypertext representing data and relationships.
Having tried React in earnest (and yes, I know people will have counter-anecdotes) I can say that being able to components my web application leads to more testable code, easier delegating of workload across teams (each team member only needs to know the interface of a component to use it), and better code reuse. It is beautiful (albeit busy looking).
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.
Fun fact: types, line numbers, and BS keywords like 'let' 'var' and * *&uint32, are only constructs of the language authors mind... a visualization of how he thinks. And are completely optional to a language (given a slightly more flexible parsercompiler)
I really like how it can reduce a number of tasks to less code, but it's the most common thing that trips me up when I read React or 'ESNext' codebases. It feels like ternary operators on steroids, with all advantages and disadvantages magnified.
Perhaps I just need to get used to it.
Well, once you understand a statement like this anyway:
`store => next => action => next(action);`
I mean, despite the risk of making things complicated, I use ternary operators all over the place...
To prove my point: Here's the code for the Audio Player in meta64.
https://github.com/Clay-Ferguson/meta64/blob/master/src/main...
No one can possibly argue that an HTML template for that would be easier to read, than the TypeScript I've written. I think the way meta64 uses Polymer, TypeScript, generated-HTML, etc is the ideal architecture for the modern app.
BTW: I just picked a random example of my generated code from meta64. I do agree the CSS embedded in that would be better as a CSS class. I am not arguing for dynamically created CSS, but only dynamically created HTML (i.e. no templates). My point was that if you have clean code, you can make your HTML-code-generation look almost like the HTML itself, or be 'as readable' as it would be if it were an HTML template. Readability is the key here. That's all that counts. If you can achieve that in JS/TS then it beats a template approach easy, because of its power in terms of OOP, reuse, etc, which templates are just awkward with.
(35 years experience)
Or specifically ():, I know arrow functions.
the colon refers to flow and typescripts type annotation "colon something". none-objects are lowercased
I think without the typing it would just be build = () => {
I'm not sure whether the code takes advantage of this difference in some way or not. If not, it's just a slightly more awkward and less efficient way of defining a method.
https://gist.github.com/anonymous/e506ac871c32b169ce5760de9d...
I think I still prefer the html style markup, but probably only because I am used to it.
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.
The wider context is that these components are typically built within an organised class structure enabled by ES2015, and operate within an organised component lifecycle as defined by react. Integration of logic with presentation and code into a single component makes a great deal of sense to me - all I hear are haters griping from the sidelines about how it looks like PHP.
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 by compilers and tests.
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.
Now, have I told you all about intercooler.js...
;-)
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.
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.
I'm pretty happy with how React/Redux works compared to what came before... separating file structure by directories of features, and components/actions/reducers that represent them is much easier than looking in one spot for all my view templates with a goofy DSL abstraction, and another directory for the actual event binding.
If you're building a static website, sure, you probably don't need React - the old tools and techniques handle that use case well. But if you're building a webapp, something with complex, dynamic client-side behaviour, it doesn't make sense to pretend that CSS, HTML and JS aren't already heavily coupled by the nature of what you're building. React just embraces that idea, rather than pretending it doesn't exist.
The reality of modern apps is that JS is going to transform your HTML and CSS at runtime, and most of the bugs you'll end up tracking down will be related to it being transformed in ways you weren't expecting. React's component model and declarative rendering are far more effective at addressing this problem than any other tool I've tried.
So much effort has been done with React to work with the broader JS community and its' direction as opposed to against it. ES6 class syntax, simple render function components, modules. React doesn't need much to get started, and it's unprescripted enough that just a few tools can round it out, with heavier and lighter options.
I don't want to go back, and frankly, I'd rather have JSX in my JS than go back to weird template DSLs ever again.
We didn't. And React doesn't change that either. React components are not logic code, they are UI code, and that has always went with view concerns (loop this times, show this button or that button depending on state, etc).
In the Desktop GUI space, where they don't have our HTML madness, do you think their UI components are not using code? Buttons, drop-downs, etc are not appearing by magic, they are created by code that does things like: draw a line of x length and y color, then another perpendicular to that, etc, then loop and draw some stripes, etc. That's the case even in Smalltalk, where MVC was invented. That still matches with "separation of concerns" -- which is about not mixing your BUSINESS logic with your UI code, not about not having code in your UI rendering.
In fact, compared to the classical way (foreach and other kinds of template instructions embedded in template strings, from PHP's Twig to Angular) it's even cleaner, because even though JSX looks like HTML it's actually compiled to Javascript instructions it's not just some ad-hoc language hidden in template tags to be interpreted at runtime.
And separation of concerns also applies to UI elements (encapsulation, re-use, etc) something which "logic free" templates like Mustache and so also miss (or, well, make harder -- of course if you try hard enough you can always fit a square peg in a round hole).
You can also bundle it to generate distributable desktop applications (e.g. Visual Studio Code, Atom, or the desktop Slack client).
I can't comprehend the very idea of "template languages". Especially in PHP, because PHP itself is a decent template language by design. But even outside - they always evolve the same. They start as a "lightweight" way to avoid putting code into view templates, but then they slowly accrue conditionals, loops, local variables, half-assed tools for defining functions, and before you know, your "no code allowed" template language becomes a Turing-complete and pretty crappy replication of PHP.
And all of that is orthogonal to the main insanity of this whole era - stitching HTML from strings. HTML is a structured tree format, and should be built out as a tree. Gluing strings together is the source of oh so many errors and security vulnerabilities...
Personally, I liked the CL-WHO approach - http://weitz.de/cl-who/.
The question ofcourse is: why would people rather use:
instead of: And I think this goes deep. People are looking for more human ways to express themselves. And PHP is not a very beautiful language. So maybe my first example looks more 'human' than the PHP example.I don't have an opinion on this "more human way" to express oneself, but it seems that it would connect this case with the reason people seem to prefer curly braces to parenthesis in code too.
Escaping-as-default helps, but people sometimes forget escaping is a function of output context. For example,
is a potential vulnerability if the default escaping mechanism for {bar} is one meant for HTML.http://stampte.com/
- Model is props/state.
- View is render().
- Controller is everything else (lifecycle, handlers, etc.)
IMHO it's also best-practice to separate view from presentation using CSS modules for component-level styles, and sprinkling namespaced classes here and there so that the component can be styled externally using application-level CSS.
We didn't get the separation of concerns wrong. React is the same we've been doing for 15 years, but we finally understood we had to modularize and encapsulate it to encourage reusability and true separation of concerns.
I'm never going back to traditional code that violates the single-responsibility principle. I'm never going back to manual DOM mutation. Give me modular, namespaced, declarative HTML+CSS+JS and I'll stop using React.
Well, we had - the whole "separate content from presentation" thing was a cargo cult. Before the recent wave of JS frameworks, the standard website was littered with tons of div elements, almost all of which had zero semantic meaning, and existed only as CSS hooks and/or a hipster replacement for tables. And it was like nobody stopped to ask if all those divs aren't breaking the "separation of concerns" rule - or even if the rule made sense in the first place (it didn't; "presentation" often delivers as much information as "content" itself).
I don't know of any other industry so blinded by fads than web development.
Meanwhile, when you need to go edit the logic operating on some element later, you end up grepping through your code base for ids, classnames, element types, whatever, trying to figure out where that bit of code that operates on that element got to, often several directories in the file structure away from the markup.
Hardly something that can be described as quality software engineering.
What matters is how this happens, and there's a huge difference between React's approach and '<div class="whoops"><?php echo $some_unescaped_dangerous_thing ?></div>'
If you look at what the racket team has done for their documentation system "scribble", it is pretty clear that we can engineer whatever modularity we require for the purpose at hand given that generality.
Well, yeah. Forgive me, because I never know, here, if I am talking to my grand-son or my grand-pa, but "Separation of concerns", as an idea, came up when we thought that HTML/JS/CSS was about describing web-sites, for, for example, the NYT vs the WSJ, not for an applet or Swing replacement.
Separating content (including, maybe, semantics too) from presentation (branding, look&feel) makes sense when you are talking about web-pages. I don't even know how the idea transmogrified into a point-of-contention on SPAs.
It's quite funny when you think about it: "Look, Ma! I can build a fully functioning GUI out of type-setting elements and sticks!"
...but I agree with many of these comments; I thought it was odd (to be charitable) but after using it find it to be quite nice. Redux is what I see over used (imo) and at times almost an antipattern
My application contains a single index.html with entry point to my js bundle, empty body tag and no css.
Everything is loaded as needed, encapsulated as modules. The simplicity is just amazing .
The way I think about it is react like thinking offers me the most semantic compression in my code.
(I use webpack because it now supports tree-shaking)
He knows that what he's said has been said a thousand times before, and he knows that every time it's said a bunch of people will reply with "separation of concerns, not seperation of technology", and he knows that's a very valid counterargument which can't be refuted in a tweet, which means he also knows how pointless this is. Which in turn means that he's not doing this to start a discussion, but just to get a rise out of people. Giving him the benefit of the doubt, he might actually have an interesting point to add to the debate...but we'll never know, since he thinks a better use of his time is trolling React developers than actually making his case for...whatever it might be.
One of the tweets in reply to him hit the nail on the head: https://twitter.com/chrisbarless/status/810918115601158145
Sad.
Edit: Scroll through Fuchs' twitter feed right now; he's basically just non-stop trolling. "This is why we can’t have nice things" "Q: What is React? A: It’s PHP, but on the client." "I can see how react is awesome if you build todo apps that do nothing. :)" Then when noting how a million people are disagreeing with him: "I think that means that I’m on to something." No attempt at dialogue, no acknowledgement that there might be alternative viewpoints. Almost every tweet is another dollop of smug arrogance.
It must be nice to have so much confidence that you never have to stop and wonder if there might be something new you don't yet know.
So often a phrase like this is repeated on HN.
React only got released 3 years ago. How could it be "trashed over the years"? Over what years? It barely qualifies for the plural.
I seriously wonder sometimes if javascript programmers live in dog years.
React apps haven't been in production long, we're only just entering the maintenance phase, now is exactly when we will start seeing the problems with mingling code + UI as the code gets forgotten, opened again, modified, added to and bloats.
HTML + CSS started in the 90s but it wasn't until the late 00s until strict CSS/HTML separation was regularly practiced.
It takes proper experience and years of work to understand why these splits are useful. And React was literally released 3 years, 2 months ago. We're not even taking into account adoption time or anything.
How quickly we forget the past I guess.
Unless we're talking in javascript years again...
EDIT: I actually forget my perspective at times. I have 10+ years experience, I saw all this for real, I worked with HTML with inline style="" tags + style tags in pages + with old-school ASP of pages with loads of inline code (yes, not ASP.Net, ASP) + PHP + VBScript + IE6 + on-element javascript + all the craziness.
It was a nightmare to find out what did what. Everything turned confusing very quickly. You never knew quite what did what.
But I don't see that that point is relevant here. Here is someone who claims to have gained that experience and learned from it, and now at least gives the impression of aiming to share that knowledge. But that's not what he's doing. He's completely ignoring the fact that there have been many, many responses to the issue he's raising, and maybe he has some good refutation of those responses based on his experience and wisdom, but in that case he does not share it. It just comes off as arrogant and polemic in my opinion.
So, yes, experience takes time and is perhaps sometimes the best possible way to learn. But given that you claim to have that experience and therefore some wisdom that is relevant, then it shouldn't take three years to state that. If that is your goal.
And if it is literally impossible to formulate the experience and wisdom that you do have into something that can be communicated and taught, yes, then of course every future generation is bound to repeat the same mistakes. How could they not?
I've started to get so pissed off every time I read about 'separation of concerns' whenever React is discussed. I had the same misgivings at first, but all it took was a short explanation of how 'concerns' is not necessarily about splitting html/js/css.
I've never read a single convincing argument to counter it except perhaps YAGNI, for some small projects (which even Redux-creator wrote about). It's almost always a throwaway comment about how silly front-end is these days, or an argument based on a lack of understanding of how React works.
Separating html/js/css is one of the first things many of us learned. The fact that a massive number of us are okay with React probably means something.
Mostly I'm just wondering why people bother. If you've got some serious concerns, express them. If they make sense, I'll happily change my ways and discard React. But what do you gain from essentially implying that a huge section of developers are idiots without arguing why.
Don't get me wrong, there's plenty of questionable stuff going on in front-end-land, but React has a level of mindshare so big that disagreeing demands a proper justification other than 'we always did it this way and this new thing looks a bit like the old thing we were told to avoid'.
Even disregarding the discussion of which concerns exactly are supposed to be separated and why, this seems to be perfectly inconsistent to me. It's as if their rule is "there should never be markup in a .js file or <script> tag", but other logic is perfectly fine, as long as the templating language is not JS. Or maybe I'm missing something they're saying.
e.g: Major Angular releases every 6 months sounds bonkers, but updates every 3.5 dog years would be satisfactory to all but the most dogged fault-finders.
Yes. Three years. Plural. This has been debated for three years; that's why I said "years". Are you suggesting I should have said some other time period?
> we're only just entering the maintenance phase
Yes, I am maintaining some React code; some of it has been in maintenance mode for almost two years now. I also maintain some Backbone code, some jQuery spaghetti, a couple of Knockout projects, and an enormous MVC-ish PHP app; I've got a pretty good grip on the various ways people have written web apps over the last few years and what maintaining them is like.
> now is exactly when we will start seeing the problems with mingling code + UI
No, because there are no problems with mingling "code" and "UI" so long as all of it is presentational. What's critical is ensuring separation of concerns, which you fail to do when you mix business logic with the presentational logic.
Saying "it's all javascript so it must be related!" is how you end up with unmaintainable Backbone code. (And to be fair, you can do that with React too, but that's got nothing to do with what the screenshot was decrying. And it's actually harder to screw it up with React than Backbone, in my experience, and I have experienced both.)
Keep in mind: Many of the people who disagree with you have many, many years of experience and a deep understanding of software engineering principles and what does and does not lead to maintainable code. That doesn't mean React/JSX is perfect, but it does mean that you aren't going to get very far with snide comments. The obvious criticism of JSX is that separation of concerns is important, and the obvious defense is that JSX enables very effective separation of concerns. And that criticism and defense were first made, yes, years ago. Any further progress needs new arguments.
Ninja edit: And yes, I too have written original ASP code, and worked on "DHTML" sites, and wrote hideous inline JS to try and make rollovers work in IE6, and tried to reverse engineer the broken JS that MS Frontpage automatically injected into the pages it creates, and a bunch more besides. I too know the urge to yell at people to get off my lawn. Just because it's new doesn't mean it's always wrong though...
I'm merely observing that neophiliac programmers tend to massively over-exaggerate how long things have been around. And how much experience they have in that tech.
To be fair, there has never been any effective dialogue on Twitter. 140 characters and out-of-context replies make it impossible.
Now with web applications it's not necessary makes sense to separate some concerns. Functionality, design, markup — it's all glued together, like it or not. Remove CSS and there won't be anything but bunch of pointless divs. Remove JavaScript and it'll be just a garbage.