9 ms·

> But the cultural focus is on developer happiness, on developer fun and ramping up of code-related skillsets. "How does this benefit users?" has suddenly gone

> But the cultural focus is on developer happiness, on developer fun and ramping up of code-related skillsets. "How does this benefit users?" has suddenly gone missing from our vocabulary. No, it hasn't. It's still 100% about how to benefit users for most teams. That is quite literally the only thing that matters and everything else is a means to an end. I'm not going to deny the fact that there are some shoddy websites out there. There are some sites that are using the latest and greatest JS stuff when really, they should just be using HTML and CSS. Fine. The majority of the work that gets talked about here, by software and tech startups, will not be effectively built using HTML/CSS or server-side rendering. Since we're on the topic of users, users have come to expect a certain level of interactivity. They expect that if you right click on a row, you get a drop-down menu and you can delete it. They expect that you can do inline editing of an item without being redirected elsewhere. They expect that you can create a new thing on the page without reloading and redirecting. Let's forget about that part, though. Most software features are, at the end of the day, experimental. We don't know exactly what is going to be a hit and what isn't. If new tools allow us to iterate at 2x or 5x or 10x the rate of old tools, this is a net positive for users. No one would denigrate a carpenter for using an electric screwdriver over a manual one. No one would complain that the carpenter only cares about their "carpenter experience". At the end of the day, the "user" wants their cabinets finished.

ebullientocelot 8y ago
I largely agree with the points you are making, however I think there's a fundamental difference in the carpenter analogy: regardless of the type of screwdriver used there is no material difference in the UX of the cabinet, whereas that does not hold for web development decisions.
forrestbaer 8y ago
Your correlation between iteration cost to net positive for users is completely false. It might be a net positive for developers but certainly not users. You sound like the kind of developer who has only ever worked with an electric screwdriver. Loading 2 megs of javascript so you don't have to redirect and open a dropdown is NOT a benefit to the user. Relevant: http://suckless.org/philosophy/ http://suckless.org/philosophy/
- d357r0y3r 8y ago
  The fact that I spent time working with the manual screwdriver is how I understand the iterative difference. The turnaround time for features is not even remotely close. One of my first jobs was maintaining and extending an ASP.NET Web Forms application. A dashboard style application has to do way more than open a dropdown. People keep the page loaded all day long - the fact that it takes 2 seconds to load the first time is irrelevant.
  - forrestbaer 8y ago
    You understand the difference it makes to YOU as a developer, not the user! We don't need more features, we need lightweight software that everyone can use, that was the point of the article.
    - d357r0y3r 8y ago
      This is a whimsical belief. No - users actually do want more features. They want more features than you can ever hope to deliver. Figuring out which features they will actually appreciate is the tough part. Your competitors are working very hard to build those features before you can. Your competitor's sales team is already cold calling your users. Lightweight software is easy. As an engineer, I appreciate it, but it's not what the average user wants.
      - yellowapple 8y ago
        The user wants the site to actually work. The features don't matter if the site won't load because it's trying to shove multiple megabytes of JavaScript through a congested DSL or dial-up or 2G Internet connection (and especially not if that mass of JS is in turn trying to pull multiple megabytes of graphics before deciding to finally even add the actual content to the DOM). A prospective customer who can't use your website is a customer who's jumping ship to a competitor (as the article described with rather realistic examples). And for the vast majority of websites, the users don't actually want (let alone need) that degree of interactivity. A blog shouldn't depend on JS to be usable. A storefront shouldn't depend on JS to be usable. A restaurant page (even one with a reservation system!) shouldn't depend on JS to be usable. Even something like Twitter shouldn't depend on JS to be usable. Unless you're building something like Trello that's heavily dependent on drag-and-drop as a basic workflow, there is no good reason to make JavaScript a hard dependency on using your site. If users are forced to allow arbitrary Turing-complete code to run on their machines because your site is inexplicably incapable of running without it, then you have utterly failed. That's harsh, but that's reality. Your users want oodles of JavaScript only in the sense that a penguin wants to swim through an oil slick.
