4 ms·

These types of comments serve no purpose and really irritate me. Either A) You are ignoring that modern web apps are very complex w/ dashboards and complex fl

These types of comments serve no purpose and really irritate me. Either A) You are ignoring that modern web apps are very complex w/ dashboards and complex flows that can't be modelled with a simple URL scheme. B) You are saying "Actually I don't have a problem with React, my issue is with people using it everywhere for simple things". Which is silly because 1. That's not relevant to the article. Go talk about that issue somewhere else. 2. This feature is clearly only meant for more complex React applications, so you don't need to worry about it "over-complicating" simple React apps. 3. This feature would be just as hard to implement in a traditional web-app. JQuery based web-apps aren't simple, they are imperative hellholes. 4. React makes "simple" web-apps simpler. Even for websites that don't need React, using it can make the dev process easier.

unlinked_dll 7y ago
>You are ignoring that modern web apps are very complex w/ dashboards and complex flows that can't be modelled with a simple URL scheme. ...the problem here is developers consistently try and shape the round hole to fit their square peg. Web apps are not the appropriate product for this design problem - the solutions are desktop applications. It's very unfortunate that the ecosystem is so hostile to traditional desktop apps and solutions, but that gets back to OP's point - these frameworks are solving problems we've manufactured.
- bryanrasmussen 7y ago
  In 2004 I had a small company with some friends and we were making a desktop app that we called a media management system, that was basically for managing generating multiple media outputs from single sourced data yadda yadda yadda (I could go more into it), anyway we had some interest and some sales but we ended up running out of money and going bankrupt. I remember there were some interested people that would have thrown us money to keep going longer - but they really thought we should have been a web based application. So if by ecosystem you mean money, yeah, but I only make web apps nowadays unless someone comes with a big bucket of money for the desktop app beforehand - which I never see happening for some reason.
  - unlinked_dll 7y ago
    When you get down to it, the web is fantastic at displaying information not stored on a user's machine. It's also pretty good at taking user information and moving it somewhere else. But if your product is not just about information retrieval or collection, rather based on things like complex user interaction, persistent local data storage, integration with devices on the users machine or complex interactions that need to override mouse/keystroke behavior... then I'd question whether or not it should be a webapp. Discord is a really good example of this to me. They have a web client, sure, but the app itself makes sense on the desktop. There's nothing wrong with using web technologies to build the app, but the mental model of how browsers send/receive data from a server somewhere seems fundamentally incompatible with how such an app should work. What I meant by hostile is that publishing apps sucks for a lot of reasons, from lack of user demand to platform issues, poor sandboxing, distribution issues, etc. It's a shame, because that's how we wind up with such crazy complexity in web apps, when we could just stick to native OS APIs and call it a day.
    - orf 7y ago
      > There's nothing wrong with using web technologies to build the app, but the mental model of how browsers send/receive data from a server somewhere seems fundamentally incompatible with how such an app should work. So the solution would be to exclusively some "web technologies" (HTTPS, WS) to deliver content and messages to the application? I guess by creating a bunch of clients, managing request states and working around the intricacies involved there (or in the libraries you used). So after that's done then lets add some kind of auto-updating mechanism. After a while you get it working, awesome. Lets hope users constantly keep it updated! Spoiler: they will not. And then, when you think you're all finished, someone from product comes in and says "hey we want to A/B test this feature on these specific clients, when it's a Tuesday and they are connecting from India. Oh and these requirements will change every 24 hours". Great. "If only there was some set of technologies that made all of these problems convenient and effective", you think to yourself as you check Slack.
- hderms 7y ago
  so you'd like for us to go back to QT and such instead of taking advantage of the benefits a model like React has already given us for cross-platform UIs? (correct and performant web, desktop, mobile UIs)
- andrewflnr 7y ago
  Whether web apps are technically the right-shaped peg for a given hole is not the only factor in what technology gets used, and usually not even the biggest one. More often than not, web apps make good business sense, so that's what gets built. Regardless of where the problem came from, we still have to solve it.
- Klinky 7y ago
  Have to reviewed how multi-platform desktop apps are developed? Is that really easier and more elegant?
- woat 7y ago
  I have no idea why you have to resort to a traditional desktop application just because you want a way to show a loading bar... while something loads.

unlinked_dll 7y ago

>You are ignoring that modern web apps are very complex w/ dashboards and complex flows that can't be modelled with a simple URL scheme. ...the problem here is developers consistently try and shape the round hole to fit their square peg. Web apps are not the appropriate product for this design problem - the solutions are desktop applications. It's very unfortunate that the ecosystem is so hostile to traditional desktop apps and solutions, but that gets back to OP's point - these frameworks are solving problems we've manufactured.

bryanrasmussen 7y ago
In 2004 I had a small company with some friends and we were making a desktop app that we called a media management system, that was basically for managing generating multiple media outputs from single sourced data yadda yadda yadda (I could go more into it), anyway we had some interest and some sales but we ended up running out of money and going bankrupt. I remember there were some interested people that would have thrown us money to keep going longer - but they really thought we should have been a web based application. So if by ecosystem you mean money, yeah, but I only make web apps nowadays unless someone comes with a big bucket of money for the desktop app beforehand - which I never see happening for some reason.
- unlinked_dll 7y ago
  When you get down to it, the web is fantastic at displaying information not stored on a user's machine. It's also pretty good at taking user information and moving it somewhere else. But if your product is not just about information retrieval or collection, rather based on things like complex user interaction, persistent local data storage, integration with devices on the users machine or complex interactions that need to override mouse/keystroke behavior... then I'd question whether or not it should be a webapp. Discord is a really good example of this to me. They have a web client, sure, but the app itself makes sense on the desktop. There's nothing wrong with using web technologies to build the app, but the mental model of how browsers send/receive data from a server somewhere seems fundamentally incompatible with how such an app should work. What I meant by hostile is that publishing apps sucks for a lot of reasons, from lack of user demand to platform issues, poor sandboxing, distribution issues, etc. It's a shame, because that's how we wind up with such crazy complexity in web apps, when we could just stick to native OS APIs and call it a day.
  - orf 7y ago
    > There's nothing wrong with using web technologies to build the app, but the mental model of how browsers send/receive data from a server somewhere seems fundamentally incompatible with how such an app should work. So the solution would be to exclusively some "web technologies" (HTTPS, WS) to deliver content and messages to the application? I guess by creating a bunch of clients, managing request states and working around the intricacies involved there (or in the libraries you used). So after that's done then lets add some kind of auto-updating mechanism. After a while you get it working, awesome. Lets hope users constantly keep it updated! Spoiler: they will not. And then, when you think you're all finished, someone from product comes in and says "hey we want to A/B test this feature on these specific clients, when it's a Tuesday and they are connecting from India. Oh and these requirements will change every 24 hours". Great. "If only there was some set of technologies that made all of these problems convenient and effective", you think to yourself as you check Slack.
hderms 7y ago
so you'd like for us to go back to QT and such instead of taking advantage of the benefits a model like React has already given us for cross-platform UIs? (correct and performant web, desktop, mobile UIs)
andrewflnr 7y ago
Whether web apps are technically the right-shaped peg for a given hole is not the only factor in what technology gets used, and usually not even the biggest one. More often than not, web apps make good business sense, so that's what gets built. Regardless of where the problem came from, we still have to solve it.
Klinky 7y ago
Have to reviewed how multi-platform desktop apps are developed? Is that really easier and more elegant?
woat 7y ago
I have no idea why you have to resort to a traditional desktop application just because you want a way to show a loading bar... while something loads.