27 ms·

After reading the "Grug Developer" article recently, I've been thinking of frontend development as "The Plane of Eternal Complexity Demons".

jitl 4y ago
This is because UI programming is inherently extremely complex, especially compared to something like a stateless API tier running in AWS. It’s stateful software deployed to countless different runtimes on hardware you don’t control. Instead of a smattering of API routes handling well-structured semantic datatypes like `POST /burgers?pickles=false`, input comes in the form of arbitrary UI events from various input devices like pens, keyboards, mice, etc that must be interpreted to have a semantic meaning. Often there are hundreds of API routes (event handling elements) on screen at once in a complex application. UI engineers are perpetually frustrated by this complexity, and so some small percentage look for better ways to handle these issues. Of course it’s best to avoid UI programming entirely, but in many domains it’s necessary.
- nwh5jg56df 4y ago
  We went to the moon some +50 years ago. We ought to have solved "UI programming" already, no? Something is not working
  - agumonkey 4y ago
    simple problems easily becomes complex in mainstream contexts.. due to bazaar like soil. NASA had to solve one immensely hard problem but they owned the context. Vertical integration if you will.
  - syspec 4y ago
    By that logo , SpaceX shouldn't exist.
  - bobthepanda 4y ago
    Ultimately, successful products are determined by customers and by product managers and their executives, and it turns out there is no one-size-fits-all approach to even basic UI programming because everyone has an opinion. Not to mention, as an example touch became a widespread new UI paradigm in the last 10-20 years.
  - wly_cdgr 4y ago
    UI programming is much harder than going to the moon. Do not confuse danger, scale, glamour, etc with difficulty
- mllllv 4y ago
  I disagree, I think UI programming is inherently quite simple. Especially with a paradigm like immediate-mode GUIs in my opinion. I believe the complexity comes from the fact that the DOM is a poor API for creating user interfaces, which ultimately inspired developers to create frameworks that work in a more “immediate-mode” style way.
  - cageface 4y ago
    The native UI toolkits are even harder to use than something like React and recently have been evolving to a similar reactive + declarative paradigm. User interfaces are complex, poorly specified, and subject to rapid and often capricious changes in the middle of development. Don't blame the tools.
- aaaaaaaaaaab 4y ago
  Bullshit. In 1995 people were creating desktop UIs order of magnitude more complex than today's anemic webapps, without any of the braindamage-inducing stuff that's happening in web UI development.
  - ChefboyOG 4y ago
    I was legitimately curious about this--my memory of Windows 95 is not this nice--so I looked at Wikipedia's list of software released in 1995: https://en.m.wikipedia.org/wiki/Category:1995_software https://en.m.wikipedia.org/wiki/Category:1995_software What software specifically do you recall being "an order of magnitude more complex" than today's popular web apps?
    - aaaaaaaaaaab 4y ago
      Just from the top of my mind: Excel, Word, Photoshop, Windows Commander (called Total Commander today), SolidWorks, AutoCAD, Borland Delphi.
      - chrisco255 4y ago
        Excel is quite complex, but the Excel of 2022 is far more complex than the Excel of 1995, and part of it exists on the web itself, so Excel '22 would be an invalidation of your argument that '95 apps were more complex (as well as other modern versions of the other apps). One major difference in 1995 applications is that almost none of them were collaborative or synced with a remote server. They were all isolated applications that worked entirely in a local context. They could be programmed to a single target platform on perhaps one to three screen resolutions (640x480, 800x600 and 1024x768). They could all work under the assumption that one style of input was being used (mouse and/or keyboard). They all could use simple built-in dropdown context menus. They could all render to a canvas context graphics with much of the heavy lifting assumed by the operating system itself.
        mixmastamyk 4y ago
        We certainly had network programming in the 90s. It was just that apps didn't use it unless needed. SGI res was typically 1280x1024 and Wacom tablets were common in studio/professional settings.