gaius 8y ago
It's still 100% about how to benefit users for most teams I’m sorry, but pages that pull in several Mb of ads and tracking to show a couple of Kb of text the user actually wants are by no means constructed for the benefit of the user, any more than the line is baited for the benefit of the fish.
- thecatspaw 8y ago
  Pulling in those megabytes of ads didnt increase developer satisfaction either. Those are marketing decisions, not technical decisions wether to render serverside or clientside
  - dbdjfjrjvebd 8y ago
    The developer gets paid partly by the adverts. Getting paid is integral to my job satisfaction... I actually don't work on any ad supported products. That improves my job satisfaction even more.
andy_adams 8y ago
As a user who occasionally uses rural (slow) internet, I wish more developers would just redirect to a new page for editing. It often takes longer for the initial JS-heavy page to load than it would for me to click & load 2 simple HTML pages. It's so bad that I just skip using certain websites when I'm on the slow internet.
- yulaow 8y ago
  Feel you. I live in an area with not even very slow internet, just not full 4G speed, but the experience of navigating heavy-js websites is... extremly bad. Like often I try for 5 seconds and then just quit the tab - bad. I feel like a lot of devs do not even try testing their websites / progressive webapps in slow speed situations or on low end devices. If they tried they would understand why here if you want people to try your service you must build an app, put it in the store and keep network messages at minimum. Webapps are a good way to get a "Not interested, thanks anyway"
  - 51lver 8y ago
    Been a little while since I looked into this, but some devs do test for slow connection usability. The problem is that browser tools for simulating a slow connection don't drop and delay packets semi randomly like radio tech will. They just limit your max speeds.
    - wbl 8y ago
      Iptables can be used to make a radio imitation.
    - tomovo 8y ago
      Try Network link conditioner, built-in part of macOS and iOS. It includes options to set bandwidth, packet loss % and latency in each direction.
taeric 8y ago
I can't agree. Most sites I see nowadays are not in any way more effective for their deep use of frameworks. Best example of the craziness here is the blogging stuff Google has that loads the content after the page load. Why? React is amusing, as it makes it look like you have to have a complex JavaScript framework to have hot loading. But you don't. Never have. Will you need a fancy tool that knows JavaScript well? Yes. Do you need to be writing to that tool, or with it? So, nobody would mock a carpenter for using power tools. They would question one that only worked with a 3d printer. Even though that would certainly let them iterate faster.
- josteink 8y ago
  > Most sites I see nowadays are not in any way more effective for their deep use of frameworks. It’s both amusing and sad to see modern web developers criticize Java for being “bloated” because they don’t understand the Abstract Factory-pattern (fairly light-weight, 2 levels), while themselves are using infinitely more complex and heavy frameworks to render what is more often than not is just static HTML.
  - marcosdumay 8y ago
    The problem with OOP patterns is not that they are complex. It's that you gain incredibly little by using them.
    - nradov 8y ago
      You can gain a huge amount using OOP patterns, if your problem domain maps well to the OOP paradigm. I know this from personal experience on many projects.
      - TeMPOraL 8y ago
        Yup. The actual issues with the design patterns come from a) most problems not mapping well to OOP, and b) patterns that exist only to compensate for low expressiveness of a language (e.g. all the patterns that compensate for not having proper closures).
zzzcpan 8y ago
> users have come to expect a certain level of interactivity. Users don't expect interactivity, they tolerate it. Think of websites as obstacles or puzzles users have to solve to get to what they want. They would rather not interact with those puzzles or wait for them to load at all. If you understand that - you can't justify interactivity or most front end development for that matter by claiming this is what users want.
Pica_soO 8y ago
>No one would denigrate a carpenter for using an electric screwdriver over a manual one. No one would complain that the carpenter only cares about their "carpenter experience". At the end of the day, the "user" wants their cabinets finished. Everyone would denigrate a carpenter, who refuses to do the work, and charges the bill, because he is out of battery and you dont have time, car and patience to drive to the next store to buy them. The truth is, most people do not pay the carpenter, so the carpenter is paid by the cops and shady businesses who need to install fency listening equipment, allover your house. So the carpenter cant use the old equipment, because the listening devices need the batterys of the screwdriver, and if he gave you the option to have your furniture carptendered the jesus way- aka for free and old fashioned, everybody would want new furniture and the carpenter would starve and yearn for a different cross to be nailed on. So, the basic advertisement and tracking website - 1Cent per call?
falcolas 8y ago
> If new tools allow us to iterate at 2x or 5x or 10x the rate of old tools, this is a net positive for users. Honestly, I disagree with this. Iteration is great for developers, but not users. To use your tool analogy, users are attempting to use the toolbox you made to perform a task, but the content of the toolbox and how you use it changes every day. Users of the toolbox can never become expert users, because they can't ever rely on their past experience with these tools - the usage has probably changed in subtle ways. Personally, I really hate having to re-learn how to use a screwdriver (or a blogging platform) every few days - and I'm a professional tool builder myself! It sucks even worse when I can't use your screwdriver if I only have 3G internet access.
- JohnFen 8y ago
  I could not agree more. Iteration is a wonderful thing while development is taking place in-house. Frequent iteration is a terrible thing if it's being done in products that actual people are actively using.
