17 ms·

I am not a front-end developer but looking at it from a distance I really don't get modern web design. Sure some sites might need fancy javascript single page f

I am not a front-end developer but looking at it from a distance I really don't get modern web design. Sure some sites might need fancy javascript single page features, like if your webpage is an interactive map or realtime game, but most sites are just text and some pictures. Whats with all the javascript? Your site looks just like the next one anyway! It feels like an "Emperor's New Clothes" situation or maybe more likely I just don't understand the allure as an clueless user.. I am almost tempted to make a webpage to see what the big fuss is about!

alecst 6y ago
I agree with you. It definitely does not serve the user. I have two thoughts, as a nobody. 1. Ads/trackers/etc. need javascript 2. It's a way of flexing and saying "we have resources to put into this webpage which makes us a serious business." Any other thoughts?
- apabepa 6y ago
  Yes the ads/trackers/etc is most likely a reason that a webpage cannot be completely without javascript. Two other possible reasons from the top of my head: If a web developer is hired to make a site they can probably charge more if it is a fancy javascript site. In some cases it might be in their self interest to up-sell this to a client that does not know better. If a web developer makes a site for themselves I am sure many want to take the opportunity to get some experience in the latest web-tech while they are at it. Just as I will use an obscure programming language for my next side project..
- dgb23 6y ago
  Things that are running based on JS on "regular" sites from the top of my head: - Toggling widgets such as menus, modals and other things you only want to show when the user requests it. This includes updating accessibility related HTML attributes. - filtering, sorting etc. of larger data sets in the client. - live updates of fresh, time related data - search that doesn't force a complete reload, via AJAX or cached on the client. - smoother page / content transitions via AJAX - everything related to forms / user input: you want to instantly react - managing and preserving state / context per user - visualizations / graphs that are explorable / interactive - polyfills for older browsers that don't support optimizations such as lazy loading. - interactive widgets such as chat boxes (not a fan but still) - testing and analytics A website isn't made of paper.
