231–240 of 335 posts
So let me just check that I understand this correctly. A whole bunch of problems that were "solved" (or at least, had fairly good solutions) in the context of desktop GUI toolkits have resurfaced in the context of application development confined to the web browser. Almost none of the previous "solutions" are usable, because of the specifics of the theoretically portable "browser platform" for which all this developm…
So let me just check that I understand this correctly. A whole bunch of problems that were "solved" (or at least, had fairly good solutions) in the context of desktop GUI toolkits have resurfaced in the context of application development confined to the web browser. Almost none of the previous "solutions" are usable, because of the specifics of the theoretically portable "browser platform" for which all this developm…
So let me just check that I understand this correctly. A whole bunch of problems that were "solved" (or at least, had fairly good solutions) in the context of desktop GUI toolkits have resurfaced in the context of application development confined to the web browser. Almost none of the previous "solutions" are usable, because of the specifics of the theoretically portable "browser platform" for which all this developm…
When I google "cross-platform desktop frameworks", the entire first page of results are all about the modern toolkits like Electron, Photon, ReactNativeEverywhere, etc.
So it seems like your complaint is many years too late at this point. Maybe there were solutions to this 20 years ago, but if I'm starting from scratch today trying to build a cross-platform app, what I'm looking for are frameworks that are mature, well documented with lots of tutorials on how to do basic things, and have a large community around them for getting help on e.g. stackoverflow. It doesn't really matter what has been around longer, if the newcomers have surpassed it on these fronts.
So let me just check that I understand this correctly. A whole bunch of problems that were "solved" (or at least, had fairly good solutions) in the context of desktop GUI toolkits have resurfaced in the context of application development confined to the web browser. Almost none of the previous "solutions" are usable, because of the specifics of the theoretically portable "browser platform" for which all this developm…
I don't believe the concept of one way data flow was in the old desktop app approach was it?
Nor was the idea of "props" i.e. a consistent mechanism for pushing parameters down to subcomponents through a consistent and flexible interface.
Nor was the idea of the render function - giving components a consistent function used to display itself.
Also gigantic leaps are being made in the area of simple componentisation - we are now down to very pure functions that handle a very constrained task.
State management in ReactJS especially with hooks is giving much more simple and clean mechanisms for handling cross cutting.
Old desktop applications, because they did not have a core application "cycle/flow" and were not arranged as a tree of components, had a tendency to end up as a spaghetti mess of complex highly coupled interactions with the whole thing risking collapsing under its own weight of complex interactions. Modern frameworks like ReactJS address these things by reducing complexity, increasing modularity via components, giving applications a general structure which is a hierarchy of components, giving all applications a consistent model for data flow, forcing a simpler mechanism for data sharing via the one way data flow rather than the more highly coupled two way data binding, and lately, emphasising the power and simplicity of plain functions over classes, objects and inheritance.
Surely there's other innovations too I haven't thought of.
Characterising modern web development frameworks as somehow only now catching up to 20 year old desktop development does not seem correct to me. Such an idea does perpetuate the myth though that the JavaScript world is full of dumbos badly trying to reproduce what all the smart "real developers" did a long time ago.
So let me just check that I understand this correctly. A whole bunch of problems that were "solved" (or at least, had fairly good solutions) in the context of desktop GUI toolkits have resurfaced in the context of application development confined to the web browser. Almost none of the previous "solutions" are usable, because of the specifics of the theoretically portable "browser platform" for which all this developm…
1) The bloat cycle
2) The disruption cycle
The bloat cycle is where you have a “platform” that does more and more until it has a lot of features that most users don’t need. Eventually the cost of supporting those random features gets too high and there is pressure on people to hack together an alternative micro-platform that does some arbitrary subset of things. If that subset is actually a superset of “must-have features” for a large number of users the micro-platform becomes a new platform and the cycle repeats.
The disruption cycle is when there is a singular feature that is prohibitive to add to the framework, because of past decisions. Businesses working on the platform will just work around the hole, or fill the hole in a hacky way. This creates pressure for someone to create a new platform that solves that one unsolved problem. It can leave many solved problems unsolved and still ascend to dominance under conditions famously described in “The Innovator’s Dilemma”.
This would be something like “multiple users work on the same surface” or “works the same-ish on literally all the OS’es” features of the web.
These cycles might seem pointless, but they’re not because you end up in a different place than where you started. You get some fundamental simplifications and new features each time you go around.
Ideally as a user you want to time your entry into the cycle so you don’t have to deal with the regression phase.
So let me just check that I understand this correctly. A whole bunch of problems that were "solved" (or at least, had fairly good solutions) in the context of desktop GUI toolkits have resurfaced in the context of application development confined to the web browser. Almost none of the previous "solutions" are usable, because of the specifics of the theoretically portable "browser platform" for which all this developm…
Genuinely curious, as someone who wasn't building desktop apps 20 years ago, what are the toolkits you're referring to? When I google "cross-platform desktop frameworks", the entire first page of results are all about the modern toolkits like Electron, Photon, ReactNativeEverywhere, etc. So it seems like your complaint is many years too late at this point. Maybe there were solutions to this 20 years ago, but if I'm s…
I don't know whether there are more Electron apps these days around than Qt apps, but it's certainly neither outdated nor obscure.
Why is state management such a talked-about issue with React? Other than distributed state, which obviously comes with its own set of challenges, managing state doesn't seem to be an issue with any other language, framework or platform. But with React, it seems to be a major part of the learning curve, with entire tutorials dedicated to it and numerous libraries to help with it in some way.
Because React, more so than the other frameworks, puts such a strong emphasis on "the UI output is entirely based on your state", while at the same time there are some limitations to tracking state in ways that are inherently tied to your UI hierarchy.
How could anything else be true?
Earlier quoted context omitted.
> I've worked on a few applications with 'rich/complex interactions' and everyone on the team was opposed to using any sort of JS framework Ah but if you actually looked at what you built, I am 100% sure you folks built your own framework instead. A framework that has no community support, no stackoverflow articles to help out and most likely minimal explicit documentation. You will never be able to hire talent that…
> A framework that has no community support, no stackoverflow articles to help out and most likely minimal explicit documentation. But there are gains too. The custom framework is probably much smaller and less complex, easier to know 100% of. It can be stepped through in the debugger. It's much easier to change and add features that your company needs, there's no outside bureaucracy to get in the way. I disagree you…
Earlier quoted context omitted.
React and Redux are for apps. If you can do it with HTML/CSS, you absolutely should. React/Redux are a replacement for what people used to do with jquery or plain JS. They're not for display; they're for complex interaction of the kind that used to require a native user interface (Java Swing, Gtk, Win32, etc). Javascript is a mess, and the DOM is a mess; React makes that slightly less awful. (Redux is an extension to…
I actually write a good bit of React professionally. I'm familiar. I just have yet to see a very compelling case. And the excuse is almost always this nebulous "rich/complex interaction". And.... I just rarely see any good examples of this. The huge majority of apps (web or otherwise) are not video games. They're forms that submit stuff to a server and get a response. There's sometimes a dropdown here or there.... an…
Earlier quoted context omitted.
> I've never seen a form that really benefitted from client-side validation. As long as required fields are clearly marked, I don't really understand the value here. Required fields are typically not the only type of validation required by a form. I think a designer would see the value of client-side validation more easily than a developer. It's not to ensure correctness - it's to give the user quick and actionable f…
> it's to give the user quick and actionable feedback. Right.. But I think often times the difference is pretty overblown. Clicking "save" and getting that feedback in ~100ms is not, in my estimation, worth the massive extra overhead of using a front-end framework, duplicating your validation requirements, etc. If you're google or facebook or youtube or are otherwise printing money, go for it. But for the 99% of web…