5 ms·

> Think about the most complex frontends you’ve used. Frontends that made you wonder — “how did they create this”? What makes these frontends complex? State man

> Think about the most complex frontends you’ve used. Frontends that made you wonder — “how did they create this”? What makes these frontends complex? State management. The frontend “knows” a lot of things, and these things interact with each other in non-trivial ways. So in my view, state management is the core problem when developing a UI. To build a non-trivial React application, you need to consider state management, in my view. For example, say your app has a dark mode. All your rendered components must know what theme is on, so they can render the UI in the right color. This makes me wonder “how did we allow this to happen”? The beginning of this article alone reflects the whole tragedy of modern programming. When I was a child we would just use common controls and the operating system would paint them whatever way configured in the control panel. Now we have to solve a complex state management problem just to implement a dark mode. Application programming was supposed to become simpler and easier, not this...

deleted 7y ago
[deleted]
breytex 7y ago
You got that wrong. Modern JavaScript / SPAs make it possible to implement something like Outlook right within your browser. No (big) download, no clicking through an installation wizard, no fragmentation of versions for a tool, which forces you to be online anyway. I don't get all the hate towards SPAs and JavaScript Frameworks here on HN. Everyone is basically complaining about complexity for applications, which are more than just a server-rendered form or message board (which is a way less complex applications compared to outlook or slack, where "realtime notification" is a requirement). Application programming became easier by a lot, just the application requirements grew at the same speed, resulting in that feeling of stagnation. With something like zustand[1] or the react context api, its just ~10 lines of code to store the dark-mode boolean somewhere central in the app and connect it to all the components without prop drilling. [1] https://github.com/react-spring/zustand https://github.com/react-spring/zustand
- goatlover 7y ago
  But is React simpler for building UIs than the RAD tooling of Visual Basic, Delphi or the Flash Designer? Obviously there is the advantage of the web platform to leverage with JS frameworks, but there was something really nice about being able to drag and drop standard controls that all users were familiar with, and then just attach some code to them that talked to a database or whatever. I think that was the Parent's point that modern web development, while having the advantages of the web, is still more complicated than what was popular a decade or two ago for making UIs.
  - k__ 7y ago
    "is React simpler for building UIs than the RAD tooling of Visual Basic, Delphi or the Flash Designer" I asked something like this too, but the other way around. "If Flash, Delphi, etc. were so good, where are they now?" The answers were: These tools were good for one developer or small teams, but textual dev tools scaled better to big teams.
    - int_19h 7y ago
      Delphi is "textual" as well - the designer works with text files (*.dfm) that describe the component tree. Very similar to JSON, but with more Pascal-like syntax. People mostly used the designer because it was easier - but then again, in that era, it was also common for people to use e.g. Dreamweaver to write HTML.
      - k__ 7y ago
        Maybe, getting into development got easier? I mean, while these graphical tools certainly help, you have to learn them. I learned things like Photoshop, Sketch, Ableton Live, Final Cut Pro, Eclipse, etc. pp. and I can tell that it's a huge time investment to get up and running. Maybe coding is that much easier, that people invest their time into this instead of a UI builder? Maybe people got burned by Flash and now want to invest into somthing that lasts longer?
ehutch79 7y ago
If you're using js state management for dark mode, something has gone horribly wrong.
zeroxfe 7y ago
> Now we have to solve a complex state management problem just to implement a dark mode. What they're saying is that if you have a large complex system, it would be easier to implement dark mode with good state management. Not that you need complex state management to implement dark mode.
hombre_fatal 7y ago
Which client stack have you used where state management was simple and easy? Pretty much all desktop/mobile SDKs have all the same problems of two-way data binding that we moved away from in the web. Frankly, the web has the best experiments in state management simplicity yet that I wish we had long ago across all clients. It's taking way too long for the best ideas to trickle out into non-web clients. macOS/iOS is a good modern example of the old way of doing things where you're stuck using this weird OOP-for-OOP's-sake Core Data abstraction that certainly doesn't feel like a local optimum. It's the polar opposite of simplicity. When things don't work, it gets complicated very fast as you try to credentialize in it. By the way, client development was never easy. It's only gotten simpler over time. Painting a component to the screen (your example) whether you can use a built-in or have to make your own is still the easiest part of client development, not the hard part. State management and deciding on when to repaint is still the hard part. And just because the runtime gives you a solution doesn't mean it's simple or ideal. So I'm wondering which specific client development experience you're looking back on with such rose-tinted glasses.
veeralpatel979 7y ago
Author here. The way I think about it is, the web was designed for rendering static markup. JavaScript was designed for adding small amounts of interactivity. Instead, we've managed to turn the web into a full-blown application platform. Do you think Tim Berners-Lee envisioned something like Google Maps being created in the browser? Now, I concede that JavaScript isn't the best language for creating client-side apps. I hope someone applies some first-principle thinking and creates a language expressly designed for this purpose. Considering how many people and developers use web apps, this could be an area where someone can have a massive impact. I wonder if WebAssembly is the solution here?