MaxBarraclough 6y ago
From what I can tell the short answer is that you're right, there's really no good technical reason for all that weight. Which is to say, it's just bloat. Much has been written on this. Here's an article from 2018. (I realise the irony in that it's hosted on Medium.) https://medium.com/@addyosmani/the-cost-of-javascript-in-2018-7d8950fbb5d4 https://medium.com/@addyosmani/the-cost-of-javascript-in-201...
- spideymans 6y ago
  The JS performance difference between high and low-end devices is stunning (9s vs 32s load times, based on the Medium article). Web devs, who are often used to using the latest and greatest devices, will have no idea how terrible their code performs on slower devices. And I fear that modern CPUs with excellent JS performance will only exacerbate this issue
  - MaxBarraclough 6y ago
    It's strange as poor performance is known to be off-putting to users, which presumably translates into less traffic and thereby less profit for the site.
  - SulfurHexaFluri 6y ago
    I had always been using 2-3 year old android phones for the last 7 years and I was unable to comprehend how anyone uses the web on mobile because everything was so incredibly slow in the browser while native apps were fine. Then I got the latest iphone and my mind was blown at how I could scroll a website at 60fps. I guess if you have the fastest phone on the market, everything seems fine.
  - cellar_door 6y ago
    > will have no idea how terrible their code performs on slower devices You can (and should) monitor page load performance... using JS
sct202 6y ago
Some people are used to using javascript packages (so importing a whole framework when they are only using a small portion of the functionality) to help with UI like collapsing/expanding menus depending on the screen width. You can do a lot of those things with pure CSS now, but that's a more recent thing and a lot of popular tutorials are still JS + CSS.
timw4mail 6y ago
I have done a lot of front-end work, and full stack work. I do not understand either.
ratww 6y ago
As someone involved in hiring, this is what Bootcamps and Universities are teaching, and what companies are looking for: backend spits JSON, frontend consumes it using React. Rendering HTML on the server is not really "the default" anymore as it was 10 year ago: it's more of an optimization for when your React site is slow, and it's a black box to most people. Even static websites are "strange tech" to new graduates outside the HN bubble. Also, developers hate mixing tech. You mentioned an "interactive map" in your example. This can be made with React or something like that, right? The issue is that a lot of developers will want to use React for everything else on the page, because they think it's "icky" to use other kinds of tech in other parts of the website. They sorta have a point (the "microfrontends" discussion was a thing a couple years ago), but on the other hand they're not considering the tradeoffs. Also, the frontend is officially the centre of the application on medium sized companies (50+ devs). It's way easier to add new code to the frontend and spin another microservice than to coordinate between multiple teams of backend engineers. I'm not saying this is good or bad, btw. It's just how it is. EDIT: One thing that really bothers me that people fresh in the industry don't really believe that websites were faster 10 or 20 years ago, so I don't really see any light at the end of the tunnel. Sure we can do new things on the web, but what was already possible before has been made slower by our collective refusal to "use the right tool for the job". Even the frontend tooling today is very heavy and slow, and I'm in a 2020 MBP. I don't think we progressed much. React is an amazing idea (and the implementation is great), but the community has become too dogmatic.
- michaelpb 6y ago
  A few years ago when teaching at a previous coding bootcamp that started with FE JavaScript, I remember my surprise when well-performing students got through 3 months or so of it and were confused and very impressed when I showed them how an <a> tag worked, since they had only been aware of (jQuery) JavaScript powered pages. When you are stuck just doing JS powered SPAs, an <a> tag seems like advanced technology! I ended up at a new school creating a new curriculum. This approach is where we "recapitulate the evolution of the web", so we start with SSGs & server-side programming (Python/Django), then only at the end cover SPAs and React.JS -- since, as you mentioned, that's still the main skillset that companies are new devs for.
grishka 6y ago
As an Android developer who's now making a hobby project that has a web UI, I don't understand it either. I'm doing it the old-fashioned way and it's so fast that my browser doesn't have the time to display a loading animation when I refresh the page.
nicbou 6y ago
In the end, I just end up using Firefox' reader mode, because what I really want is the main article. Everything else is noise.
ziftface 6y ago
The fact is, the Javascript ecosystem is unmatched when it comes to very quickly creating frontend applications. Maybe another set of tools would have been better, but that doesn't really matter. This set of tools is what everyone uses, and a lot of effort and creativity goes into making js frontend development as smooth and fast as possible. I often need to very quickly make internal services at my job and while I like working in other languages (and i do for longer term projects), those always take longer to set up and get working. In js with next you're up and running in less than 60 seconds and if you're doing crud stuff, most of the work is frankly done for you.
- anderspitman 6y ago
  The cost of developing in JS isn't necessarily lower, just amortized. Or in many cases, externalized to your users.
  - ziftface 6y ago
    > externalized to your users You mean if you have customers with less powerful devices like the OP? I don't really see internal services or B2B products having that problem.
    - anderspitman 6y ago
      You original point > the Javascript ecosystem is unmatched when it comes to very quickly creating frontend applications Didn't hinge on whether you were creating internal tools or not. You simply used internal tools as an example of what you personally do with JS.
      - ziftface 6y ago
        I see your point, and I agree it's definitely not a good solution to some problems. But I think it can be very productive if your constraints allow you to use it.
        6y ago
userbinator 6y ago
I'm not either, but I've written quite a few webpages over the years, and even the occasional use of JS, but only when it's not possible to do without. I suspect much of the superfluous JS comes from a " if you have only a hammer, everything looks like a nail" mentality.
carapace 6y ago
Yes, the Emperor is bare-ass naked, now hush before you get someone fired.
srcreigh 6y ago
The two biggest rants on HN are 1) Why doesn't this site work without JavaScript? It's inaccessible. and 2) Why doesn't this app work offline? It invades my privacy. Maybe I'm wrong, but as far as I can tell, you can't have both. Sorry folks. You are right, JS is not needed if the site truly is static content. But if you try to make an interactive app that could be implemented client-side (AKA javascript) and attach a server to it, everybody will complain that the application doesn't respect the user's privacy, since it could be offline-only but it's not. Don't get me wrong, I think "interactive" can meaningfully include a simple site with links if you are looking at it from a privacy angle. Just look at how StackOverflow recently was able to track all the pages their hacker viewed. [1] SO is pretty much static content. So do you want StackOverflow to work without JavaScript? Are you happy that in-so-doing it needs to phone home whenever you look something up? You can't have one without the other. There is also the argument from scalability. You'll get less QPS on your servers if you implement a 3-step form with validation in the frontend, and send off all the data in one go. It's also faster/better UX and is more resilient under bad network conditions. Edge computing is maybe an alternative there, but that doesn't address inherent privacy concerns of phoning home to a server. Last there is the reality of a spectrum of interactivity of websites. If you are doing a blog, sure, don't do it in JS. At that point you make a decision to make it difficult to add any interactive features to you site which require JS. If you are building an evolving app with interactive features, there aren't many options for easily mixing static HTML with interactive JS. You could see how far you get with static HTML but then what if you need interactivity (JS/JQuery)? What if you need complex interactivity (React)? Are you willing to pay the costs of a heterogeneous app architecture of HTML mixed with interactive JS? Think of Facebook. It is kinda like a blog, but what about infinite scroll? Etc. Anyway that last point, I think, is why people are excited about 37signals' Hotwire[2]. It's more of a HTML-but-interactive architecture as opposed to the fully-interactive JS/React vs static HTML forms. [1]: https://stackoverflow.blog/2021/01/25/a-deeper-dive-into-our-may-2019-security-incident/ https://stackoverflow.blog/2021/01/25/a-deeper-dive-into-our... [2]: https://hotwire.dev/ https://hotwire.dev/
- kaba0 6y ago
  I don’t understand your second point. Which web app works offline?? (Unless they are deliberately made for that purpose. Hell, even most electron apps refuse to work without a connection) They regularly make new requests, there is literally no difference between SSR and CSR in this regard - it seems a bit that you are arguing with a straw men. Like, what does a webshop do which is written in react/whatever and you go to the next “page”, it hadn’t loaded yet? Also, noone would even think that it is unreasonable for a WEBapp to phone home. What people have trouble with is tracking, that is orthogonal to the current topic and should be condemned.