Ragnarork 8y ago
> [...] users have come to expect a certain level of interactivity. They expect that if you right click on a row, you get a drop-down menu and you can delete it. They expect that you can do inline editing of an item without being redirected elsewhere. They expect that you can create a new thing on the page without reloading and redirecting. I like that you speak in the name of "the users" who expect a certain level of interactivity, when that same level of interactivity on a page means many of these very same users won't ever see the page load fully, either because they can't be bothered to wait enough time on a slow connection, or because their browser/device simply won't do. I see quite a clear contradiction here. And it kinda proves the point this post make about overly eagerly assuming users have a fast enough network and/or device.
- throwaway2048 8y ago
  it also shows how quickly people make the "Good for developers = Good for users" mental leap.
sano1 8y ago
Carpenter here. Metaphors suck and are almost always deceptive ways to reinforce a point. Someone would denigrate a carpenter for using an electric screwdriver on finish screws where precise movements and protection of the surface area is important. You would be fired immediately.
- woah 8y ago
  Those are almost decorative though
wlll 8y ago
Well, as a user I find Javascript heavy websites to be a toxic wasteland full of dissapointment and failure. Just yesterday I was trying to use the Sendgrid support site. I was logged in. There was a "click here to login and send a support request" button (and no other way to create a ticket). clicking it just reloaded the page. There was a login link (even though I was logged in). It may as well have been a static image, you couldn't click it. After a few minutes of trying the button finally worked. When writing my ticket the support system would scroll the page down on every single keypress so that the text field was aligned with the bottom of the browser and I was typing on the bottom few pixels of my browser and display. It was awful. Unfortunately this "certain level of interactivity" is what I've come to expect from Javascript heavy websites. News sites where the content doesn't load. The re-rise of loading spinners, delays, errors, my CPU fans being exercised While. Displaying. Text. > No one would denigrate a carpenter for using an electric screwdriver over a manual one. No, but I'd complain if it took an hour to open my front door, took all my strength to do so, then when I finally got into the house it just fell into a pit and I had to start again. I hate the rise of Javascript, and I resent that it has made the web a significantly worse place.
- JohnFen 8y ago
  "Well, as a user I find Javascript heavy websites to be a toxic wasteland full of dissapointment and failure." And copious security issues. This is why I block all Javascript by default.
criddell 8y ago
> It's still 100% about how to benefit users for most teams. If that were true, things like Amp would never have even been proposed. Modern web browsers are absolute marvels, but shitty developers and business people are driving people like me into apps. I'm far less optimistic about the web now than I was 20 years ago. I more bullish than ever on the internet in general, but the web is a mess.
JohnFen 8y ago
"No, it hasn't. It's still 100% about how to benefit users for most teams." I have to say, though, that if this is the case then far too many teams utterly fail. Quite a lot of (most, I think) web sites don't appear to be designed primarily to benefit users to me (user benefit generally seems to fall to third place, behind "make it pretty" and "use the sexy new tools"). And that problem has been getting worse over the last decade or so. "No one would denigrate a carpenter for using an electric screwdriver over a manual one. No one would complain that the carpenter only cares about their "carpenter experience"." I absolutely would if the result is that the carpenter's work is worse for it.
- d357r0y3r 8y ago
  > I absolutely would if the result is that the carpenter's work is worse for it. I don't know by what metric the work is, on average, worse for it. I've been on the web since '91 and I've been more or less an obsessive user since then. I've seen the changes. The web - again, on average - is better to use than it ever has been. Some websites suck. Some websites are awesome. The worst websites in '95 were unusable and had broken layouts/styles, but people act like every website in '95 was some perfect embodiment of minimalist engineering.
  - JohnFen 8y ago
    "The web - again, on average - is better to use than it ever has been." My opinion is very different. Fair enough -- we're different people. "but people act like every website in '95 was some perfect embodiment of minimalist engineering." I'm certainly not asserting any such thing at all.
