7 ms·

I think modern web misery all stems from an industry problem. Everywhere I've worked, I have insisted on building things with basic semantic HTML, hand coded CS

I think modern web misery all stems from an industry problem. Everywhere I've worked, I have insisted on building things with basic semantic HTML, hand coded CSS, and vanilla JS where precisely needed. Nobody listens. You can make something that loads 50x-100x faster, works responsively on every device, has energy efficient rendering, and the UI/UX is dead simple to use and familiar to all people. And yet... at least for me, I have to fight against every client, employer, and coworker to execute this approach. Maybe web developers as a whole just got bored. They don't want to make webpages like they did in 2002. Make a folder with some .HTML, .CSS, .JS files. Then sync it to a linux box. Wow, you're on the internet, a modern marvel. I see younger devs who don't even know this basic stuff. As if, this were all way more complicated than it actually is. It's not. How do we get web devs back on track? Makers need to thoroughly understand their tools and materials, inside and out, for any industry. I'm just not seeing that as much anymore. It seems like an education problem, or maybe it's just human nature to go for new and shiny instead of practical and reliable.

snazz 6y ago
I'm agreeing with you that the "modern web" is too complex, but the "make a folder and sync it to a Linux box" solution doesn't work very well for real-world use. It's easier and a lot faster to sync your static site to something like S3 or Google Cloud Storage and serve it from there. Now you don't need to secure and update your Linux box or be responsible for its uptime.
- Frost1x 6y ago
  >It's easier and a lot faster to sync your static site to something like S3 or Google Cloud Storage and serve it from there. Now you don't need to secure and update your Linux box or be responsible for its uptime. I was pushing to *nix hosts I didn't have to manage in early 2000. Actually, one of them I recently remembered and had paid a small lifetime membership for limited static hosting (<$100) and simple shell access and guess what--the pages I put together 20 years ago and supplemental files I had hosted are still there. Not only that, they still render as intended. I've done absolutely nothing for 20 years at this specific host and it's working today. Yes, the content is fairly static and very simple (its 20 years old) but it's all there. It's a simple shared system and no it wouldn't scale out to support more than probably 10k simultaneous requests but its served its purpose over the years. No, there's no SLA. I'm not saying services like S3 haven't been able to improve on that older infrastructure but it goes to show what very simple systems are capable of. I've not spent a second of time in 20 years worrying about security, someone else did for a very nominal fee. This isn't a new concept, now we have better scaling available for sure.
amw-zero 6y ago
I agree with the sentiment of what you're saying, but I don't agree with the premise that there are no use cases for single page apps. You can achieve a decent UX for some applications by using small amounts of vanilla JS, but it's simply not possible to avoid re-rendering the entire page without using XHR requests at some point. That is how the browser is designed, fundamentally. Because it wasn't designed as an application platform, it was designed as a document platform. But some products are actually better as applications, not interconnected documents. For those applications, the browser fights you every step of the way, because that's not what it's designed for. You simply can't compare the UX of document-based web applications to native clients. An SPA is just the web approximation of a native client. Your application truly runs in the client process continuously, so rendering transitions happen smoothly instead of blank pages and jumping transitions. Everyone would benefit from understanding more and using that to simplify all areas of the tech stack, but the experience that an SPA offers is simply not possible otherwise.
- systemvoltage 6y ago
  SPA is a poor approximation of a native client with a hugely bloated browser stuck in some level of the abstraction, bypassing native app libraries, design sensibilities, typography guidelines and accessibility by implementing some UI framework that was developed by people that are entirely unqualified for it. Have you looked it the guidelines for UI development, say for MacOS? Here you go: https://developer.apple.com/design/human-interface-guidelines/ https://developer.apple.com/design/human-interface-guideline... PWAs, browser apps - they bypass all this work from professionals and give it in the hands of an unequiped developer. Oh god. A browser is a window, an area of the screen that is allowed to do whatever it wants in a sandbox mode. This is a terrible idea. It becomes complete wild-wild-west.