throw_m239339 6y ago
> Whats with all the javascript? On blogs and news media site? mostly ad tech . The irony is that it took AMP, a proprietary solution, for all these websites that mainly deal with text and image, to start cracking down on all that stuff. Remember "mobile first"? Well the majority of web developers clearly do not have a Mobile first strategy, when you look at how heavy their webpages are. Even the javascript could be lighter, but since everybody is using node.js and NPM behind the scene with a lot of complex modules, well code bundles become crazy big.
csomar 6y ago
It's a bit more complicated than that. Modern web development done correctly can help: Pages are generated in the server, no JavaScript required. If you start with a PWA mentality, then your application/site is progressive and you should cover everyone; or almost. However: 1- Progressive is expensive. You'll need more time as you need to sort what features can work; and work your way up to the full experience. The full experience, however, is what you are getting paid for (or showing). Unless the client or the company cares about these categories, you don't want to expend budget on that. 2- Web development is becoming complicated. You can get started quickly with Nextjs/Gatsby thanks to "DX"(Developer Experience). The reality is that you don't understand much of what's going on behind the surface and if you bootcamp-ed your way in 3 months, you probably have no idea what's going on. But it works!
moring 6y ago
> Whats with all the javascript What's with all the server round-trips? If you have a UI that takes user input and just reacts to it, without any data needed from the server -- why should it go on a full round-trip just to get a new UI element that it could create locally just as well? Look at other things on your computer: a text editor, or a calculator. Would you expect every interaction to send a request to some remote server just for the sake of it?
- smaudet 6y ago
  Shitty server code isn't an excuse for shitty frontend code though. Moreover you are confounding apps with the web. A calculator should probably never use the network... Pretty much every web browser can and has to open and send network packets - as long as they are small and there is not a lot of state, you are fine. You can support almost any device from 20, 30 years ago. 'Modern' JS dogpiles huge swathes of mostly unused, uncompiled code, resulting in huge network transfer costs, extreme overusage of CPU and RAM, and encourages a lot of e-waste because it mainly only works well with the latest devices... It's arguable that this is such a bad engineering design, just to save some network packets, I wouldn't be surprised if the carbon footprint of a JS developer was at least similar to that of burning coal...
datagram 6y ago
I think the bloat comes from a few places: Developer productivity: Making complex pages and reusing components across pages is much easier with a library like React than with more vanilla approaches. For a lot of companies with large numbers of engineers, making sure that engineers can be productive without intimate knowledge of HTML/CSS ends up taking priority over things like performance and accessibility. Branding/customization: The built-in HTML controls are difficult/impossible to style or customize. A lot of UI designers will design some fancy looking select dropdown, not appreciating the fact that they're forcing developers to reinvent the wheel in order to implement their design. Alternatively, there are cases where the UX for built-in controls is lacking enough that you're somewhat forced to implement a replacement (e.g. <select multiple>)

