101–110 of 371 posts
In theory, the "modern" frontend frameworks could be useful for a subset of applications. In practice, they are wildly overused, largely (IMHO) because front-end developers have forgotten how to build without them. If I gave this as an example, people would say I'm being unfair to the front-end folks. But since Deno posted it, I think it's fair say that it's overkill to use a front-end framework like React (mentioned…
And the future beyond that will be client-side rendering. In the beginning everything was rendered on the mainframe; then CICS allowed partial screen updates and even dynamic green screen design. Then the early web where everything was server which made the job of web indexing much easier. Then we moved back to rich client apps -- applets, flash, eventually SPAs -- with no way for search engines to easily index thing…
Earlier quoted context omitted.
Not arguing they aren't useful. Just that no backend dev is ever jealous of what's happening with front end frameworks.
Another interesting question : are frontend developers jealous of what the backend developers are doing, or are they not?
Earlier quoted context omitted.
Caching also works for client side rendering of course (you can usually cache the entire client side app so that the browser doesn't have to hit the network at all to start running client side code).
> you can usually cache the entire client side app so that the browser doesn't have to hit the network at all to start running client side code This is also true for Web apps that do not have meaningful amounts of client-side code. > Caching also works for client side rendering There are obviously a lot of differences in how caching works, but client-side caching is generally strictly worse than doing so on the serve…
As an extreme example, something like https://www.photopea.com/ would be a nightmare to use if it was server-side rendered. Or consider something like Google Maps. For things like ecommerce that are mainly focussed on presenting information I agree that client side rendering doesn't make a whole lot of sense. But that isn't the whole web.
If web sites have to so dynamic, I much prefer that the computation involved is done on their machine than on mine. I simply don't trust random web sites enough to let them run code on my machines.
What is it you dont trust? This Fear Uncertainty & Doubt clashes heavily with the excellent security sandbox the web browser is. What is the harm you are afraid of? What are you supposing the risk is/what's in jeapordy here?
And the future beyond that will be client-side rendering. In the beginning everything was rendered on the mainframe; then CICS allowed partial screen updates and even dynamic green screen design. Then the early web where everything was server which made the job of web indexing much easier. Then we moved back to rich client apps -- applets, flash, eventually SPAs -- with no way for search engines to easily index thing…
The client-server wheel of life just keeps turning, and turning, and turning. It's an eternal human truth: each generation yearns to improve on the previous generation's efforts. This server-client zeal to improve has been tremendously productive of good ideas over the last few decades. It will continue. Hopefully saving power and CO2 can be the focus of the next couple of turns of the great wheel.
I wouldn't be shocked if we sooner or later saw language-level support (think of something like Elm, improved) for writing "just" code and then later marking up which parts execute where, and the communications and state synchronization crud and compiling down to the native language is just handled.
It's obviously nonsense. The lowest latency cache and state storage is clientside. You can piss around with multi regions and SSR to minimize latency but that's just placing a lot of regional caches near your users. The nearest place is in their actual browser -> offline first is the future
In theory, the "modern" frontend frameworks could be useful for a subset of applications. In practice, they are wildly overused, largely (IMHO) because front-end developers have forgotten how to build without them. If I gave this as an example, people would say I'm being unfair to the front-end folks. But since Deno posted it, I think it's fair say that it's overkill to use a front-end framework like React (mentioned…
I think this is heavily dependent on company focus (and to some extent - the data requirements of the experience)
Basically - I think you can create a much stronger, more compelling experience on a site for a person with a bad/slow connection with judicious usage of service_workers and a solid front end framework.
But on the flip side... Making that experience isn't trivial, requires up front planning, and most companies won't do it.
> Performance is higher with the server because the HTML is already generated and ready to be displayed when the page is loaded. but the page is loaded later because you have to wait for the server to perform this work. There is no reduction in total work, probably an absolute increase because some logic is duplicated. If there is a speed improvement it is because the server has more clock cycles available than the c…
I really don’t like server side rendering. I like my react apps to be static files served from a plain HTML server.