7 ms·

He has a nice follow up which gets to the reasons why https://tonsky.me/blog/good-times-weak-men/ https://tonsky.me/blog/good-times-weak-men/ Another take: re

He has a nice follow up which gets to the reasons why https://tonsky.me/blog/good-times-weak-men/ https://tonsky.me/blog/good-times-weak-men/ Another take: rewrites and rehashes tend to be bad because they are not exciting for programmers. Everything you re about to write is predictable, nothing looks Clearly better and it just feels forced. First versions of anything are exciting, the possibilities are endless, and even if the choices along the path are suboptimal, they are willing to make it work right.

pm90 7y ago
Rewrites can be really amazing if you incentivize it that way. Its really important to have a solid reason for doing a rewrite though. But if there are good reasons, the problem of 0 (or < x) downtime migrations is an opportunity to do some solid engineering work. Anecdotally, a lot of rewrites happen for the wrong reasons, usually NIH or churn. The key to a good rewrite is understanding the current system really well, without that its very hard to work with it let alone replace it.
jiofih 7y ago
He hints at Electron in the end, but I think the real blame lies on React which has become standard in the past five years. Nobody has any fucking idea what’s going on in their react projects. I work with incredibly bright people and not a single one can explain accurately what happens when you press a button. On the way to solving UI consistency it actually made it impossible for anyone to reason about what’s happening on the screen, and bugs like the ones shown simply pop up in random places, due to the complete lack of visibility into the system. No, the debug tooling is not enough. I’m really looking forward to whatever next thing becomes popular and replaces this shit show.
- mynegation 7y ago
  What is better? Jquery? It comes with its own can of worms and React designers had solid reasoning to migrate away from immediate DOM modification. In general UI is hard. Nice features like compositing, variable width fonts, reflow etc come with the underlying mechanisms that are pretty complicated and once something behaves different to the expectations it might be hard to understand why.
  - buzzkillington 7y ago
    UI is hard because you're using a hyper text language with fewer features than were the standard in the 60s. Then with styling on top of that, then with a scripting language on top of that. Reading Computer Lib/Dream Machine over the holidays and I wonder where it all went so wrong.
    - somatic 7y ago
      Free markets hate good software. "Good" meaning secure, stable, and boring. On both ends. Software developers hate boring software for pragmatic HR-driven career reasons and because devs are apes and apes are faddish and like the shiny new thing. And commercial hegemony tends to go to the companies that slap something together with duct tape and bubble gum and rush it out the door. So you get clusterfucks like Unix winning out against elegantly designed Lisp systems, and clusterfucks like Linux winning out against elegantly designed Unix systems, and clusterfucks like Docker and microservices and whatever other "innovations" "winning out" over elegantly design Linux package management and normal webservers and whatnot. At some point someone important will figure out that no software should ever need to be updated for any reason ever, and a software update should carry the same stigma as...I don't know...adultery once carried. Or an oil spill. Or cooking the books. Whatever. But then also it's important to be realistic. If anyone ever goes back and fixes any of this, well, a whole lot of very smart people are going to go unemployed. Speaking of which... https://www-users.cs.york.ac.uk/susan/joke/cpp.htm https://www-users.cs.york.ac.uk/susan/joke/cpp.htm
      - kazinator 7y ago
        Free markets hate unchanging software. Software churn generates activity and revenue, and the basic goal of the game is to be the one controlling the change. Change is good when you have your hands on the knobs and levers, bad when someone else does. Organizations try to steer their users away from having dependencies on changes that they don't control. "You're still using some of XYZ Corp's tools along with ABC's suite? In the upcoming release, ABC we will help you drop that XYZ stuff ..."
      - 7y ago
