5 ms·

While I completely agree with most of this article. I think some of it is untrue. A lot of the new functionality is needed for a increasing amount of apps. For

While I completely agree with most of this article. I think some of it is untrue. A lot of the new functionality is needed for a increasing amount of apps. For example, I work on an app which wouldn't be possible on the web 5-10 years ago. It's a single page app because it needs to be. It uses a lot of javascript making many requests because we have to and the customers requires it. We could probably make it a lot faster, the issue is that the amount of functionality that we are trying to include in a short amount of time leaves us no other choice than to include yet another library etc. I know this case maybe isn't the kind of app the article is targeting. But I think even "simple" apps today often include some part of complexity that would be hard(er) to do in a "old style" multi page app. That being said, I use a lot of old style apps. I use the old reddit instead of the horrible new one. I use HN, I use fastmail so I do think speed is very important.

xg15 7y ago
> A lot of the new functionality is needed for a increasing amount of apps. Could you make a few examples? > It uses a lot of javascript making many requests because we have to and the customers requires it. Why couldn't the requests be done by the back-end? > But I think even "simple" apps today often include some part of complexity that would be hard(er) to do in a "old style" multi page app. Absolutely, but isn't that exactly the point of the article? Working with a framework can make development massively easier - however, the benefits of this only go to developers, while users have to bear the costs.
- ecmascript 7y ago
  > Could you make a few examples? Sure, not in any particular order (and there's a lot more) 1. Users can use drag and drop functionality on areas, making updates to the backend as they are moving stuff around. To have the webpage reload would not be an acceptable experience. 2. File management. Users can upload files and create folders, refreshing the page after every update wouldn't be nice. 3. Users can retrieve data on many objects. Open specific objects and see it's data in popups. Edit the data, add comments, upload images etc. Wouldn't work very well with a refresh. > Why couldn't the requests be done by the back-end? When the backend can do the requests, it does. I meant doing requests to our backend and to static resources. > Absolutely, but isn't that exactly the point of the article? Working with a framework can make development massively easier - however, the benefits of this only go to developers, while users have to bear the costs. Not really. I am saying that many new apps aren't simple crud apps anymore.
  - plorkyeran 7y ago
    What part of that do you think wasn't possible on the web 5-10 years ago? The term "ajax" is 15 years old now.
    - true_religion 7y ago
      It’s not that it wasn’t possible, but it was really fiddly keeping the HTML up to date with all state changes, and having the rendered template match up with what the JavaScript wanted to do. I ended up having to cut a lot of features to make projects happen on time, and adding a new complex feature to an existing site coded with unobstrusive JavaScript was always felt like a full rewrite. Doing it with React though is like being back to working with desktop GUIs. Anything you want we can do. In the older days, anything that had to be a complex webapp would be easier done as a java applet, or a flash app.
meritt 7y ago
> For example, I work on an app which wouldn't be possible on the web 5-10 years ago What is it? Because I highly doubt that statement. Ajax, DHTML, ActiveX, and Java Applets offered effectively the same solutions in the late 90s.
- ecmascript 7y ago
  Well, 5 years may have been a stretch. Maybe more like 10+. Doubt it as much as you want but we use several newer apis and phones wouldn't be powerful enough to run the damn thing 10 years ago since it's a web app.
  - meritt 7y ago
    I don't think you're making a good case for yourself. It would be extremely difficult to run Slack on a computer from the 1990s, but we sure as hell still had chat apps.
    - ecmascript 7y ago
      I don't think the majority of people had chat apps on their phones even in the late 2000s. I remember a little of the pre smartphone days. Basically no one installed any apps that didn't come with the phone. I tried to download some apps on some symbian device but experience was shitty as hell and many times they didn't even work for some unknown reason.
namewasmypw 7y ago
> For example, I work on an app which wouldn't be possible on the web 5-10 years ago. It's a single page app because it needs to be. No, it doesn't need to be. If you need to use hacks like SPAs to have the functionality you want, that is telling you that you're using the wrong tool for the job, and shouldn't be making a Web site. What you and a lot of other Web developers have done is, when faced with a square peg and a round hole, break the peg and the hole. Worse yet, not just for you, but for everybody who has to use those pegs and holes. Now the Web is a terrible place even for the people who used it correctly. Now the desktop is a terrible place because Web people have infected it with Electron. Web developers, if they can be called that, have set back the state of the art by several decades.
- gdev20 7y ago
  I think that you don't understand that web developers build what they are told to, not what they want. And if the company want a SPA you build it.
  - namewasmypw 7y ago
    Professionals in any field have a responsibility to do good and thoughtful work, and to treat their field with respect. Anyone who just builds whatever crap they're told is a bad professional.
    - Eikon 7y ago
      And the others are good professionals without a job then I guess.
      - namewasmypw 7y ago
        Right, just like how civil engineers are starving so hard they'll build faulty bridges for a paycheck. The post you made tells us a lot about how software ended up in the hellhole it has, and shows us why "software engineering" is currently an oxymoron. If Web developers had consequences like actual engineers, they would be killing their users instead of merely abusing them.

xg15 7y ago

> A lot of the new functionality is needed for a increasing amount of apps. Could you make a few examples? > It uses a lot of javascript making many requests because we have to and the customers requires it. Why couldn't the requests be done by the back-end? > But I think even "simple" apps today often include some part of complexity that would be hard(er) to do in a "old style" multi page app. Absolutely, but isn't that exactly the point of the article? Working with a framework can make development massively easier - however, the benefits of this only go to developers, while users have to bear the costs.

ecmascript 7y ago
> Could you make a few examples? Sure, not in any particular order (and there's a lot more) 1. Users can use drag and drop functionality on areas, making updates to the backend as they are moving stuff around. To have the webpage reload would not be an acceptable experience. 2. File management. Users can upload files and create folders, refreshing the page after every update wouldn't be nice. 3. Users can retrieve data on many objects. Open specific objects and see it's data in popups. Edit the data, add comments, upload images etc. Wouldn't work very well with a refresh. > Why couldn't the requests be done by the back-end? When the backend can do the requests, it does. I meant doing requests to our backend and to static resources. > Absolutely, but isn't that exactly the point of the article? Working with a framework can make development massively easier - however, the benefits of this only go to developers, while users have to bear the costs. Not really. I am saying that many new apps aren't simple crud apps anymore.
- plorkyeran 7y ago
  What part of that do you think wasn't possible on the web 5-10 years ago? The term "ajax" is 15 years old now.
  - true_religion 7y ago
    It’s not that it wasn’t possible, but it was really fiddly keeping the HTML up to date with all state changes, and having the rendered template match up with what the JavaScript wanted to do. I ended up having to cut a lot of features to make projects happen on time, and adding a new complex feature to an existing site coded with unobstrusive JavaScript was always felt like a full rewrite. Doing it with React though is like being back to working with desktop GUIs. Anything you want we can do. In the older days, anything that had to be a complex webapp would be easier done as a java applet, or a flash app.

meritt 7y ago

> For example, I work on an app which wouldn't be possible on the web 5-10 years ago What is it? Because I highly doubt that statement. Ajax, DHTML, ActiveX, and Java Applets offered effectively the same solutions in the late 90s.

ecmascript 7y ago
Well, 5 years may have been a stretch. Maybe more like 10+. Doubt it as much as you want but we use several newer apis and phones wouldn't be powerful enough to run the damn thing 10 years ago since it's a web app.
- meritt 7y ago
  I don't think you're making a good case for yourself. It would be extremely difficult to run Slack on a computer from the 1990s, but we sure as hell still had chat apps.
  - ecmascript 7y ago
    I don't think the majority of people had chat apps on their phones even in the late 2000s. I remember a little of the pre smartphone days. Basically no one installed any apps that didn't come with the phone. I tried to download some apps on some symbian device but experience was shitty as hell and many times they didn't even work for some unknown reason.

namewasmypw 7y ago

> For example, I work on an app which wouldn't be possible on the web 5-10 years ago. It's a single page app because it needs to be. No, it doesn't need to be. If you need to use hacks like SPAs to have the functionality you want, that is telling you that you're using the wrong tool for the job, and shouldn't be making a Web site. What you and a lot of other Web developers have done is, when faced with a square peg and a round hole, break the peg and the hole. Worse yet, not just for you, but for everybody who has to use those pegs and holes. Now the Web is a terrible place even for the people who used it correctly. Now the desktop is a terrible place because Web people have infected it with Electron. Web developers, if they can be called that, have set back the state of the art by several decades.

gdev20 7y ago
I think that you don't understand that web developers build what they are told to, not what they want. And if the company want a SPA you build it.
- namewasmypw 7y ago
  Professionals in any field have a responsibility to do good and thoughtful work, and to treat their field with respect. Anyone who just builds whatever crap they're told is a bad professional.
  - Eikon 7y ago
    And the others are good professionals without a job then I guess.
    - namewasmypw 7y ago
      Right, just like how civil engineers are starving so hard they'll build faulty bridges for a paycheck. The post you made tells us a lot about how software ended up in the hellhole it has, and shows us why "software engineering" is currently an oxymoron. If Web developers had consequences like actual engineers, they would be killing their users instead of merely abusing them.