gumby 8y ago
> No, it hasn't. It's still 100% about how to benefit users for most teams. That is quite literally the only thing that matters and everything else is a means to an end. I can't agree with this statement. It's 100% about how to benefit the company, which means satisfying the customer. And serving users up to the customers is the name of the game. Most sites are heavy with trackers. You could argue that *one& might be in the user's interest, but can hardly make the same claim for the huge number of ad-related ones) and full of devious antipatterns. Just enough value for the user, one hopes, to get the page view.
sbov 8y ago
> The majority of the work that gets talked about here, by software and tech startups, will not be effectively built using HTML/CSS or server-side rendering. The majority of work that gets talked about here is technical work which is N levels below the business use case. Without the business use case you have no idea if it can be effectively built using server side rendering. Because of that I'm not sure anyone here is really able to make this statement.
lhorie 8y ago
In my experience, ironically, a lot of web tooling tends to actually bog you down, especially at scale. For example, I've seen people get blocked from shipping code due to a million lint errors after running some codemods, people wasting a month configuring webpack (and still not get it quite right), people wasting weeks cleaning up flow errors after a patch release. Bikesheds about webpack loaders and babel plugins and lint rules and typescript-vs-flow. Nasty workarounds for babel parsing bugs for non-standard syntax. Erroneously-strict mode bugs in bundling. Minification bugs. `node_modules` peer dep hoisting bugs. Bugs in `yarn`. GYP issues. Stuff that only breaks in CI. VS Code plugin configuration issues. Etc etc etc. Large companies literally have entire teams dedicated to maintaining tooling. And don't even get me started on monorepos. At a previous company, a co-worker that had been setting up tooling infrastructure for a project was astonished at my iteration speed when he saw that mine was written with just a micro-framework and ES5. Conversely, when I had to jump in to help get his project back on schedule, we could never figure why the hot reloading setup had a 2 second delay on my machine (among other things). Having worked on two projects of very comparable scope (two documentation sites for different projects), one written with the "latest and greatest" Gatsby and friends, and the other with just a dirty script, I honestly can't see any reason to do the former: it takes longer to do anything, the final payload is bigger, and now the codebase is using a version one major out of date, meaning a migration looming in the horizon. On the upside... GraphQL; yay I guess? With this point in mind, your carpenter analogy seems a bit off IMHO. Of course, consumers don't care if the carpenter uses an electric screwdriver, but they do care if a knob gets loose and falls off because it was held by a single rushedly-drilled screw. Also, the employer should presumably be worried if said carpenter keeps spending a significant portion of his time sanding his hammer handles and replacing his workbench legs, or needs another carpenter to do so on an ongoing basis.

ebullientocelot 8y ago

I largely agree with the points you are making, however I think there's a fundamental difference in the carpenter analogy: regardless of the type of screwdriver used there is no material difference in the UX of the cabinet, whereas that does not hold for web development decisions.

forrestbaer 8y ago

Your correlation between iteration cost to net positive for users is completely false. It might be a net positive for developers but certainly not users. You sound like the kind of developer who has only ever worked with an electric screwdriver. Loading 2 megs of javascript so you don't have to redirect and open a dropdown is NOT a benefit to the user. Relevant: http://suckless.org/philosophy/ http://suckless.org/philosophy/