- vsareto 7y ago
  >I’m really looking forward to whatever next thing becomes popular and replaces this shit show. I'm with you, but motivation to really learn a system tanks when there's something else on the horizon. And what happens when new-thing appears really great for the first 1-2 years, but goes downhill and we're back to asking for its replacement only 5 years after its release? That tells me we're still chasing 'new', but instead of a positive 'new', it's a negative one. This was also reinforced constantly by people claiming you'll be unemployable if you aren't riding the 'new' wave or doing X amount of things in your spare time. It's a natural consequence of an industry that moves quickly. If we want a more stable bedrock, we MUST slow down.
- TeMPOraL 7y ago
  I think my favourite fact(oid) to point out here would be that the React model is essentially the same thing as the good ol' Windows GUI model. The good ol' 1980s Windows, though perhaps slightly more convenient for developers. See [0]. I think it's good to keep that in mind as a reference point. -- https://www.bitquabit.com/post/the-more-things-change/ https://www.bitquabit.com/post/the-more-things-change/
  - buboard 7y ago
    if webdev is going to go through all the iterations of GUI development ... oh boy , there are decades of frameworks ahead
    - ratww 7y ago
      It's just the underlying model that is similar, but React is pretty good at abstracting all that (unlike Win32). When it comes to developer experience I'd say that React and company are ahead of most desktop UI technologies, and has inspired others (Flutter, SwiftUI).
      - goatlover 7y ago
        So where's the RAD React tooling? Is that a thing yet?
        ratww 7y ago
        Apparently there's React Studio, BuilderX and tools like Sketch2React and Figma to React. Ionic Studio will probably support React in a close future (maybe it already supports).
- ipodopt 7y ago
  Flutter is a very good bet IMO. It uses Dart was designed from the ground up to be a solid front end language instead of building on top of JS. The underlying architecture of flutter is clearly articulated and error messages are informative. Still seems a bit slow and bloated in some aspects but it is getting better every day and I think their top down control of the stack is going to let them trim it all the way down.
