7 ms·
This is because UI programming is inherently extremely complex, especially compared to something like a stateless API tier running in AWS. It’s stateful softwa
by 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 agoWe went to the moon some +50 years ago. We ought to have solved "UI programming" already, no? Something is not working
- agumonkey 4y agosimple 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 agoBy that logo , SpaceX shouldn't exist.
- bobthepanda 4y agoUltimately, 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 agoUI programming is much harder than going to the moon. Do not confuse danger, scale, glamour, etc with difficulty
- mllllv 4y agoI 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 agoThe 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 agoBullshit. 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 agoI 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 agoJust from the top of my mind: Excel, Word, Photoshop, Windows Commander (called Total Commander today), SolidWorks, AutoCAD, Borland Delphi.
- chrisco255 4y agoExcel 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 agoWe 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 agoThere 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 agoI 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 agoAbsolutely - 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 agoI think this suggests that UI is more complex than API.
- wizofaus 4y agoThen 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).