21–30 of 313 posts
I was recently considering that we went through this cultural shift with computing: we started out by having a system to run code onvdistributed to terminals, then to actual desktop computers, then back to remote with the cloud, and now pushing out to "edge" computing. I'm sure it's more nuanced than that, but we seem to do these cycles, refining our processes.
It seems the trend points to slower and slower websites with more JS bloat. I also notice a increase in JS-errors causing entire sites to malfunction, recently this happened to large apps like Teams and Float
New reddit is painfully slow to login. So much javascript for a simple dialog to load it's absurd.
Pfff - That's completely wrong. SPAs are all about performance. If you want to built a highly-interactive site, it makes sense to do the computing where it's consumed -- in the browser. And hey, if you use a lot of the same logic and data models in the browser as you do on the back-end server, it's only natural to want to try to centralize the code. DRY. The problem is basically what @s_y_n_t_a_x said: developers got carried away with it and starting using SPAs for everything, including sites with low interactivity like blogs, which turned out to be less performant.
> But the web is about presenting content first and foremost!
Says who? I understand that the underlying structures of the web are all about transferring documents and other resources. But Gmail showed us that web 'apps' are useful. Why shouldn't we pursue that? Just because the original web architecture didn't account for it?
In the end, the article makes the right point: Use the right technology for what you're trying to build.
Earlier quoted context omitted.
Be interesting to see if we could start charging website owners fees for them using our processing power to render their site. Something needs to be done to encourage some efficiencies given the fact it takes more resources to surf the internet and read about running a k8s cluster than it does to actually run the cluster
You're free not to use any website...
There are mechanisms to charge for it.
Wouldn't do it any other way. I dipped out of web dev in 2015 to run an ecommerce project. I stopped tracking all the latest js framework news. I settled on a barebones CSS rule set. I stopped choosing SPAs as the starting point for mvp ideas. I shelved Wordpress and moved some content sites over to Netlify and just recently started using a nifty desktop ssr cms instead of Hugo, Gatsby, etc. I was regressing to the e…
> I doubt I'll ever voluntarily use one of those frameworks for web dev. > I do, however, like this thing called, Svelte. Svelte is just another one of “those frameworks”, except with a vastly smaller community: https://trends.google.com/trends/explore?geo=US&q=svelte%20i...
1- There is no simple CSS start point; unless you don't want to be responsive, support mobile/tablets, add a print stylesheet. Then you have thousands of line. Time to add a pre-processor like Sass because CSS was not designed for such complex use cases.
2- There is no simple HTML either. Are you going to memorize how you coded that widget. Maybe use a framework (like bootstrap) to standardize things.
3- JS is not simple too; and the struggle is real. I remember coffeescript and then how EcmaScript 2015 tried to implement some of that nice stuff. Then you have TypeScript, because if your JavaScript is complex enough you might need stronger types.
4- Then you have JS/HTML/CSS; all of the three, interacting with your DOM.
5- Then you have JS interacting with your server; because who wants to reload the page multiple times. And there are different ways to do that too: Ajax, REST, WebSocket, GraphQl.
6- Now that things are getting too complicated, maybe add a build tool in the process (like Grunt) and a package manager too (npm). They might not be that good, so time to build new ones (gulp/webpack/yarn).
tl;dr: Developing for the Web is complicated. Any attempt to make it simple is going to add to the already complex ecosystem which brought us here in the first place.
No, the SPA hype has warn off and people realize that although these new technologies exist, they are not always needed. If you are building a web app, use React or similar. If you are building a web site, use plain HTML+CSS w/ supplemental JS. Sometimes your project can be split in half. Do the landing page, signup, login, privacy policy, etc. in plain HTML. Maybe don't embed all that stuff in your app and you would…
We are not going back full circle. We are facing new challenges and realizing how complex web development is. 1- There is no simple CSS start point; unless you don't want to be responsive, support mobile/tablets, add a print stylesheet. Then you have thousands of line. Time to add a pre-processor like Sass because CSS was not designed for such complex use cases. 2- There is no simple HTML either. Are you going to mem…
> The Dark Age - Somewhere on this path to render pages on the fly (SSR) and render pages on the client (SPA) we forgot about the performance of our webpages. We were trying to build apps. But the web is about presenting content first and foremost! Pfff - That's completely wrong. SPAs are all about performance. If you want to built a highly-interactive site, it makes sense to do the computing where it's consumed -- i…
And we really have come full circle. Gmail performance, at least on Firefox, is awful.