11–20 of 177 posts
It is amazing how much react resembles php and classic asp from 15 years ago. I guess that's what happens when you don't hire anyone over 30.
Earlier quoted context omitted.
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 s…
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 m…
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.."
Earlier quoted context omitted.
Ah, you think technical design is governed by technical concerns. It's fashion, like anything else.
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 c…
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.
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).
It is amazing how much react resembles php and classic asp from 15 years ago. I guess that's what happens when you don't hire anyone over 30.
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.
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.
Earlier quoted context omitted.
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 m…
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 t…
React means composable components, the browser implementation uses DOM diffing.
Earlier quoted context omitted.
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 m…
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 t…
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.