3 ms·
User interfaces have different, inherent complexity that backend programming doesn't have. If you look at the Android & iOS native toolkits they've churned at l
by cageface 2y ago
User interfaces have different, inherent complexity that backend programming doesn't have. If you look at the Android & iOS native toolkits they've churned at least as much in the same time.
Also, and it seems like this has to be pointed out in every one of these threads, the complexity of interfaces we're building on the web now is far greater than what we were building 10 years ago.
- mrbombastic 2y agoNot sure why this is downvoted without comment, many people underestimate the complexity here.
- kitsune_ 2y agoThere indeed is complexity, but a lot of the projects that are created to deal with that complexity that gain traction are made by people who don't have much experience in general, or lack exposure to non-frontend programming, so you end up having to deal with a lot of half-baked stuff. It's kind of a lethal cocktail.
- skydhash 2y agoUi is practically a problem solved (from the technical perspective). The complexity you’re talking about stems from trying to solve the problem with the wrong technology (the DOM). Laying out text for a document is fundamentally different from creating an application interface. An things that are easy to do in any UI toolkit (from GTK to Android) can only be hacked in the DOM. Things like layout constraints (between two components) and lists.
- cageface 2y agoThis is completely wrong. The DOM is an implementation detail. All the native toolkits are moving to the same kind of declarative APIs that were pioneered on the web because it's just a lot easier to think of UI as a function of state than it is to get 100 imperative updates in a row right.
- gyomu 2y agoI have UIKit (iOS) code that’s over a decade old and still compiles and runs perfectly (it might look a bit off on new hardware form factors - eg content bleeds into the notch - but that’s about it). I have Python + Tkinter code that’s close to two decades old and still runs great (doesn’t look great tho but it didn’t look great at the time either). I have some vanilla JS websites that are about as old and still work great. As other commenters have noted, boring stable choices are there. Ignoring them for the fancy novel brittle stuff is entirely on the programmer.
- arvinsim 2y agoI bet all of your examples are not something you deploy to a modern application today. All of those are good in theory but don't stand against the demands of modern consumers.
- gyomu 2y agoBet lost. If as a technologist you can’t imagine companies making money selling software to happy customers without relying on the brittle trendy framework du jour, my only advice would be to spend less time making silly bets with strangers on internet discussion boards and more time looking at boring profitable companies.
- mattgreenrocks 2y agoA lot of devs justify the time they spend keeping up with the technological Joneses as necessary to keep pace with current trends (especially in UI). I think it is a bit of a cope though, because users just want to solve their problems. They don't care about React or htmx. They just want something that fixes the problem. This is actually very freeing: meet a real need and you don't have to believe that software development consists on running on a treadmill of constant changes for their own sake. Just do the job competently.
- arvinsim 2y agoWe don't live in a world where every dev can choose the technology they work on. Most of the time it is dictated by the whims of corporate(by making frameworks/tools as part of a job requirement) or by the mob(teams need to collective decide what technology to use).