- dexen 6y ago
  >it's simply not possible to avoid re-rendering the entire page without using XHR Wrong on two separate levels. First up, technologies like iframes, frames, and objects/embeds allow that just fine; you can use at least some of them without any JS whatsoever. Secondly, with avoiding re-rendering you end up avoiding a 200ms ... 500ms load+render of simple full page, at the cost of doing 2...5 seconds of gradual load+render of various bits and pieces. Bits and pieces that often are so unwieldy they cause widgets & content to load gradually, jump around, and sometimes even get hidden behind a loader. While the CPU fan keeps whining at full revs. The solution became worse than the problem it purported to solve, and your users pay the price in wasted time + RAM + electricity. If you pay even a little attention to order of loading you can avoid FOUC entirely. If you pay a little attention to defining sizes of leading elements, you'll have constant layout of the top part of the page, and avoid flash of white background. If you use anchors here and there your user will be scrolled to the proper position. Yes your page can easily look as if it got only updated with JS after doing a full load+render. The technology is already in the browser; no need to approximate it with three layers of JS.
systemvoltage 6y ago
Please write more about this because I feel the exact same. Use built in HTML forms. Let the page refresh, what's wrong with going to `/orders/{order_id}` page to get information about the order? It is REST-ful and static. Why do you want things moving around and reacting? People of the internet - imagine if the internet protocols were given to us, but no browser existed. Would we develop this non-sense we have today? What should have happened is the following: - Develop web-to-native-UI mapper, call that thing a browser. - Don't let developers style native elements. A drop down should not be designed by people except for the owners of the OS. Yes, it looks different on different OS but your application should be more than putting lipstick on a pig. - Accept the fact that your application looks different on different OS'es but embrace the fact that your application works intuitively to the users, you have much less to maintain and focus on the logic of your app. The web went downhill the day `<input>` tag was allowed to be styled by CSS. We had a web-to-native-UI mapper! I am forever a believer that democratically designed things generally suck unless there is a BDFL who can make shots. Dictatorship is a necessity of great products and services - Steve Jobs to Guido, democracy is good in politics, not in software development. Feature creep from the public will ruin whatever youre buidling. Designers will ravage through what worked well and replace it with "taste". /Rant, I am getting old. Humans tried to make the web "pop", but instead it exploded with chaos.
- userbinator 6y ago
  Let the page refresh, what's wrong with going to `/orders/{order_id}` page to get information about the order? It is REST-ful and static Exactly. As a bonus, you automatically get the behaviour associated with a link that browsers already implement: people can bookmark a link for later use, open it in a new window, etc. All of which would need extra effort (and thus also easily break) if it was just a clickable element invoking some JS. I've had some pretty annoying conversations with customer support and developers about things like this; almost always, the response is something like "we didn't think you would have a need to do that". They would not have needed to think about it at all, and it would work for me, if they had just used a regular link. That said I'm not totally opposed to SPAs; highly interactive apps, e.g. realtime games and such, would definitely benefit as they wouldn't really make sense as a linked set of documents. But for everything else it feels like they not only reinvent the wheel, but make it square.
Frondo 6y ago
Just chiming in to say this is an absolutely viable approach. I just built a project, over about six weeks, using mostly vanilla js and some jquery (the heaviest widget I have is tinymce, which is a necessity unfortunately), and started selling it about two weeks in. I'm up to $650 mrr and the sky's the limit (really, the market is huge and desperately underserved), and not one person has complained about it acting like an old style website. People are just happy it works. And mobile testing was a breeze. If I tried to build this on a "modern" stack I cannot imagine any benefit, only drawbacks.
- cosmojg 6y ago
  Got a link? I'm curious what your end product looks like.
  - Frondo 6y ago
    So unfortunately the live project has no public-facing component; without going into too much detail it helps certain corporations and larger nonprofits with a kind of compliance. But, I can tell you that I based it very closely on the layouts provided by the ultra lightweight css framework, PureCSS. (This is also my favorite framework!) https://purecss.io https://purecss.io The layouts are here: https://purecss.io/layouts/ https://purecss.io/layouts/ One other remark: people are happy when they learn about this. That is now my #1 predictor of success. Everyone I've demoed to has adopted the product within a day (usually during the demo), and tech wise it's no different from what was possible with the web 15 years ago.
commandlinefan 6y ago
> loads 50x-100x faster And takes less time to develop in the first place! These frameworks just seem like pure overhead to me.
- shard972 6y ago
  As someone who uses React/Mithril and has just been hired to work mostly on jQuery, you obviously haven't had to build something more complicated than a wordpress blog.