alecst 6y ago

I agree with you. It definitely does not serve the user. I have two thoughts, as a nobody. 1. Ads/trackers/etc. need javascript 2. It's a way of flexing and saying "we have resources to put into this webpage which makes us a serious business." Any other thoughts?

apabepa 6y ago
Yes the ads/trackers/etc is most likely a reason that a webpage cannot be completely without javascript. Two other possible reasons from the top of my head: If a web developer is hired to make a site they can probably charge more if it is a fancy javascript site. In some cases it might be in their self interest to up-sell this to a client that does not know better. If a web developer makes a site for themselves I am sure many want to take the opportunity to get some experience in the latest web-tech while they are at it. Just as I will use an obscure programming language for my next side project..
dgb23 6y ago
Things that are running based on JS on "regular" sites from the top of my head: - Toggling widgets such as menus, modals and other things you only want to show when the user requests it. This includes updating accessibility related HTML attributes. - filtering, sorting etc. of larger data sets in the client. - live updates of fresh, time related data - search that doesn't force a complete reload, via AJAX or cached on the client. - smoother page / content transitions via AJAX - everything related to forms / user input: you want to instantly react - managing and preserving state / context per user - visualizations / graphs that are explorable / interactive - polyfills for older browsers that don't support optimizations such as lazy loading. - interactive widgets such as chat boxes (not a fan but still) - testing and analytics A website isn't made of paper.

MaxBarraclough 6y ago