d357r0y3r 8y ago
The fact that I spent time working with the manual screwdriver is how I understand the iterative difference. The turnaround time for features is not even remotely close. One of my first jobs was maintaining and extending an ASP.NET Web Forms application. A dashboard style application has to do way more than open a dropdown. People keep the page loaded all day long - the fact that it takes 2 seconds to load the first time is irrelevant.
- forrestbaer 8y ago
  You understand the difference it makes to YOU as a developer, not the user! We don't need more features, we need lightweight software that everyone can use, that was the point of the article.
  - d357r0y3r 8y ago
    This is a whimsical belief. No - users actually do want more features. They want more features than you can ever hope to deliver. Figuring out which features they will actually appreciate is the tough part. Your competitors are working very hard to build those features before you can. Your competitor's sales team is already cold calling your users. Lightweight software is easy. As an engineer, I appreciate it, but it's not what the average user wants.
    - yellowapple 8y ago
      The user wants the site to actually work. The features don't matter if the site won't load because it's trying to shove multiple megabytes of JavaScript through a congested DSL or dial-up or 2G Internet connection (and especially not if that mass of JS is in turn trying to pull multiple megabytes of graphics before deciding to finally even add the actual content to the DOM). A prospective customer who can't use your website is a customer who's jumping ship to a competitor (as the article described with rather realistic examples). And for the vast majority of websites, the users don't actually want (let alone need) that degree of interactivity. A blog shouldn't depend on JS to be usable. A storefront shouldn't depend on JS to be usable. A restaurant page (even one with a reservation system!) shouldn't depend on JS to be usable. Even something like Twitter shouldn't depend on JS to be usable. Unless you're building something like Trello that's heavily dependent on drag-and-drop as a basic workflow, there is no good reason to make JavaScript a hard dependency on using your site. If users are forced to allow arbitrary Turing-complete code to run on their machines because your site is inexplicably incapable of running without it, then you have utterly failed. That's harsh, but that's reality. Your users want oodles of JavaScript only in the sense that a penguin wants to swim through an oil slick.

gaius 8y ago

It's still 100% about how to benefit users for most teams I’m sorry, but pages that pull in several Mb of ads and tracking to show a couple of Kb of text the user actually wants are by no means constructed for the benefit of the user, any more than the line is baited for the benefit of the fish.

thecatspaw 8y ago
Pulling in those megabytes of ads didnt increase developer satisfaction either. Those are marketing decisions, not technical decisions wether to render serverside or clientside
- dbdjfjrjvebd 8y ago
  The developer gets paid partly by the adverts. Getting paid is integral to my job satisfaction... I actually don't work on any ad supported products. That improves my job satisfaction even more.

andy_adams 8y ago

As a user who occasionally uses rural (slow) internet, I wish more developers would just redirect to a new page for editing. It often takes longer for the initial JS-heavy page to load than it would for me to click & load 2 simple HTML pages. It's so bad that I just skip using certain websites when I'm on the slow internet.

yulaow 8y ago
Feel you. I live in an area with not even very slow internet, just not full 4G speed, but the experience of navigating heavy-js websites is... extremly bad. Like often I try for 5 seconds and then just quit the tab - bad. I feel like a lot of devs do not even try testing their websites / progressive webapps in slow speed situations or on low end devices. If they tried they would understand why here if you want people to try your service you must build an app, put it in the store and keep network messages at minimum. Webapps are a good way to get a "Not interested, thanks anyway"
- 51lver 8y ago
  Been a little while since I looked into this, but some devs do test for slow connection usability. The problem is that browser tools for simulating a slow connection don't drop and delay packets semi randomly like radio tech will. They just limit your max speeds.
  - wbl 8y ago
    Iptables can be used to make a radio imitation.
  - tomovo 8y ago
    Try Network link conditioner, built-in part of macOS and iOS. It includes options to set bandwidth, packet loss % and latency in each direction.

taeric 8y ago

I can't agree. Most sites I see nowadays are not in any way more effective for their deep use of frameworks. Best example of the craziness here is the blogging stuff Google has that loads the content after the page load. Why? React is amusing, as it makes it look like you have to have a complex JavaScript framework to have hot loading. But you don't. Never have. Will you need a fancy tool that knows JavaScript well? Yes. Do you need to be writing to that tool, or with it? So, nobody would mock a carpenter for using power tools. They would question one that only worked with a 3d printer. Even though that would certainly let them iterate faster.

josteink 8y ago
> Most sites I see nowadays are not in any way more effective for their deep use of frameworks. It’s both amusing and sad to see modern web developers criticize Java for being “bloated” because they don’t understand the Abstract Factory-pattern (fairly light-weight, 2 levels), while themselves are using infinitely more complex and heavy frameworks to render what is more often than not is just static HTML.
- marcosdumay 8y ago
  The problem with OOP patterns is not that they are complex. It's that you gain incredibly little by using them.
  - nradov 8y ago
    You can gain a huge amount using OOP patterns, if your problem domain maps well to the OOP paradigm. I know this from personal experience on many projects.
    - TeMPOraL 8y ago
      Yup. The actual issues with the design patterns come from a) most problems not mapping well to OOP, and b) patterns that exist only to compensate for low expressiveness of a language (e.g. all the patterns that compensate for not having proper closures).

