3 ms·
Back in the day, every page of an online store was rendered server-side. One day, someone needed certain elements to call database views and rewrite the dom ins
by noduerme 5y ago
Back in the day, every page of an online store was rendered server-side. One day, someone needed certain elements to call database views and rewrite the dom inside a little area when a user clicked a button. So smart people tried to create frameworks like React that would automate the Dom update and bind the Dom more closely to the data state on the server.
After many years, front end programmers forgot how to build their own hooks and came to rely on automated views. Then they began to forget how to parse models and build controllers. Why not shuffle all that off to the back end anyway?
One nice thing about rolling your own front and back ends is that you can determine when or if each individual subcomponent needs to update its visual state. Often this is very useful in managing the actual server load, but it requires understanding who needs this data immediately and who can load it lazily long after a page loads, or the other data updates server-side, not to mention whether it also has to become readable across a distributed or federated data structure.
So after all the modern conveniences, server side rendering impoverishes both front and back end coders in the name of curing a problem with data transfer and efficiency that is far less of a problem than that of overly tight bindings between front end states and back end data storage.
Anyone can write a tightly bound backend model/view/control..
it's a fun project. It's a horrible architecture.
- nickcox 5y ago> Back in the day, every page of an online store was rendered server-side. One day, someone needed certain elements to call database views and rewrite the dom inside a little area when a user clicked a button. So smart people tried to create frameworks like React I think you skipped a few years there! AJAX, Mootools, prototype, JQuery, etc.
- noduerme 5y agoTotally ;) Between the first and second sentence. I'm still writing a lot of software in that paradigm. Basic AJAX, with nice typescript. JQuery (still super useful for having its own event loop). Underscore JS. Bit of PixiJS to replace the Flash I lost when I need something in canvas. Here's what I won't do: * Move any logic into HTML files * Use any nonstandard tags or inline any code to hook frameworks * Use any frameworks that modify the dom on the fly in any way I'm not 100% in control of. [edit] Here's what I do: Write all data types front/back in NodeJS now, or maintain a 1:1 datatype where PHP is involved that's a perfect mirror of the database table structure; strongly type everything coming in from DB calls before it hits the front end, including types that need to be dehydrated; make outbound objects rewritable to the DB and cached for writing until the time is right, depending on load; maintain high readability without forcing the backend to choke on every single long poler's data update. But hey, take 20 years worth of kids and put them through the same academies and job interviews, eventually they'll be great at answering questions about React and suck at writing useful code.