From what I can tell the short answer is that you're right, there's really no good technical reason for all that weight. Which is to say, it's just bloat. Much has been written on this. Here's an article from 2018. (I realise the irony in that it's hosted on Medium.) https://medium.com/@addyosmani/the-cost-of-javascript-in-2018-7d8950fbb5d4 https://medium.com/@addyosmani/the-cost-of-javascript-in-201...

spideymans 6y ago
The JS performance difference between high and low-end devices is stunning (9s vs 32s load times, based on the Medium article). Web devs, who are often used to using the latest and greatest devices, will have no idea how terrible their code performs on slower devices. And I fear that modern CPUs with excellent JS performance will only exacerbate this issue
- MaxBarraclough 6y ago
  It's strange as poor performance is known to be off-putting to users, which presumably translates into less traffic and thereby less profit for the site.
- SulfurHexaFluri 6y ago
  I had always been using 2-3 year old android phones for the last 7 years and I was unable to comprehend how anyone uses the web on mobile because everything was so incredibly slow in the browser while native apps were fine. Then I got the latest iphone and my mind was blown at how I could scroll a website at 60fps. I guess if you have the fastest phone on the market, everything seems fine.
- cellar_door 6y ago
  > will have no idea how terrible their code performs on slower devices You can (and should) monitor page load performance... using JS

sct202 6y ago

Some people are used to using javascript packages (so importing a whole framework when they are only using a small portion of the functionality) to help with UI like collapsing/expanding menus depending on the screen width. You can do a lot of those things with pure CSS now, but that's a more recent thing and a lot of popular tutorials are still JS + CSS.

timw4mail 6y ago

I have done a lot of front-end work, and full stack work. I do not understand either.

ratww 6y ago

As someone involved in hiring, this is what Bootcamps and Universities are teaching, and what companies are looking for: backend spits JSON, frontend consumes it using React. Rendering HTML on the server is not really "the default" anymore as it was 10 year ago: it's more of an optimization for when your React site is slow, and it's a black box to most people. Even static websites are "strange tech" to new graduates outside the HN bubble. Also, developers hate mixing tech. You mentioned an "interactive map" in your example. This can be made with React or something like that, right? The issue is that a lot of developers will want to use React for everything else on the page, because they think it's "icky" to use other kinds of tech in other parts of the website. They sorta have a point (the "microfrontends" discussion was a thing a couple years ago), but on the other hand they're not considering the tradeoffs. Also, the frontend is officially the centre of the application on medium sized companies (50+ devs). It's way easier to add new code to the frontend and spin another microservice than to coordinate between multiple teams of backend engineers. I'm not saying this is good or bad, btw. It's just how it is. EDIT: One thing that really bothers me that people fresh in the industry don't really believe that websites were faster 10 or 20 years ago, so I don't really see any light at the end of the tunnel. Sure we can do new things on the web, but what was already possible before has been made slower by our collective refusal to "use the right tool for the job". Even the frontend tooling today is very heavy and slow, and I'm in a 2020 MBP. I don't think we progressed much. React is an amazing idea (and the implementation is great), but the community has become too dogmatic.

michaelpb 6y ago
A few years ago when teaching at a previous coding bootcamp that started with FE JavaScript, I remember my surprise when well-performing students got through 3 months or so of it and were confused and very impressed when I showed them how an <a> tag worked, since they had only been aware of (jQuery) JavaScript powered pages. When you are stuck just doing JS powered SPAs, an <a> tag seems like advanced technology! I ended up at a new school creating a new curriculum. This approach is where we "recapitulate the evolution of the web", so we start with SSGs & server-side programming (Python/Django), then only at the end cover SPAs and React.JS -- since, as you mentioned, that's still the main skillset that companies are new devs for.

grishka 6y ago

As an Android developer who's now making a hobby project that has a web UI, I don't understand it either. I'm doing it the old-fashioned way and it's so fast that my browser doesn't have the time to display a loading animation when I refresh the page.

nicbou 6y ago

In the end, I just end up using Firefox' reader mode, because what I really want is the main article. Everything else is noise.

ziftface 6y ago

The fact is, the Javascript ecosystem is unmatched when it comes to very quickly creating frontend applications. Maybe another set of tools would have been better, but that doesn't really matter. This set of tools is what everyone uses, and a lot of effort and creativity goes into making js frontend development as smooth and fast as possible. I often need to very quickly make internal services at my job and while I like working in other languages (and i do for longer term projects), those always take longer to set up and get working. In js with next you're up and running in less than 60 seconds and if you're doing crud stuff, most of the work is frankly done for you.

anderspitman 6y ago
The cost of developing in JS isn't necessarily lower, just amortized. Or in many cases, externalized to your users.
- ziftface 6y ago
  > externalized to your users You mean if you have customers with less powerful devices like the OP? I don't really see internal services or B2B products having that problem.
  - anderspitman 6y ago
    You original point > the Javascript ecosystem is unmatched when it comes to very quickly creating frontend applications Didn't hinge on whether you were creating internal tools or not. You simply used internal tools as an example of what you personally do with JS.
    - ziftface 6y ago
      I see your point, and I agree it's definitely not a good solution to some problems. But I think it can be very productive if your constraints allow you to use it.
      - 6y ago

userbinator 6y ago

I'm not either, but I've written quite a few webpages over the years, and even the occasional use of JS, but only when it's not possible to do without. I suspect much of the superfluous JS comes from a " if you have only a hammer, everything looks like a nail" mentality.

carapace 6y ago

Yes, the Emperor is bare-ass naked, now hush before you get someone fired.

srcreigh 6y ago

The two biggest rants on HN are 1) Why doesn't this site work without JavaScript? It's inaccessible. and 2) Why doesn't this app work offline? It invades my privacy. Maybe I'm wrong, but as far as I can tell, you can't have both. Sorry folks. You are right, JS is not needed if the site truly is static content. But if you try to make an interactive app that could be implemented client-side (AKA javascript) and attach a server to it, everybody will complain that the application doesn't respect the user's privacy, since it could be offline-only but it's not. Don't get me wrong, I think "interactive" can meaningfully include a simple site with links if you are looking at it from a privacy angle. Just look at how StackOverflow recently was able to track all the pages their hacker viewed. [1] SO is pretty much static content. So do you want StackOverflow to work without JavaScript? Are you happy that in-so-doing it needs to phone home whenever you look something up? You can't have one without the other. There is also the argument from scalability. You'll get less QPS on your servers if you implement a 3-step form with validation in the frontend, and send off all the data in one go. It's also faster/better UX and is more resilient under bad network conditions. Edge computing is maybe an alternative there, but that doesn't address inherent privacy concerns of phoning home to a server. Last there is the reality of a spectrum of interactivity of websites. If you are doing a blog, sure, don't do it in JS. At that point you make a decision to make it difficult to add any interactive features to you site which require JS. If you are building an evolving app with interactive features, there aren't many options for easily mixing static HTML with interactive JS. You could see how far you get with static HTML but then what if you need interactivity (JS/JQuery)? What if you need complex interactivity (React)? Are you willing to pay the costs of a heterogeneous app architecture of HTML mixed with interactive JS? Think of Facebook. It is kinda like a blog, but what about infinite scroll? Etc. Anyway that last point, I think, is why people are excited about 37signals' Hotwire[2]. It's more of a HTML-but-interactive architecture as opposed to the fully-interactive JS/React vs static HTML forms. [1]: https://stackoverflow.blog/2021/01/25/a-deeper-dive-into-our-may-2019-security-incident/ https://stackoverflow.blog/2021/01/25/a-deeper-dive-into-our... [2]: https://hotwire.dev/ https://hotwire.dev/