zzzcpan 8y ago

> users have come to expect a certain level of interactivity. Users don't expect interactivity, they tolerate it. Think of websites as obstacles or puzzles users have to solve to get to what they want. They would rather not interact with those puzzles or wait for them to load at all. If you understand that - you can't justify interactivity or most front end development for that matter by claiming this is what users want.

Pica_soO 8y ago

>No one would denigrate a carpenter for using an electric screwdriver over a manual one. No one would complain that the carpenter only cares about their "carpenter experience". At the end of the day, the "user" wants their cabinets finished. Everyone would denigrate a carpenter, who refuses to do the work, and charges the bill, because he is out of battery and you dont have time, car and patience to drive to the next store to buy them. The truth is, most people do not pay the carpenter, so the carpenter is paid by the cops and shady businesses who need to install fency listening equipment, allover your house. So the carpenter cant use the old equipment, because the listening devices need the batterys of the screwdriver, and if he gave you the option to have your furniture carptendered the jesus way- aka for free and old fashioned, everybody would want new furniture and the carpenter would starve and yearn for a different cross to be nailed on. So, the basic advertisement and tracking website - 1Cent per call?

falcolas 8y ago

> If new tools allow us to iterate at 2x or 5x or 10x the rate of old tools, this is a net positive for users. Honestly, I disagree with this. Iteration is great for developers, but not users. To use your tool analogy, users are attempting to use the toolbox you made to perform a task, but the content of the toolbox and how you use it changes every day. Users of the toolbox can never become expert users, because they can't ever rely on their past experience with these tools - the usage has probably changed in subtle ways. Personally, I really hate having to re-learn how to use a screwdriver (or a blogging platform) every few days - and I'm a professional tool builder myself! It sucks even worse when I can't use your screwdriver if I only have 3G internet access.

JohnFen 8y ago
I could not agree more. Iteration is a wonderful thing while development is taking place in-house. Frequent iteration is a terrible thing if it's being done in products that actual people are actively using.

Ragnarork 8y ago

> [...] users have come to expect a certain level of interactivity. They expect that if you right click on a row, you get a drop-down menu and you can delete it. They expect that you can do inline editing of an item without being redirected elsewhere. They expect that you can create a new thing on the page without reloading and redirecting. I like that you speak in the name of "the users" who expect a certain level of interactivity, when that same level of interactivity on a page means many of these very same users won't ever see the page load fully, either because they can't be bothered to wait enough time on a slow connection, or because their browser/device simply won't do. I see quite a clear contradiction here. And it kinda proves the point this post make about overly eagerly assuming users have a fast enough network and/or device.

throwaway2048 8y ago
it also shows how quickly people make the "Good for developers = Good for users" mental leap.

sano1 8y ago

Carpenter here. Metaphors suck and are almost always deceptive ways to reinforce a point. Someone would denigrate a carpenter for using an electric screwdriver on finish screws where precise movements and protection of the surface area is important. You would be fired immediately.

woah 8y ago
Those are almost decorative though

wlll 8y ago

Well, as a user I find Javascript heavy websites to be a toxic wasteland full of dissapointment and failure. Just yesterday I was trying to use the Sendgrid support site. I was logged in. There was a "click here to login and send a support request" button (and no other way to create a ticket). clicking it just reloaded the page. There was a login link (even though I was logged in). It may as well have been a static image, you couldn't click it. After a few minutes of trying the button finally worked. When writing my ticket the support system would scroll the page down on every single keypress so that the text field was aligned with the bottom of the browser and I was typing on the bottom few pixels of my browser and display. It was awful. Unfortunately this "certain level of interactivity" is what I've come to expect from Javascript heavy websites. News sites where the content doesn't load. The re-rise of loading spinners, delays, errors, my CPU fans being exercised While. Displaying. Text. > No one would denigrate a carpenter for using an electric screwdriver over a manual one. No, but I'd complain if it took an hour to open my front door, took all my strength to do so, then when I finally got into the house it just fell into a pit and I had to start again. I hate the rise of Javascript, and I resent that it has made the web a significantly worse place.

JohnFen 8y ago
"Well, as a user I find Javascript heavy websites to be a toxic wasteland full of dissapointment and failure." And copious security issues. This is why I block all Javascript by default.

