5 ms·

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

by quasse 10y ago

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?

SomeStupidPoint 10y ago
Ah, you think technical design is governed by technical concerns. It's fashion, like anything else.
- quasse 10y ago
  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.
  - deleted 10y ago
    [deleted]
throwaway2016a 10y ago
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.
- aantix 10y ago
  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.."
  - Chris_Newton 10y ago
    (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.
TeMPOraL 10y ago
> 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)

by quasse 10y ago

SomeStupidPoint 10y ago

Ah, you think technical design is governed by technical concerns. It's fashion, like anything else.

quasse 10y ago
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.
- deleted 10y ago
  [deleted]

throwaway2016a 10y ago

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.

aantix 10y ago
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.."
- Chris_Newton 10y ago
  (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.

TeMPOraL 10y ago

> 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)