5 ms·

Multi page flows are fine for many data entry style apps which covers a lot of the web. But for more nuanced software, responsive and rich ui is very important

Multi page flows are fine for many data entry style apps which covers a lot of the web. But for more nuanced software, responsive and rich ui is very important to user uptake. Examples: Gmail, Facebook, Maps, Slack, SoundCloud, every autocomplete search box everywhere. If you accept that parts of the page should be interactive then you need to consider the benefit of an isomorphic approach to eliminate code duplication. Usually it's not just a single interactive component.

Retric 9y ago
You can do all of that with very lightweight JavaScript though. 10+ years ago I did autocomplete using a few carefully crafted lines of code and the page still renders just fine. The problem is JS frameworks make development easier but have high real world costs that are often ignored.
- andrewstuart2 9y ago
  Your second sentence describes engineering trade-offs. The simplest engineering solution to a canyon is to walk around it. The most practical or productive solution over the long run is a different question entirely from the simplest or easiest to implement.
  - Retric 9y ago
    Frameworks are simpler to implement and maintain, that does not make them better for users.
  - TeMPOraL 9y ago
    Yup, those are engineering trade-offs. Making your life a little easier by causing users a disproportionate amount of resource waste, frustration and security issues is just shitty engineering. Even though the business types may like it, because externalities are good for profit.
- ozim 9y ago
  "I did autocomplete using a few carefully crafted lines of code" Now take 10 developers to reuse that autocomplete in the same project in 10 different places. I bet those carefully crafted lines become 100 little monsters, one without eye other with 3 legs. Not that they have to be stupid, it is just they think differently.
  - Retric 9y ago
    Users don't care about development. Sure, for us frameworks are great, for them the trade offs look far worse.
  - TeMPOraL 9y ago
    If they were really carefully crafted, then they likely can be carefully repackaged into a solution that could be included in those 10 different places with zero - or close to zero - runtime overhead on the code sharing mechanism. But it takes actual thinking - and care - to do that. Something that seems to be in short supply with the current web trends.
- mmcnl 9y ago
  Are JS frameworks really easier than your good ol' fully server-side rendered websites? I doubt that. There are costs for everything, both for using and _not_ using JS. It's silly to think that only using JS adds a cost and nothing else. That's just tunnel vision.
falcolas 9y ago
Gmail started out as a multi-page flow, and it worked perfectly fine. Page loads were quick because there wasn't several MB of JS to be interpreted with every page load, just some HTML and CSS.

Retric 9y ago

You can do all of that with very lightweight JavaScript though. 10+ years ago I did autocomplete using a few carefully crafted lines of code and the page still renders just fine. The problem is JS frameworks make development easier but have high real world costs that are often ignored.

andrewstuart2 9y ago
Your second sentence describes engineering trade-offs. The simplest engineering solution to a canyon is to walk around it. The most practical or productive solution over the long run is a different question entirely from the simplest or easiest to implement.
- Retric 9y ago
  Frameworks are simpler to implement and maintain, that does not make them better for users.
- TeMPOraL 9y ago
  Yup, those are engineering trade-offs. Making your life a little easier by causing users a disproportionate amount of resource waste, frustration and security issues is just shitty engineering. Even though the business types may like it, because externalities are good for profit.
ozim 9y ago
"I did autocomplete using a few carefully crafted lines of code" Now take 10 developers to reuse that autocomplete in the same project in 10 different places. I bet those carefully crafted lines become 100 little monsters, one without eye other with 3 legs. Not that they have to be stupid, it is just they think differently.
- Retric 9y ago
  Users don't care about development. Sure, for us frameworks are great, for them the trade offs look far worse.
- TeMPOraL 9y ago
  If they were really carefully crafted, then they likely can be carefully repackaged into a solution that could be included in those 10 different places with zero - or close to zero - runtime overhead on the code sharing mechanism. But it takes actual thinking - and care - to do that. Something that seems to be in short supply with the current web trends.
mmcnl 9y ago
Are JS frameworks really easier than your good ol' fully server-side rendered websites? I doubt that. There are costs for everything, both for using and _not_ using JS. It's silly to think that only using JS adds a cost and nothing else. That's just tunnel vision.

falcolas 9y ago

Gmail started out as a multi-page flow, and it worked perfectly fine. Page loads were quick because there wasn't several MB of JS to be interpreted with every page load, just some HTML and CSS.