7 ms·

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

by 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 ..."
    - Nasrudith 7y ago
      That brings to mind one common computer scientest fallacy - that elegence is an end to itself. It may share some properties which make it practical but unfortunately it is not in practice. Recursive solutions are more elegant but you still use a stack and while loop to not smash the stack.
      - somatic 7y ago
        Scheme is properly tail-recursive and has been around since 1975. Most (all?) Common Lisp implementations have proper tail recursion. Clojure has tail call optimization for simple cases and only if you explicitly ask for it, but it gets you most of the way there most of the time. So there are reasons to prefer more imperative languages and their systems, but stack-smashing isn't one of them.
- somatic 7y ago
  jQuery: 88KB, standard everywhere, one entity responsible for all of it, people know what it is and what it does, if it breaks you know what went wrong and who to blame. Literally anything built with NPM: megabytes? tens of megabytes? in size, totally inscrutable, code being pulled in from hundreds of megabytes of code in tens of thousands of packages from hundreds or thousands of people of unknown (and unknowable) competence and trustworthiness, if it breaks not only do you not know who to blame but you probably have literally no idea what wrong. Yeah, jQuery was probably better.
  - enlyth 7y ago
    That's a problem with the npm ecosystem. React is just so, so much nicer to work with. It's easy to be dismissive if you've never had to develop UIs with jQuery and didn't experience yourself the transition to React which is a million times better in terms of developer experience. I feel like people that don't build UIs themselves think of them too much in a completely functional way as in "it's just buttons and form inputs that do X", and forget about the massive complexity, edge cases, aesthetic requirements, accessibility, rendering on different viewports, huge statefulness, and so on.
    - engineeringwoke 7y ago
      Old is better is just not true here. React is a dream. Synthetic eventing, batched updates, and DOM node re-use are so good. I rolled my own DOM renderer recently and remembered a lot of problems from the past that I would not like to re-visit.
    - somatic 7y ago
      Yes, you're absolutely right: React itself is great. But React is part of the NPM ecosystem; try using one without the other. And then if you're still feeling cocky try finding someone else who uses one without the other.
  - Cthulhu_ 7y ago
    It Depends, as always. The problem React was originally solving was that DOM updates cause re-rendering which can be slow; jquery (usually) works directly in the DOM, so applications heavy in updates don't perform well. So initially an equivalent React and jQuery app would have React look a lot faster, due to smart / batched DOM updates. However, because React is so fast it made people create apps differently. As always in software development, an application will grow to fill up available performance / memory. If people were to develop on intentionally constricted computers they would do things differently. (IIRC, at Facebook they'll throttle the internet on some days to 3g speeds to force this exact thing. Tangentially related, at Netflix (iirc) they have Chaos Monkey which randomly shuts down servers and causes problems, so errors are a day to day thing instead of an exception they've not foreseen).
- Sharlin 7y ago
  To an extent, UI was solved in 1991 by Visual Basic. Yes, complex state management is not the best in a purely event-based programming model. Yes, you didn’t get a powerful document layout engine seamlessly integrated to the UI. Yes, theming your components was more difficult. And so on. But… if the alternative is what we have now? I’m not sure.
  - ptx 7y ago
    One big disadvantage with Visual Basic (and similar visual form designers) is that you can't put the result in version control and diff or merge it in any meaningful way.
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.

by jiofih 7y ago

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 ..."
  - Nasrudith 7y ago
    That brings to mind one common computer scientest fallacy - that elegence is an end to itself. It may share some properties which make it practical but unfortunately it is not in practice. Recursive solutions are more elegant but you still use a stack and while loop to not smash the stack.
    - somatic 7y ago
      Scheme is properly tail-recursive and has been around since 1975. Most (all?) Common Lisp implementations have proper tail recursion. Clojure has tail call optimization for simple cases and only if you explicitly ask for it, but it gets you most of the way there most of the time. So there are reasons to prefer more imperative languages and their systems, but stack-smashing isn't one of them.
somatic 7y ago
jQuery: 88KB, standard everywhere, one entity responsible for all of it, people know what it is and what it does, if it breaks you know what went wrong and who to blame. Literally anything built with NPM: megabytes? tens of megabytes? in size, totally inscrutable, code being pulled in from hundreds of megabytes of code in tens of thousands of packages from hundreds or thousands of people of unknown (and unknowable) competence and trustworthiness, if it breaks not only do you not know who to blame but you probably have literally no idea what wrong. Yeah, jQuery was probably better.
- enlyth 7y ago
  That's a problem with the npm ecosystem. React is just so, so much nicer to work with. It's easy to be dismissive if you've never had to develop UIs with jQuery and didn't experience yourself the transition to React which is a million times better in terms of developer experience. I feel like people that don't build UIs themselves think of them too much in a completely functional way as in "it's just buttons and form inputs that do X", and forget about the massive complexity, edge cases, aesthetic requirements, accessibility, rendering on different viewports, huge statefulness, and so on.
  - engineeringwoke 7y ago
    Old is better is just not true here. React is a dream. Synthetic eventing, batched updates, and DOM node re-use are so good. I rolled my own DOM renderer recently and remembered a lot of problems from the past that I would not like to re-visit.
  - somatic 7y ago
    Yes, you're absolutely right: React itself is great. But React is part of the NPM ecosystem; try using one without the other. And then if you're still feeling cocky try finding someone else who uses one without the other.
- Cthulhu_ 7y ago
  It Depends, as always. The problem React was originally solving was that DOM updates cause re-rendering which can be slow; jquery (usually) works directly in the DOM, so applications heavy in updates don't perform well. So initially an equivalent React and jQuery app would have React look a lot faster, due to smart / batched DOM updates. However, because React is so fast it made people create apps differently. As always in software development, an application will grow to fill up available performance / memory. If people were to develop on intentionally constricted computers they would do things differently. (IIRC, at Facebook they'll throttle the internet on some days to 3g speeds to force this exact thing. Tangentially related, at Netflix (iirc) they have Chaos Monkey which randomly shuts down servers and causes problems, so errors are a day to day thing instead of an exception they've not foreseen).
Sharlin 7y ago
To an extent, UI was solved in 1991 by Visual Basic. Yes, complex state management is not the best in a purely event-based programming model. Yes, you didn’t get a powerful document layout engine seamlessly integrated to the UI. Yes, theming your components was more difficult. And so on. But… if the alternative is what we have now? I’m not sure.
- ptx 7y ago
  One big disadvantage with Visual Basic (and similar visual form designers) is that you can't put the result in version control and diff or merge it in any meaningful way.

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.