kaba0 6y ago
I don’t understand your second point. Which web app works offline?? (Unless they are deliberately made for that purpose. Hell, even most electron apps refuse to work without a connection) They regularly make new requests, there is literally no difference between SSR and CSR in this regard - it seems a bit that you are arguing with a straw men. Like, what does a webshop do which is written in react/whatever and you go to the next “page”, it hadn’t loaded yet? Also, noone would even think that it is unreasonable for a WEBapp to phone home. What people have trouble with is tracking, that is orthogonal to the current topic and should be condemned.

throw_m239339 6y ago

> Whats with all the javascript? On blogs and news media site? mostly ad tech . The irony is that it took AMP, a proprietary solution, for all these websites that mainly deal with text and image, to start cracking down on all that stuff. Remember "mobile first"? Well the majority of web developers clearly do not have a Mobile first strategy, when you look at how heavy their webpages are. Even the javascript could be lighter, but since everybody is using node.js and NPM behind the scene with a lot of complex modules, well code bundles become crazy big.

csomar 6y ago

It's a bit more complicated than that. Modern web development done correctly can help: Pages are generated in the server, no JavaScript required. If you start with a PWA mentality, then your application/site is progressive and you should cover everyone; or almost. However: 1- Progressive is expensive. You'll need more time as you need to sort what features can work; and work your way up to the full experience. The full experience, however, is what you are getting paid for (or showing). Unless the client or the company cares about these categories, you don't want to expend budget on that. 2- Web development is becoming complicated. You can get started quickly with Nextjs/Gatsby thanks to "DX"(Developer Experience). The reality is that you don't understand much of what's going on behind the surface and if you bootcamp-ed your way in 3 months, you probably have no idea what's going on. But it works!

moring 6y ago

> Whats with all the javascript What's with all the server round-trips? If you have a UI that takes user input and just reacts to it, without any data needed from the server -- why should it go on a full round-trip just to get a new UI element that it could create locally just as well? Look at other things on your computer: a text editor, or a calculator. Would you expect every interaction to send a request to some remote server just for the sake of it?

smaudet 6y ago
Shitty server code isn't an excuse for shitty frontend code though. Moreover you are confounding apps with the web. A calculator should probably never use the network... Pretty much every web browser can and has to open and send network packets - as long as they are small and there is not a lot of state, you are fine. You can support almost any device from 20, 30 years ago. 'Modern' JS dogpiles huge swathes of mostly unused, uncompiled code, resulting in huge network transfer costs, extreme overusage of CPU and RAM, and encourages a lot of e-waste because it mainly only works well with the latest devices... It's arguable that this is such a bad engineering design, just to save some network packets, I wouldn't be surprised if the carbon footprint of a JS developer was at least similar to that of burning coal...

datagram 6y ago

I think the bloat comes from a few places: Developer productivity: Making complex pages and reusing components across pages is much easier with a library like React than with more vanilla approaches. For a lot of companies with large numbers of engineers, making sure that engineers can be productive without intimate knowledge of HTML/CSS ends up taking priority over things like performance and accessibility. Branding/customization: The built-in HTML controls are difficult/impossible to style or customize. A lot of UI designers will design some fancy looking select dropdown, not appreciating the fact that they're forcing developers to reinvent the wheel in order to implement their design. Alternatively, there are cases where the UX for built-in controls is lacking enough that you're somewhat forced to implement a replacement (e.g. <select multiple>)