criddell 8y ago

> It's still 100% about how to benefit users for most teams. If that were true, things like Amp would never have even been proposed. Modern web browsers are absolute marvels, but shitty developers and business people are driving people like me into apps. I'm far less optimistic about the web now than I was 20 years ago. I more bullish than ever on the internet in general, but the web is a mess.

JohnFen 8y ago

"No, it hasn't. It's still 100% about how to benefit users for most teams." I have to say, though, that if this is the case then far too many teams utterly fail. Quite a lot of (most, I think) web sites don't appear to be designed primarily to benefit users to me (user benefit generally seems to fall to third place, behind "make it pretty" and "use the sexy new tools"). And that problem has been getting worse over the last decade or so. "No one would denigrate a carpenter for using an electric screwdriver over a manual one. No one would complain that the carpenter only cares about their "carpenter experience"." I absolutely would if the result is that the carpenter's work is worse for it.

d357r0y3r 8y ago
> I absolutely would if the result is that the carpenter's work is worse for it. I don't know by what metric the work is, on average, worse for it. I've been on the web since '91 and I've been more or less an obsessive user since then. I've seen the changes. The web - again, on average - is better to use than it ever has been. Some websites suck. Some websites are awesome. The worst websites in '95 were unusable and had broken layouts/styles, but people act like every website in '95 was some perfect embodiment of minimalist engineering.
- JohnFen 8y ago
  "The web - again, on average - is better to use than it ever has been." My opinion is very different. Fair enough -- we're different people. "but people act like every website in '95 was some perfect embodiment of minimalist engineering." I'm certainly not asserting any such thing at all.

gumby 8y ago

> No, it hasn't. It's still 100% about how to benefit users for most teams. That is quite literally the only thing that matters and everything else is a means to an end. I can't agree with this statement. It's 100% about how to benefit the company, which means satisfying the customer. And serving users up to the customers is the name of the game. Most sites are heavy with trackers. You could argue that *one& might be in the user's interest, but can hardly make the same claim for the huge number of ad-related ones) and full of devious antipatterns. Just enough value for the user, one hopes, to get the page view.

sbov 8y ago

> The majority of the work that gets talked about here, by software and tech startups, will not be effectively built using HTML/CSS or server-side rendering. The majority of work that gets talked about here is technical work which is N levels below the business use case. Without the business use case you have no idea if it can be effectively built using server side rendering. Because of that I'm not sure anyone here is really able to make this statement.

lhorie 8y ago

In my experience, ironically, a lot of web tooling tends to actually bog you down, especially at scale. For example, I've seen people get blocked from shipping code due to a million lint errors after running some codemods, people wasting a month configuring webpack (and still not get it quite right), people wasting weeks cleaning up flow errors after a patch release. Bikesheds about webpack loaders and babel plugins and lint rules and typescript-vs-flow. Nasty workarounds for babel parsing bugs for non-standard syntax. Erroneously-strict mode bugs in bundling. Minification bugs. `node_modules` peer dep hoisting bugs. Bugs in `yarn`. GYP issues. Stuff that only breaks in CI. VS Code plugin configuration issues. Etc etc etc. Large companies literally have entire teams dedicated to maintaining tooling. And don't even get me started on monorepos. At a previous company, a co-worker that had been setting up tooling infrastructure for a project was astonished at my iteration speed when he saw that mine was written with just a micro-framework and ES5. Conversely, when I had to jump in to help get his project back on schedule, we could never figure why the hot reloading setup had a 2 second delay on my machine (among other things). Having worked on two projects of very comparable scope (two documentation sites for different projects), one written with the "latest and greatest" Gatsby and friends, and the other with just a dirty script, I honestly can't see any reason to do the former: it takes longer to do anything, the final payload is bigger, and now the codebase is using a version one major out of date, meaning a migration looming in the horizon. On the upside... GraphQL; yay I guess? With this point in mind, your carpenter analogy seems a bit off IMHO. Of course, consumers don't care if the carpenter uses an electric screwdriver, but they do care if a knob gets loose and falls off because it was held by a single rushedly-drilled screw. Also, the employer should presumably be worried if said carpenter keeps spending a significant portion of his time sanding his hammer handles and replacing his workbench legs, or needs another carpenter to do so on an ongoing basis.