- mmis1000 6y ago
  You end up dupe your layout page everywhere and have a hard time update all of them if designer changed their mind. Or you could use some template system to do that… but if you need to use template, why not use react(or something like that) anyway?
  - goatlover 6y ago
    Because Rails, Symphony, Django, Phoenix or whatever does the job in the preferred language of the developer/team and often has more batteries or better tooling included.
    - mmis1000 6y ago
      I bet those are not a Front end's preferred language and you end up need JavaScript anyway if you need some extra client form handling. Now you use two language to do one thing and made it more difficult to be maintained.
  - grey-area 6y ago
    That problem was solved approx 20 years ago. The alternatives are not react and templates vs writing html by hand.
  - benibela 6y ago
    The browsers had support for XSL templates You write your website in XML and the browser renders it using the template
bluetwo 6y ago
100% agree. KISS - Keep It Simple, Stupid - Never let me down.

snazz 6y ago

I'm agreeing with you that the "modern web" is too complex, but the "make a folder and sync it to a Linux box" solution doesn't work very well for real-world use. It's easier and a lot faster to sync your static site to something like S3 or Google Cloud Storage and serve it from there. Now you don't need to secure and update your Linux box or be responsible for its uptime.

Frost1x 6y ago
>It's easier and a lot faster to sync your static site to something like S3 or Google Cloud Storage and serve it from there. Now you don't need to secure and update your Linux box or be responsible for its uptime. I was pushing to *nix hosts I didn't have to manage in early 2000. Actually, one of them I recently remembered and had paid a small lifetime membership for limited static hosting (<$100) and simple shell access and guess what--the pages I put together 20 years ago and supplemental files I had hosted are still there. Not only that, they still render as intended. I've done absolutely nothing for 20 years at this specific host and it's working today. Yes, the content is fairly static and very simple (its 20 years old) but it's all there. It's a simple shared system and no it wouldn't scale out to support more than probably 10k simultaneous requests but its served its purpose over the years. No, there's no SLA. I'm not saying services like S3 haven't been able to improve on that older infrastructure but it goes to show what very simple systems are capable of. I've not spent a second of time in 20 years worrying about security, someone else did for a very nominal fee. This isn't a new concept, now we have better scaling available for sure.

amw-zero 6y ago

I agree with the sentiment of what you're saying, but I don't agree with the premise that there are no use cases for single page apps. You can achieve a decent UX for some applications by using small amounts of vanilla JS, but it's simply not possible to avoid re-rendering the entire page without using XHR requests at some point. That is how the browser is designed, fundamentally. Because it wasn't designed as an application platform, it was designed as a document platform. But some products are actually better as applications, not interconnected documents. For those applications, the browser fights you every step of the way, because that's not what it's designed for. You simply can't compare the UX of document-based web applications to native clients. An SPA is just the web approximation of a native client. Your application truly runs in the client process continuously, so rendering transitions happen smoothly instead of blank pages and jumping transitions. Everyone would benefit from understanding more and using that to simplify all areas of the tech stack, but the experience that an SPA offers is simply not possible otherwise.

systemvoltage 6y ago
SPA is a poor approximation of a native client with a hugely bloated browser stuck in some level of the abstraction, bypassing native app libraries, design sensibilities, typography guidelines and accessibility by implementing some UI framework that was developed by people that are entirely unqualified for it. Have you looked it the guidelines for UI development, say for MacOS? Here you go: https://developer.apple.com/design/human-interface-guidelines/ https://developer.apple.com/design/human-interface-guideline... PWAs, browser apps - they bypass all this work from professionals and give it in the hands of an unequiped developer. Oh god. A browser is a window, an area of the screen that is allowed to do whatever it wants in a sandbox mode. This is a terrible idea. It becomes complete wild-wild-west.
dexen 6y ago
>it's simply not possible to avoid re-rendering the entire page without using XHR Wrong on two separate levels. First up, technologies like iframes, frames, and objects/embeds allow that just fine; you can use at least some of them without any JS whatsoever. Secondly, with avoiding re-rendering you end up avoiding a 200ms ... 500ms load+render of simple full page, at the cost of doing 2...5 seconds of gradual load+render of various bits and pieces. Bits and pieces that often are so unwieldy they cause widgets & content to load gradually, jump around, and sometimes even get hidden behind a loader. While the CPU fan keeps whining at full revs. The solution became worse than the problem it purported to solve, and your users pay the price in wasted time + RAM + electricity. If you pay even a little attention to order of loading you can avoid FOUC entirely. If you pay a little attention to defining sizes of leading elements, you'll have constant layout of the top part of the page, and avoid flash of white background. If you use anchors here and there your user will be scrolled to the proper position. Yes your page can easily look as if it got only updated with JS after doing a full load+render. The technology is already in the browser; no need to approximate it with three layers of JS.

