4 ms·
old man alert Back in my day, we wrote ASP.NET that was all server-side-rendered HTML. Once in a while we got REAL FANCY and used JQuery to make PARTIAL HTML re
by noveltyaccount 4y ago
old man alert Back in my day, we wrote ASP.NET that was all server-side-rendered HTML. Once in a while we got REAL FANCY and used JQuery to make PARTIAL HTML requests and update only FRAGMENTS of the page. Hooboy I knew that fashion was cyclical but not tech!
- tanepiper 4y agoBack in the days of MySpace, we were working for a client in UK Sports betting (Littlewoods Pools) - and we managed to persuade MySpace to let us have a script tag on the page, pointing to a JS file we controlled. The script injected jQuery, then we replaced the page with HTML fragments. We had an Adobe Air installer, a Flash game and even had an RSS feed. Funnily enough today we're mostly working towards using ESI - which reminds me of mod_include back in the day.
- luckylion 4y agoESI is awesome and really connects "let's just cache it" with "but what if this tiny detail in the footer changes and we'll spent hours refreshing the cache". I would've loved to do more with it, but we added a lot more optimization that need to happen before the cache and require access to the whole page, so now I do a poor man's ESI transparently caching all kinds of widgets and shortcodes (Frankenstein's WP). I guess one could potentially have tiered caches with an optimization layer in the middle and ESI on the backend-facing cache, but that feels extreme and more brittle.
- wvenable 4y agoWebforms has an UpdatePanel control sending partial HTML (and even additional JavaScript) to web pages.
- antoniuschan99 4y agoI wonder if people nowadays know that Ajax (aka. partial HTML requests to update fragments of the page) was a huge leap. Gmail is one of the first to have adopted this paradigm.
- gpvos 4y agoComputer tech has been cyclical since at least the 1960s, mostly moving the cleverness back and forth between the server and the client.
- matwood 4y agoSame. AJAX was around, but quite new. Browser JS engines were hit and miss speed wise. Creating elements in the dom could be super slow depending on the browser. My solution then was to have the server send html as a string and then drop it into an existing element. Felt super hacky at the time haha.
- lukaszkorecki 4y agoI wrote some jQuery-based code to enhance a page rendered by Rails this week, it felt pretty great as compared to waiting for Webpack to do its thing
- nickswan 4y agoThat’s exactly what we are still doing in our bootstrapped SaaS tool! Using asp.net mvc though, not web forms.
- deleted 4y ago[deleted]
- tracker1 4y agoUntil the page gets complex and viewstate gets ugly too... Add in a dialup connection and you were in for worlds of pain. By today's standards of interactivity, I find the modern take (server rendered Blazor) as equally painfully slow to respond.
- seydor 4y agoEqually is putting it midldly. Jquery sites are blazingly fast today. Anything that involves compiled javascript is impossible to load on bad connections.
- 88913527 4y agoReturning html fragments is quite stateful and contextual to the rest of the DOM structure. Ex: You might be referencing class names; is there already a stylesheet loaded that defines those styles? Are those styles actually what you want? I try to avoid these sort of "hidden dependencies" because it makes it harder to reason about a system and make changes to it without unknowingly breaking something.
- ravagat 4y agoI forgot where I saw it but I recently read that McMaster-Carr has their setup with ASP.NET and their website is truly a beautiful form of software
- snorkel 4y agoASP! bah! Perl was all we needed!! Kids these days with the Reacts and Angulars messing up a perfectly fine cyber space that wasn’t broken! “HTML over the wire” hah! Where did all the Netscape buttons go?
- ryloric 4y agoAtleast Fashion runs on yearly cycles, we run on 3-week cycle.