5 ms·

Sometimes I wonder if these framework astronauts have ever done a little Java Swing or VB GUI or the like. A user interface is not the greatest problem of our t

Sometimes I wonder if these framework astronauts have ever done a little Java Swing or VB GUI or the like. A user interface is not the greatest problem of our time...it's not supposed to be this hard...

jillesvangurp 8y ago
Yep, I started out doing java swing and awt UIs in the nineties. That stuff was a walk in the park compared to the craptastic react garbage that passes for software engineering these days. Looking at the JS landscape right now, it feels like we are running backwards in a hurry. Back in the day you could drag and drop simple uis together in minutes in range of IDEs for several languages. Any idiot could do it. In fact there were lots of idiots being productive in stuff like VB. The pros would do it programmatically in basically not a lot more time and end up with something that was easy to maintain and evolve. You'd struggle to replicate most of that stuff in javascript even if you had days/weeks to do it. You'd be reinventing off the shelf components along the way that were completely bog standard 25 years ago; hand crafting event handling mechanisms; dealing with hard layout and positioning issues; etc. That style of development seems to have died out for no good reason that I can think of other than that Javascript has been the only thing that actually works in a browser for the last 20 years. There's no other good reason for people to tolerate that. Looking forward to WASM fixing that problem over the next few years. I might even get back to doing some frontend stuff.
- kthejoker2 8y ago
  So on one hand, this this this. I left web dev 10 years ago for data precisely because I saw that I was being asked to learn complexity for complexity's sake and no notable benefit to my users. On the other hand, the rise of cross-browser and cross-OS compatibility is really the root cause that drove a lot of this complexity from jQuery to React to even WASM, so you can't throw the baby out with the bathwater.
dynamite-ready 8y ago
UI development is hard. It's always the most avidly scrutinised component of a software product, and needs can change very easily as a result, not just at the design/review stage, but also at runtime. So because of that, there seems to be this mad scramble to standardise the tools needed to cope with all the different categories of change. Managing events in a large UI can often be a nightmare, no matter how you approach it. Race condition errors are common, so the idea, for example, of a universal event bus, is a longstanding pattern for dealing with the complexity found in handling a large number of disparate events, and displaying their results. Redux is the latest 'solution' to that problem, though I personally think that Backbone Radio (https://marionettejs.com/docs/master/backbone.radio.html https://marionettejs.com/docs/master/backbone.radio.html) handled it best. Even the name suggests a solid understanding of the problem. What's nice about Redux, is that by demanding this explicit contract between events and data changes, you're much less likely to experience race condition errors. But it's resultantly complicated. I'm not knowledgeable enough (or possibly too lazy right now) to tell you if the reducer pattern is the best way to guarantee immutability, but it works in Redux, despite the hurdles (read as 'complicated API'). GraphQL is nice, and does have it's place. Especially in making it much easier to decide exactly how server-side data is consumed by the client, so it's worth the time in some cases, sure. But GraphQL should not be seen as a way to bypass the problems associated with managing events on the front end. Because that will eventually lead to server load issues, which are potentially far more expensive to fix.

jillesvangurp 8y ago

Yep, I started out doing java swing and awt UIs in the nineties. That stuff was a walk in the park compared to the craptastic react garbage that passes for software engineering these days. Looking at the JS landscape right now, it feels like we are running backwards in a hurry. Back in the day you could drag and drop simple uis together in minutes in range of IDEs for several languages. Any idiot could do it. In fact there were lots of idiots being productive in stuff like VB. The pros would do it programmatically in basically not a lot more time and end up with something that was easy to maintain and evolve. You'd struggle to replicate most of that stuff in javascript even if you had days/weeks to do it. You'd be reinventing off the shelf components along the way that were completely bog standard 25 years ago; hand crafting event handling mechanisms; dealing with hard layout and positioning issues; etc. That style of development seems to have died out for no good reason that I can think of other than that Javascript has been the only thing that actually works in a browser for the last 20 years. There's no other good reason for people to tolerate that. Looking forward to WASM fixing that problem over the next few years. I might even get back to doing some frontend stuff.

kthejoker2 8y ago
So on one hand, this this this. I left web dev 10 years ago for data precisely because I saw that I was being asked to learn complexity for complexity's sake and no notable benefit to my users. On the other hand, the rise of cross-browser and cross-OS compatibility is really the root cause that drove a lot of this complexity from jQuery to React to even WASM, so you can't throw the baby out with the bathwater.

dynamite-ready 8y ago

UI development is hard. It's always the most avidly scrutinised component of a software product, and needs can change very easily as a result, not just at the design/review stage, but also at runtime. So because of that, there seems to be this mad scramble to standardise the tools needed to cope with all the different categories of change. Managing events in a large UI can often be a nightmare, no matter how you approach it. Race condition errors are common, so the idea, for example, of a universal event bus, is a longstanding pattern for dealing with the complexity found in handling a large number of disparate events, and displaying their results. Redux is the latest 'solution' to that problem, though I personally think that Backbone Radio (https://marionettejs.com/docs/master/backbone.radio.html https://marionettejs.com/docs/master/backbone.radio.html) handled it best. Even the name suggests a solid understanding of the problem. What's nice about Redux, is that by demanding this explicit contract between events and data changes, you're much less likely to experience race condition errors. But it's resultantly complicated. I'm not knowledgeable enough (or possibly too lazy right now) to tell you if the reducer pattern is the best way to guarantee immutability, but it works in Redux, despite the hurdles (read as 'complicated API'). GraphQL is nice, and does have it's place. Especially in making it much easier to decide exactly how server-side data is consumed by the client, so it's worth the time in some cases, sure. But GraphQL should not be seen as a way to bypass the problems associated with managing events on the front end. Because that will eventually lead to server load issues, which are potentially far more expensive to fix.