systemvoltage 6y ago

Please write more about this because I feel the exact same. Use built in HTML forms. Let the page refresh, what's wrong with going to `/orders/{order_id}` page to get information about the order? It is REST-ful and static. Why do you want things moving around and reacting? People of the internet - imagine if the internet protocols were given to us, but no browser existed. Would we develop this non-sense we have today? What should have happened is the following: - Develop web-to-native-UI mapper, call that thing a browser. - Don't let developers style native elements. A drop down should not be designed by people except for the owners of the OS. Yes, it looks different on different OS but your application should be more than putting lipstick on a pig. - Accept the fact that your application looks different on different OS'es but embrace the fact that your application works intuitively to the users, you have much less to maintain and focus on the logic of your app. The web went downhill the day `<input>` tag was allowed to be styled by CSS. We had a web-to-native-UI mapper! I am forever a believer that democratically designed things generally suck unless there is a BDFL who can make shots. Dictatorship is a necessity of great products and services - Steve Jobs to Guido, democracy is good in politics, not in software development. Feature creep from the public will ruin whatever youre buidling. Designers will ravage through what worked well and replace it with "taste". /Rant, I am getting old. Humans tried to make the web "pop", but instead it exploded with chaos.

userbinator 6y ago
Let the page refresh, what's wrong with going to `/orders/{order_id}` page to get information about the order? It is REST-ful and static Exactly. As a bonus, you automatically get the behaviour associated with a link that browsers already implement: people can bookmark a link for later use, open it in a new window, etc. All of which would need extra effort (and thus also easily break) if it was just a clickable element invoking some JS. I've had some pretty annoying conversations with customer support and developers about things like this; almost always, the response is something like "we didn't think you would have a need to do that". They would not have needed to think about it at all, and it would work for me, if they had just used a regular link. That said I'm not totally opposed to SPAs; highly interactive apps, e.g. realtime games and such, would definitely benefit as they wouldn't really make sense as a linked set of documents. But for everything else it feels like they not only reinvent the wheel, but make it square.

Frondo 6y ago

Just chiming in to say this is an absolutely viable approach. I just built a project, over about six weeks, using mostly vanilla js and some jquery (the heaviest widget I have is tinymce, which is a necessity unfortunately), and started selling it about two weeks in. I'm up to $650 mrr and the sky's the limit (really, the market is huge and desperately underserved), and not one person has complained about it acting like an old style website. People are just happy it works. And mobile testing was a breeze. If I tried to build this on a "modern" stack I cannot imagine any benefit, only drawbacks.

cosmojg 6y ago
Got a link? I'm curious what your end product looks like.
- Frondo 6y ago
  So unfortunately the live project has no public-facing component; without going into too much detail it helps certain corporations and larger nonprofits with a kind of compliance. But, I can tell you that I based it very closely on the layouts provided by the ultra lightweight css framework, PureCSS. (This is also my favorite framework!) https://purecss.io https://purecss.io The layouts are here: https://purecss.io/layouts/ https://purecss.io/layouts/ One other remark: people are happy when they learn about this. That is now my #1 predictor of success. Everyone I've demoed to has adopted the product within a day (usually during the demo), and tech wise it's no different from what was possible with the web 15 years ago.

commandlinefan 6y ago

> loads 50x-100x faster And takes less time to develop in the first place! These frameworks just seem like pure overhead to me.

shard972 6y ago
As someone who uses React/Mithril and has just been hired to work mostly on jQuery, you obviously haven't had to build something more complicated than a wordpress blog.
mmis1000 6y ago
You end up dupe your layout page everywhere and have a hard time update all of them if designer changed their mind. Or you could use some template system to do that… but if you need to use template, why not use react(or something like that) anyway?
- goatlover 6y ago
  Because Rails, Symphony, Django, Phoenix or whatever does the job in the preferred language of the developer/team and often has more batteries or better tooling included.
  - mmis1000 6y ago
    I bet those are not a Front end's preferred language and you end up need JavaScript anyway if you need some extra client form handling. Now you use two language to do one thing and made it more difficult to be maintained.
- grey-area 6y ago
  That problem was solved approx 20 years ago. The alternatives are not react and templates vs writing html by hand.
- benibela 6y ago
  The browsers had support for XSL templates You write your website in XML and the browser renders it using the template

bluetwo 6y ago

100% agree. KISS - Keep It Simple, Stupid - Never let me down.