deleted 7y ago

[deleted]

breytex 7y ago

You got that wrong. Modern JavaScript / SPAs make it possible to implement something like Outlook right within your browser. No (big) download, no clicking through an installation wizard, no fragmentation of versions for a tool, which forces you to be online anyway. I don't get all the hate towards SPAs and JavaScript Frameworks here on HN. Everyone is basically complaining about complexity for applications, which are more than just a server-rendered form or message board (which is a way less complex applications compared to outlook or slack, where "realtime notification" is a requirement). Application programming became easier by a lot, just the application requirements grew at the same speed, resulting in that feeling of stagnation. With something like zustand[1] or the react context api, its just ~10 lines of code to store the dark-mode boolean somewhere central in the app and connect it to all the components without prop drilling. [1] https://github.com/react-spring/zustand https://github.com/react-spring/zustand

goatlover 7y ago
But is React simpler for building UIs than the RAD tooling of Visual Basic, Delphi or the Flash Designer? Obviously there is the advantage of the web platform to leverage with JS frameworks, but there was something really nice about being able to drag and drop standard controls that all users were familiar with, and then just attach some code to them that talked to a database or whatever. I think that was the Parent's point that modern web development, while having the advantages of the web, is still more complicated than what was popular a decade or two ago for making UIs.
- k__ 7y ago
  "is React simpler for building UIs than the RAD tooling of Visual Basic, Delphi or the Flash Designer" I asked something like this too, but the other way around. "If Flash, Delphi, etc. were so good, where are they now?" The answers were: These tools were good for one developer or small teams, but textual dev tools scaled better to big teams.
  - int_19h 7y ago
    Delphi is "textual" as well - the designer works with text files (*.dfm) that describe the component tree. Very similar to JSON, but with more Pascal-like syntax. People mostly used the designer because it was easier - but then again, in that era, it was also common for people to use e.g. Dreamweaver to write HTML.
    - k__ 7y ago
      Maybe, getting into development got easier? I mean, while these graphical tools certainly help, you have to learn them. I learned things like Photoshop, Sketch, Ableton Live, Final Cut Pro, Eclipse, etc. pp. and I can tell that it's a huge time investment to get up and running. Maybe coding is that much easier, that people invest their time into this instead of a UI builder? Maybe people got burned by Flash and now want to invest into somthing that lasts longer?

ehutch79 7y ago

If you're using js state management for dark mode, something has gone horribly wrong.

zeroxfe 7y ago

> Now we have to solve a complex state management problem just to implement a dark mode. What they're saying is that if you have a large complex system, it would be easier to implement dark mode with good state management. Not that you need complex state management to implement dark mode.

hombre_fatal 7y ago

Which client stack have you used where state management was simple and easy? Pretty much all desktop/mobile SDKs have all the same problems of two-way data binding that we moved away from in the web. Frankly, the web has the best experiments in state management simplicity yet that I wish we had long ago across all clients. It's taking way too long for the best ideas to trickle out into non-web clients. macOS/iOS is a good modern example of the old way of doing things where you're stuck using this weird OOP-for-OOP's-sake Core Data abstraction that certainly doesn't feel like a local optimum. It's the polar opposite of simplicity. When things don't work, it gets complicated very fast as you try to credentialize in it. By the way, client development was never easy. It's only gotten simpler over time. Painting a component to the screen (your example) whether you can use a built-in or have to make your own is still the easiest part of client development, not the hard part. State management and deciding on when to repaint is still the hard part. And just because the runtime gives you a solution doesn't mean it's simple or ideal. So I'm wondering which specific client development experience you're looking back on with such rose-tinted glasses.

veeralpatel979 7y ago

Author here. The way I think about it is, the web was designed for rendering static markup. JavaScript was designed for adding small amounts of interactivity. Instead, we've managed to turn the web into a full-blown application platform. Do you think Tim Berners-Lee envisioned something like Google Maps being created in the browser? Now, I concede that JavaScript isn't the best language for creating client-side apps. I hope someone applies some first-principle thinking and creates a language expressly designed for this purpose. Considering how many people and developers use web apps, this could be an area where someone can have a massive impact. I wonder if WebAssembly is the solution here?