- wizofaus 4y ago
  There are definitely examples of UI programming that is more complex than certain APIs that largely perform basic CRUD operations, but I'd strongly disagree either is inherently more complex than the other, it's just that human behaviours and preferences are messy and unpredictable, which means conceptually "simple and elegant" UIs are often not what users actually enjoy using, and this inevitably has impacts at the code level. APIs don't have to designed to deal with human eccentricities as they're written for developers, and we aren't like normal people.
  - emptysea 4y ago
    I find the big difference for me when building an API vs working on a UI is the testing. I think backend APIs tend to be much easier to test than UIs. For the backend, it's mostly Request in Response out, check they look good and the side effects (database, caches, queues, etc.) are performed etc. For the UI you have a lot of async stuff going on and writing non-flakey tests is tricky and verbose with the current tooling - using react testing library which is better than enzyme, but still harder than testing a Django endpoint.
    - wizofaus 4y ago
      Absolutely - realistically you never can automate UI tests fully, as there's no way of describing all the things humans "expect" to experience while using a UI. Even when you can, the effort involved in creating and maintaining the tests and confirming that the failures are genuine often doesn't justify the benefits.
      - jitl 4y ago
        I think this suggests that UI is more complex than API.
        wizofaus 4y ago
        Then you've never written APIs that have to do super complex calculations or process huge amounts of data efficiently and reliably. By far the most complex code I've had to deal with has been "back-end engine" type code, even if it was technically part of a desktop application (but wasn't dealing with user interactions).
Starlevel001 4y ago
Server-side templating died for this.
sph 4y ago
It makes me smile that elsewhere in this thread there's people saying "I've been using <library> and state management is now super easy." when you know in two months people will be saying that library is over-engineered and someone will suggest to try the new panacea that will solve all of your problems, for real this time. Such is the hype cycle of frontend development.
- jcelerier 4y ago
  I mostly use Qt Widgets which hasn't fundamentally changed since 1995 and still performs just fine for desktop UI
doitLP 4y ago
Link: https://grugbrain.dev/ https://grugbrain.dev/ It is universally worth your time to read it if you haven’t :)
- pcthrowaway 4y ago
  Plain english translation: https://github.com/reidjs/grug-dev-translation https://github.com/reidjs/grug-dev-translation I haven't read it, but wish I had seen it before struggling through the original
  - surrealize 4y ago
    Thanks so much for the link! I tried the original and bounced off the style. It seemed like something that might be fun and useful if I invested enough effort in reading it, but I just bounced off. But with the translation, I just devoured and appreciated it.
- maxekman 4y ago
  Amazing read! Missed it when it trended 10 days ago. https://news.ycombinator.com/item?id=31840331 https://news.ycombinator.com/item?id=31840331
deleted 4y ago
[deleted]
robocat 4y ago
JavaScipt on the browser is cursed[1]. 1. There is no standard GUI library, as per article. A GUI can be as arbitrarily complex as you wish, and every different frontend system is a unique GUI system deployed in JavaScript, usually using HTML for the view drawing primitives* and events for input. The complexities of GUI library design bubble up to developers who are implementing their own tweaks or combinations of a GUI library, usually with a huge amount of “needless” variation. Application developers should ideally never have to be making choices about internals of a GUI system, yet the core of most articles comparing frontend frameworks is discussing GUI internals. 2. There is no golden standard for tooling. Everyone has their pet variations on how to deploy to JavaScript, CSS, and HTML. 3. Back end choice. Huge variation. As a developer we get APIs on the edges, but we make our own spaghetti to join everything how we wish because there is not one or two standard library/framework choices, and we have the power to do what we will. I developed my own 100% custom component framework because I could write one that suited us far better than what was available at the time (OSS or commercial). Browser variation used to be a huge driver for complexity, but is far less so now. * drawing primitives can also be Canvas or SVG or WebGL e.g. https://news.ycombinator.com/item?id=27131659 https://news.ycombinator.com/item?id=27131659 is a good comment. [1] https://www.google.co.nz/search?q=lisp+curse https://www.google.co.nz/search?q=lisp+curse
- lvass 4y ago
  At least in AI, what happened to lisp was being replaced by Python. What do you presume happens to JS in this case? WASM frameworks are likely to have the same problems. Stuff like Phoenix Liveview can be rather standard but limited in scope.

jitl 4y ago

This is because UI programming is inherently extremely complex, especially compared to something like a stateless API tier running in AWS. It’s stateful software deployed to countless different runtimes on hardware you don’t control. Instead of a smattering of API routes handling well-structured semantic datatypes like `POST /burgers?pickles=false`, input comes in the form of arbitrary UI events from various input devices like pens, keyboards, mice, etc that must be interpreted to have a semantic meaning. Often there are hundreds of API routes (event handling elements) on screen at once in a complex application. UI engineers are perpetually frustrated by this complexity, and so some small percentage look for better ways to handle these issues. Of course it’s best to avoid UI programming entirely, but in many domains it’s necessary.

nwh5jg56df 4y ago
We went to the moon some +50 years ago. We ought to have solved "UI programming" already, no? Something is not working
- agumonkey 4y ago
  simple problems easily becomes complex in mainstream contexts.. due to bazaar like soil. NASA had to solve one immensely hard problem but they owned the context. Vertical integration if you will.
- syspec 4y ago
  By that logo , SpaceX shouldn't exist.
- bobthepanda 4y ago
  Ultimately, successful products are determined by customers and by product managers and their executives, and it turns out there is no one-size-fits-all approach to even basic UI programming because everyone has an opinion. Not to mention, as an example touch became a widespread new UI paradigm in the last 10-20 years.
- wly_cdgr 4y ago
  UI programming is much harder than going to the moon. Do not confuse danger, scale, glamour, etc with difficulty
mllllv 4y ago
I disagree, I think UI programming is inherently quite simple. Especially with a paradigm like immediate-mode GUIs in my opinion. I believe the complexity comes from the fact that the DOM is a poor API for creating user interfaces, which ultimately inspired developers to create frameworks that work in a more “immediate-mode” style way.
- cageface 4y ago
  The native UI toolkits are even harder to use than something like React and recently have been evolving to a similar reactive + declarative paradigm. User interfaces are complex, poorly specified, and subject to rapid and often capricious changes in the middle of development. Don't blame the tools.
aaaaaaaaaaab 4y ago
Bullshit. In 1995 people were creating desktop UIs order of magnitude more complex than today's anemic webapps, without any of the braindamage-inducing stuff that's happening in web UI development.
- ChefboyOG 4y ago
  I was legitimately curious about this--my memory of Windows 95 is not this nice--so I looked at Wikipedia's list of software released in 1995: https://en.m.wikipedia.org/wiki/Category:1995_software https://en.m.wikipedia.org/wiki/Category:1995_software What software specifically do you recall being "an order of magnitude more complex" than today's popular web apps?
  - aaaaaaaaaaab 4y ago
    Just from the top of my mind: Excel, Word, Photoshop, Windows Commander (called Total Commander today), SolidWorks, AutoCAD, Borland Delphi.
    - chrisco255 4y ago
      Excel is quite complex, but the Excel of 2022 is far more complex than the Excel of 1995, and part of it exists on the web itself, so Excel '22 would be an invalidation of your argument that '95 apps were more complex (as well as other modern versions of the other apps). One major difference in 1995 applications is that almost none of them were collaborative or synced with a remote server. They were all isolated applications that worked entirely in a local context. They could be programmed to a single target platform on perhaps one to three screen resolutions (640x480, 800x600 and 1024x768). They could all work under the assumption that one style of input was being used (mouse and/or keyboard). They all could use simple built-in dropdown context menus. They could all render to a canvas context graphics with much of the heavy lifting assumed by the operating system itself.
      - mixmastamyk 4y ago
        We certainly had network programming in the 90s. It was just that apps didn't use it unless needed. SGI res was typically 1280x1024 and Wacom tablets were common in studio/professional settings.
wizofaus 4y ago
There are definitely examples of UI programming that is more complex than certain APIs that largely perform basic CRUD operations, but I'd strongly disagree either is inherently more complex than the other, it's just that human behaviours and preferences are messy and unpredictable, which means conceptually "simple and elegant" UIs are often not what users actually enjoy using, and this inevitably has impacts at the code level. APIs don't have to designed to deal with human eccentricities as they're written for developers, and we aren't like normal people.
- emptysea 4y ago
  I find the big difference for me when building an API vs working on a UI is the testing. I think backend APIs tend to be much easier to test than UIs. For the backend, it's mostly Request in Response out, check they look good and the side effects (database, caches, queues, etc.) are performed etc. For the UI you have a lot of async stuff going on and writing non-flakey tests is tricky and verbose with the current tooling - using react testing library which is better than enzyme, but still harder than testing a Django endpoint.
  - wizofaus 4y ago
    Absolutely - realistically you never can automate UI tests fully, as there's no way of describing all the things humans "expect" to experience while using a UI. Even when you can, the effort involved in creating and maintaining the tests and confirming that the failures are genuine often doesn't justify the benefits.
    - jitl 4y ago
      I think this suggests that UI is more complex than API.
      - wizofaus 4y ago
        Then you've never written APIs that have to do super complex calculations or process huge amounts of data efficiently and reliably. By far the most complex code I've had to deal with has been "back-end engine" type code, even if it was technically part of a desktop application (but wasn't dealing with user interactions).

Starlevel001 4y ago

Server-side templating died for this.

sph 4y ago

It makes me smile that elsewhere in this thread there's people saying "I've been using <library> and state management is now super easy." when you know in two months people will be saying that library is over-engineered and someone will suggest to try the new panacea that will solve all of your problems, for real this time. Such is the hype cycle of frontend development.

jcelerier 4y ago
I mostly use Qt Widgets which hasn't fundamentally changed since 1995 and still performs just fine for desktop UI

doitLP 4y ago

Link: https://grugbrain.dev/ https://grugbrain.dev/ It is universally worth your time to read it if you haven’t :)

pcthrowaway 4y ago
Plain english translation: https://github.com/reidjs/grug-dev-translation https://github.com/reidjs/grug-dev-translation I haven't read it, but wish I had seen it before struggling through the original
- surrealize 4y ago
  Thanks so much for the link! I tried the original and bounced off the style. It seemed like something that might be fun and useful if I invested enough effort in reading it, but I just bounced off. But with the translation, I just devoured and appreciated it.
maxekman 4y ago
Amazing read! Missed it when it trended 10 days ago. https://news.ycombinator.com/item?id=31840331 https://news.ycombinator.com/item?id=31840331

deleted 4y ago

[deleted]

robocat 4y ago

JavaScipt on the browser is cursed[1]. 1. There is no standard GUI library, as per article. A GUI can be as arbitrarily complex as you wish, and every different frontend system is a unique GUI system deployed in JavaScript, usually using HTML for the view drawing primitives* and events for input. The complexities of GUI library design bubble up to developers who are implementing their own tweaks or combinations of a GUI library, usually with a huge amount of “needless” variation. Application developers should ideally never have to be making choices about internals of a GUI system, yet the core of most articles comparing frontend frameworks is discussing GUI internals. 2. There is no golden standard for tooling. Everyone has their pet variations on how to deploy to JavaScript, CSS, and HTML. 3. Back end choice. Huge variation. As a developer we get APIs on the edges, but we make our own spaghetti to join everything how we wish because there is not one or two standard library/framework choices, and we have the power to do what we will. I developed my own 100% custom component framework because I could write one that suited us far better than what was available at the time (OSS or commercial). Browser variation used to be a huge driver for complexity, but is far less so now. * drawing primitives can also be Canvas or SVG or WebGL e.g. https://news.ycombinator.com/item?id=27131659 https://news.ycombinator.com/item?id=27131659 is a good comment. [1] https://www.google.co.nz/search?q=lisp+curse https://www.google.co.nz/search?q=lisp+curse

lvass 4y ago
At least in AI, what happened to lisp was being replaced by Python. What do you presume happens to JS in this case? WASM frameworks are likely to have the same problems. Stuff like Phoenix Liveview can be rather standard but limited in scope.