A Modern Frontend Web Development Guide
-
Someone wrote up a guide on web dev. Since it's written by a web dev, it's a markdown file on github.
All jokes aside it seems interesting. But I came across this quote and it made me laugh (emphasis added):
…Meanwhile, the tools that were used to create websites became more advanced as the web became more vital and companies began competing to attract visitors using the latest in fancy web technology. This technology was used for one primary purpose: creating user interfaces. And it became really good at it.
😂😂😂
(On SPAs and client-side rendering):
Well, as convenient as that was (to avoiding repeating the same HTML all over the place), it required there be a server that did all the heavy-lifting, assembling each one of these pages and sending the HTML back to clients. That's problematic for several reasons:
…
- More importantly, it requires that someone run and maintain one of these PHP servers
Well, with client-side rendering and single-page apps, you can now put all of that logic into the client-side javascript and ship most of your website, except the database (essentially) as static files that can be hosted anywhere! … The database portion continues to live on the server and now just provides a RESTful API.
-
Whoops I posted this in the wrong section.
-
@bb36e Moved to the sidebar.
-
I love how he bitches about needing servers for PHP then goes on about having NodeJS as though it's somehow magically different.
Thick client is still retarded in this environment and offloading too much to the client can't go well...
-
@Arantor said in A Modern Frontend Web Development Guide:
then goes on about having NodeJS as though it's somehow magically different.
In his defense, he moved half of his app to CDNs, making it impossible to debug performance issues in prod and tying your uptime to your provider's uptime. If only there was some way to outsource server management instead, so you could still manage your performance and debug issues with direct access but pay someone else to keep it running. Maybe with some stupid name, something about weather or some crap seems appropriate.
-
@Yamikuronue said in A Modern Frontend Web Development Guide:
something about weather or some crap
Sorry the word Shit Storm is already in use
-
@Yamikuronue said in A Modern Frontend Web Development Guide:
In his defense, he moved half of his app to CDNs, making it impossible to debug performance issues in prod and tying your uptime to your provider's uptime.
Why can't you debug performance issues?
Putting static assets onto a CDN is considered best practice, if you have a passive CDN setup and a cache buster there generally isn't a problem.
Also surely unless you are hosting yourself this is true of any cloud computing platform?
-
@lucas1 I mean, you can, but we've had serious issues with that sort of thing at my job. the CDN goes down, or it starts routing things funny, you have no control or insight into what happened, just users reporting performance issues. Something gets cached weird, the CDN doesn't handle it right, you get issues you can't fix. et cetera.
-
In almost every website I have deployed you have a switch in a config file somewhere to turn the CDN and a helper method e.g.
<script src="<% MyHelperClass.PrePrendCDN("~/path/to/src.js") %>" />Or something roughly equivalent.