- systematical 7y ago
  Yes both appear to be a disaster. Vuejs is a bit better imo but i'm generally holding out for the next thing.
  - cutler 7y ago
    ... which is https://svelte.dev https://svelte.dev
    - zbentley 7y ago
      It might be the next big thing, but Svelte doesn't solve the problem outlined in the root of this subthread: nobody has any idea what the fuck is going on. I like Svelte, the simplicity of programming in it is great, and it has several advantages compared to React. But I have no idea how it works, past a point of complexity. Like, yes: I can run the compiler and check out the JS it generates, same as I can do in React. For simple components, sometimes the compiled code even makes sense. But when I introduce repeated state mutations or components that reference each other, I no longer know what's going on at all, and I don't think I'm alone in this. Svelte might be an improvement in ergonomics (and that's a good and much needed thing!) but it does nothing to answer the obscurity/too-far-up-the-abstraction-stack-itis that GP mentioned. The whole point of that is frameworks/abstraction layers that tell you "you don't need to understand what's going on below here" are . . . maybe not lying, exactly, but also not telling the whole truth about the costs of operating at that level of both tooling abstraction and developer comprehension.
    - JMTQp8lwXL 7y ago
      More likely to be web components. Then you can use your web components in Svelte, React, Angular, Vue, etc projects.
- jeffmcmahan 7y ago
  I completely agree, here. React has replaced the DOM, and it's pretty fast, pretty efficient when you understand its limitations... but when you start rendering to the canvas or creating SVG animation from within react code, everything is utterly destroyed. Performance is 1/1000 of what the platform provides. I have completely stopped using frameworks in my day-to-day, and moved my company to a simple pattern for updatable, optionally stateful DOM elements. Definitely some headaches, some verbosity, and so forth. But zero tool chain and much better performance, and the performance will improve, month-by-month, forever.
  - Aeolun 7y ago
    It seems to me that using your react components to render SVG animations, or to canvas, is just inviting disaster.
    - jeffmcmahan 7y ago
      Well yeah. But I've seen it done; the attitude being "this is fine, React is fast, it works on my Mac..."
  - swah 7y ago
    Can you expand? You actually convinced other folks to stop using React and go back to writing DOM-manipulating VanillaJS?
    - jeffmcmahan 7y ago
      No one's going back to the messy spaghetti-generating "just-jQuery" pattern of yore. I devised a way of using plain closures to create DOM nodes and express how the nodes and their descendants should change when the model changes. So a component is a function that creates a node and returns a function not unlike a ReactComponent#render() method: props => newNodeState When called, that function returns an object describing the new state of the node. Roughly: { node, className: 'foo', childNodes: [ childComponent(props) ] } So, it's organized exactly like a react app. A simple reconciliation function (~100 lines) applies a state description to the topmost node and then iterates recursively through childNodes. A DOM node is touched if and only if its previous state object differs from its current state object - no fancy tree diffing. And we don't have to fake events or any of that; everything is just the native platform. I implemented an in-browser code editor this way. Syntax highlighting, bracket matching, soft wrap, sophisticated selection, copy/cut/paste, basic linting, code hints, all of it... It edits huge files with no hint of delay as you type, select, &c. It was a thorough test of the approach. Also, when we animate something, we can hook right in to the way reconciliation works and pass control of the update to the component itself, to execute its own transition states and then pass control back to the reconcile function... This has made some really beautiful things possible. Fine grained control over everything - timing, order, &c. - but only when you want it. Sorry for the wall of text.
- tndl 7y ago
  This a thousand times. It's amazing how each new layer of abstraction becomes the smallest unit of understanding you can work with. Browser APIs were the foundation for a while, then DOM manipulation libs like jquery, and now full blown view libraries and frameworks like react and angular. I wrote a little bit more about my thoughts on the problem here: https://blog.usejournal.com/you-probably-shouldt-be-using-react-2f45ca487c8e?source=friends_link&sk=b88d7e3f0c715965bbc859b5ce8053e1 https://blog.usejournal.com/you-probably-shouldt-be-using-re...
- ramraj07 7y ago
  If someone's starting a new website project (that has potential to become quite complex), what would you recommend is the best frontend technology to adapt then?
- deleted 7y ago
  [deleted]
- JMTQp8lwXL 7y ago
  This doesn't seem unique to React projects. Can anyone explain what is happening under the hood in their Angular projects? How about Vue? It seems to be a failing of all major UI frameworks, lots of complexity is abstracted away.
- machiaweliczny 7y ago
  React is super simple - I could implement same API from memory so I don't think it's the root of the problem. > Nobody Speak for yourself
  - tsukurimashou 7y ago
    never used React but my guess is, it is pretty simple to use, but most people using it don't know what happens behind the scenes (which is not specific to React but more like an issue for any framework that tries to do everything)
  - jiofih 7y ago
    I take it you’re thinking of virtual DOM only, which is not the problem, or the component class which hides all of the details. React is huge, it’s unlikely you’ll implement the synthetic events, lifecycle hooks, bottom up updates, context, hooks with their magical stacks, rendering “optimizations” and all of react-specific warts. There are simple reimplementations like hyperapp and preact and I completely recommend using those instead. I really meant React the library and ecosystem are at fault, not the general model.
originalvichy 7y ago
Time is money and engineers aren't given time to properly finish developing software before releases. Add to this the modern way of being able to hotfix or update features and you will set an even lower bar for working software. The reason an iPod didn't release with a broken music player is that back then forcing users to just update their app/OS was too big an ask. You shipped complete products. Now a company like Apple even prides itself by releasing phone hardware with missing software features: Deep Fusion released months after the newest iPhone was released. Software delivery became faster and it is being abused. It is not only being used to ship fixes and complete new features, but it is being used to ship incomplete software that will be fixed later. As a final sidenote while I'm whining about Apple: as a consultant in the devops field with an emphasis on CI/CD, the relative difficulty of using macOS in a CI/CD pipeline makes me believe that Apple has a terrible time testing its software. This is pure speculation based on how my experience. A pure Apple shop has probably solved many of the problems and hiccups we might run into, but that's why I used the term "relatively difficult".
TeMPOraL 7y ago
Yet somehow, it seems to me that most software - including all the "innovative" hot companies - are mostly rewriting what came before, just in a different tech stack. So how come nobody wants to rewrite the prior art to be faster than it was before?

pm90 7y ago

Rewrites can be really amazing if you incentivize it that way. Its really important to have a solid reason for doing a rewrite though. But if there are good reasons, the problem of 0 (or < x) downtime migrations is an opportunity to do some solid engineering work. Anecdotally, a lot of rewrites happen for the wrong reasons, usually NIH or churn. The key to a good rewrite is understanding the current system really well, without that its very hard to work with it let alone replace it.

jiofih 7y ago

He hints at Electron in the end, but I think the real blame lies on React which has become standard in the past five years. Nobody has any fucking idea what’s going on in their react projects. I work with incredibly bright people and not a single one can explain accurately what happens when you press a button. On the way to solving UI consistency it actually made it impossible for anyone to reason about what’s happening on the screen, and bugs like the ones shown simply pop up in random places, due to the complete lack of visibility into the system. No, the debug tooling is not enough. I’m really looking forward to whatever next thing becomes popular and replaces this shit show.

mynegation 7y ago
What is better? Jquery? It comes with its own can of worms and React designers had solid reasoning to migrate away from immediate DOM modification. In general UI is hard. Nice features like compositing, variable width fonts, reflow etc come with the underlying mechanisms that are pretty complicated and once something behaves different to the expectations it might be hard to understand why.
- buzzkillington 7y ago
  UI is hard because you're using a hyper text language with fewer features than were the standard in the 60s. Then with styling on top of that, then with a scripting language on top of that. Reading Computer Lib/Dream Machine over the holidays and I wonder where it all went so wrong.
  - somatic 7y ago
    Free markets hate good software. "Good" meaning secure, stable, and boring. On both ends. Software developers hate boring software for pragmatic HR-driven career reasons and because devs are apes and apes are faddish and like the shiny new thing. And commercial hegemony tends to go to the companies that slap something together with duct tape and bubble gum and rush it out the door. So you get clusterfucks like Unix winning out against elegantly designed Lisp systems, and clusterfucks like Linux winning out against elegantly designed Unix systems, and clusterfucks like Docker and microservices and whatever other "innovations" "winning out" over elegantly design Linux package management and normal webservers and whatnot. At some point someone important will figure out that no software should ever need to be updated for any reason ever, and a software update should carry the same stigma as...I don't know...adultery once carried. Or an oil spill. Or cooking the books. Whatever. But then also it's important to be realistic. If anyone ever goes back and fixes any of this, well, a whole lot of very smart people are going to go unemployed. Speaking of which... https://www-users.cs.york.ac.uk/susan/joke/cpp.htm https://www-users.cs.york.ac.uk/susan/joke/cpp.htm
    - kazinator 7y ago
      Free markets hate unchanging software. Software churn generates activity and revenue, and the basic goal of the game is to be the one controlling the change. Change is good when you have your hands on the knobs and levers, bad when someone else does. Organizations try to steer their users away from having dependencies on changes that they don't control. "You're still using some of XYZ Corp's tools along with ABC's suite? In the upcoming release, ABC we will help you drop that XYZ stuff ..."
    - 7y ago
vsareto 7y ago
>I’m really looking forward to whatever next thing becomes popular and replaces this shit show. I'm with you, but motivation to really learn a system tanks when there's something else on the horizon. And what happens when new-thing appears really great for the first 1-2 years, but goes downhill and we're back to asking for its replacement only 5 years after its release? That tells me we're still chasing 'new', but instead of a positive 'new', it's a negative one. This was also reinforced constantly by people claiming you'll be unemployable if you aren't riding the 'new' wave or doing X amount of things in your spare time. It's a natural consequence of an industry that moves quickly. If we want a more stable bedrock, we MUST slow down.
TeMPOraL 7y ago
I think my favourite fact(oid) to point out here would be that the React model is essentially the same thing as the good ol' Windows GUI model. The good ol' 1980s Windows, though perhaps slightly more convenient for developers. See [0]. I think it's good to keep that in mind as a reference point. -- https://www.bitquabit.com/post/the-more-things-change/ https://www.bitquabit.com/post/the-more-things-change/
- buboard 7y ago
  if webdev is going to go through all the iterations of GUI development ... oh boy , there are decades of frameworks ahead
  - ratww 7y ago
    It's just the underlying model that is similar, but React is pretty good at abstracting all that (unlike Win32). When it comes to developer experience I'd say that React and company are ahead of most desktop UI technologies, and has inspired others (Flutter, SwiftUI).
    - goatlover 7y ago
      So where's the RAD React tooling? Is that a thing yet?
      - ratww 7y ago
        Apparently there's React Studio, BuilderX and tools like Sketch2React and Figma to React. Ionic Studio will probably support React in a close future (maybe it already supports).
ipodopt 7y ago
Flutter is a very good bet IMO. It uses Dart was designed from the ground up to be a solid front end language instead of building on top of JS. The underlying architecture of flutter is clearly articulated and error messages are informative. Still seems a bit slow and bloated in some aspects but it is getting better every day and I think their top down control of the stack is going to let them trim it all the way down.
systematical 7y ago
Yes both appear to be a disaster. Vuejs is a bit better imo but i'm generally holding out for the next thing.
- cutler 7y ago
  ... which is https://svelte.dev https://svelte.dev
  - zbentley 7y ago
    It might be the next big thing, but Svelte doesn't solve the problem outlined in the root of this subthread: nobody has any idea what the fuck is going on. I like Svelte, the simplicity of programming in it is great, and it has several advantages compared to React. But I have no idea how it works, past a point of complexity. Like, yes: I can run the compiler and check out the JS it generates, same as I can do in React. For simple components, sometimes the compiled code even makes sense. But when I introduce repeated state mutations or components that reference each other, I no longer know what's going on at all, and I don't think I'm alone in this. Svelte might be an improvement in ergonomics (and that's a good and much needed thing!) but it does nothing to answer the obscurity/too-far-up-the-abstraction-stack-itis that GP mentioned. The whole point of that is frameworks/abstraction layers that tell you "you don't need to understand what's going on below here" are . . . maybe not lying, exactly, but also not telling the whole truth about the costs of operating at that level of both tooling abstraction and developer comprehension.
  - JMTQp8lwXL 7y ago
    More likely to be web components. Then you can use your web components in Svelte, React, Angular, Vue, etc projects.
jeffmcmahan 7y ago
I completely agree, here. React has replaced the DOM, and it's pretty fast, pretty efficient when you understand its limitations... but when you start rendering to the canvas or creating SVG animation from within react code, everything is utterly destroyed. Performance is 1/1000 of what the platform provides. I have completely stopped using frameworks in my day-to-day, and moved my company to a simple pattern for updatable, optionally stateful DOM elements. Definitely some headaches, some verbosity, and so forth. But zero tool chain and much better performance, and the performance will improve, month-by-month, forever.
- Aeolun 7y ago
  It seems to me that using your react components to render SVG animations, or to canvas, is just inviting disaster.
  - jeffmcmahan 7y ago
    Well yeah. But I've seen it done; the attitude being "this is fine, React is fast, it works on my Mac..."
- swah 7y ago
  Can you expand? You actually convinced other folks to stop using React and go back to writing DOM-manipulating VanillaJS?
  - jeffmcmahan 7y ago
    No one's going back to the messy spaghetti-generating "just-jQuery" pattern of yore. I devised a way of using plain closures to create DOM nodes and express how the nodes and their descendants should change when the model changes. So a component is a function that creates a node and returns a function not unlike a ReactComponent#render() method: props => newNodeState When called, that function returns an object describing the new state of the node. Roughly: { node, className: 'foo', childNodes: [ childComponent(props) ] } So, it's organized exactly like a react app. A simple reconciliation function (~100 lines) applies a state description to the topmost node and then iterates recursively through childNodes. A DOM node is touched if and only if its previous state object differs from its current state object - no fancy tree diffing. And we don't have to fake events or any of that; everything is just the native platform. I implemented an in-browser code editor this way. Syntax highlighting, bracket matching, soft wrap, sophisticated selection, copy/cut/paste, basic linting, code hints, all of it... It edits huge files with no hint of delay as you type, select, &c. It was a thorough test of the approach. Also, when we animate something, we can hook right in to the way reconciliation works and pass control of the update to the component itself, to execute its own transition states and then pass control back to the reconcile function... This has made some really beautiful things possible. Fine grained control over everything - timing, order, &c. - but only when you want it. Sorry for the wall of text.
tndl 7y ago
This a thousand times. It's amazing how each new layer of abstraction becomes the smallest unit of understanding you can work with. Browser APIs were the foundation for a while, then DOM manipulation libs like jquery, and now full blown view libraries and frameworks like react and angular. I wrote a little bit more about my thoughts on the problem here: https://blog.usejournal.com/you-probably-shouldt-be-using-react-2f45ca487c8e?source=friends_link&sk=b88d7e3f0c715965bbc859b5ce8053e1 https://blog.usejournal.com/you-probably-shouldt-be-using-re...
ramraj07 7y ago
If someone's starting a new website project (that has potential to become quite complex), what would you recommend is the best frontend technology to adapt then?
deleted 7y ago
[deleted]
JMTQp8lwXL 7y ago
This doesn't seem unique to React projects. Can anyone explain what is happening under the hood in their Angular projects? How about Vue? It seems to be a failing of all major UI frameworks, lots of complexity is abstracted away.
machiaweliczny 7y ago
React is super simple - I could implement same API from memory so I don't think it's the root of the problem. > Nobody Speak for yourself
- tsukurimashou 7y ago
  never used React but my guess is, it is pretty simple to use, but most people using it don't know what happens behind the scenes (which is not specific to React but more like an issue for any framework that tries to do everything)
- jiofih 7y ago
  I take it you’re thinking of virtual DOM only, which is not the problem, or the component class which hides all of the details. React is huge, it’s unlikely you’ll implement the synthetic events, lifecycle hooks, bottom up updates, context, hooks with their magical stacks, rendering “optimizations” and all of react-specific warts. There are simple reimplementations like hyperapp and preact and I completely recommend using those instead. I really meant React the library and ecosystem are at fault, not the general model.

originalvichy 7y ago

Time is money and engineers aren't given time to properly finish developing software before releases. Add to this the modern way of being able to hotfix or update features and you will set an even lower bar for working software. The reason an iPod didn't release with a broken music player is that back then forcing users to just update their app/OS was too big an ask. You shipped complete products. Now a company like Apple even prides itself by releasing phone hardware with missing software features: Deep Fusion released months after the newest iPhone was released. Software delivery became faster and it is being abused. It is not only being used to ship fixes and complete new features, but it is being used to ship incomplete software that will be fixed later. As a final sidenote while I'm whining about Apple: as a consultant in the devops field with an emphasis on CI/CD, the relative difficulty of using macOS in a CI/CD pipeline makes me believe that Apple has a terrible time testing its software. This is pure speculation based on how my experience. A pure Apple shop has probably solved many of the problems and hiccups we might run into, but that's why I used the term "relatively difficult".

TeMPOraL 7y ago

Yet somehow, it seems to me that most software - including all the "innovative" hot companies - are mostly rewriting what came before, just in a different tech stack. So how come nobody wants to rewrite the prior art to be faster than it was before?