7 ms·

What's old is new again. I recall ASP.NET had some interesting tech around this in the 2000s where it could dynamically update parts of the page. If I recall c

What's old is new again. I recall ASP.NET had some interesting tech around this in the 2000s where it could dynamically update parts of the page. If I recall correctly, this made use of that new technology of the time called "XMLHttpRequest" (/s) which pretty much jump-started web 2.0.

vittore 6y ago
good ol' ASP.NET 2.0
recursive 6y ago
AjaxContentPanels or something to that effect. Those things were a nightmare. At the time, asp.net pretended to be stateful by bundling up the entire state of the page into "ViewState" and passing it back and forth client to server. Getting that to work with those panels was more work than just ajax-ing the content and injecting it with jquery. In the Microsoft-verse, this might also draw some comparisons to the more modern server-side blazor.
- mmastrac 6y ago
  Oh yeah. I remember that ViewState could reach 100s of KBs on a page if you weren't careful. It was a huge juggling act between keeping state in your input fields vs ViewState.
- toddwprice 6y ago
  <UpdatePanel /> see here: https://docs.microsoft.com/en-us/dotnet/api/system.web.ui.updatepanel?view=netframework-4.8 https://docs.microsoft.com/en-us/dotnet/api/system.web.ui.up... I used it 13 years ago. It was fancy.
axegon_ 6y ago
My thought exactly, though I fully support that. I often rant about how the modern web is billions of layers of duck tape over duck tape and it has become an unmanageable mess of libraries, frameworks, resources, all while javascript remains the most outrageous and absurd language ever created. I'm by no means a fan of rails or ruby for that matter but I think things like these are a considerably better alternative than all the ridiculous libraries and frameworks everyone uses, which result megabytes of javascript and require corporate-grade bandwidth and at least an 8-th gen i7 and at least 8gb of memory to open. And all that to open a website which has 3 images and a contact form. I mean someone should create a package that analyzes websites and creates a minimum requirements manifest. It's good to see that there are people who are trying to bring some sanity.
- ChrisLTD 6y ago
  Preach! Websites don’t seem all that much better to me than they did 10 years ago [^fn], so what are we gaining with all these much more complex and fragile tools? [fn]: Arguably, the web is worse with chat bots, sticky headers, and modals constantly vying for your attention.
  - craftinator 6y ago
    > Arguably, the web is worse with chat bots, sticky headers, and modals constantly vying for your attention. We can blame this on the MBA types. I've literally never heard a software engineer say "hey, let's make this pop-up after they've already been looking at the page for a minute!" or anything like it.
    - rorykoehler 6y ago
      Engineers typically aren’t tasked with increasing revenue/engagement.
      - Nextgrid 6y ago
        Unfortunately I have to disagree - if there weren't any engineers around to implement the dark patterns they wouldn't be as prevalent. Maybe this calls for an equivalent of the Hippocratic Oath but in the tech world?
        rorykoehler 6y ago
        Brick layers. Developers develop, designers design was more my point, though of course this line is blurred in many organisations.
- rektide 6y ago
  There is plenty of duck tape yes, But there is suprisingly little layers on layers. Part of what has been amazing about the web is that the target remains the same. There is the DOM. Everyone is trying different ways to build & update the DOM. Agreed that there are better alternatives than a lot of what is out there. We seem to be in a mass consolidation, focusing around a couple very popular systems. I am glad to see folks like Github presenting some of the better alternatives, such as their Catalyst tools[1] which speed up (developer-wise & page-wise (via "Actions") both) & give some patterns for building WebComponents. The web has been unimaginably stable a platform for building things, has retained it's spirit while allowing hundreds of different architectures for how things get built. Yes, we can make a mess of our architectures. Yes, humanity can over-consume resources. But we can also, often, do it right, and we can learn & evolve, as we have done so, over the past 30 years we've had with the web. [1] https://github.github.io/catalyst/ https://github.github.io/catalyst/
shireboy 6y ago
Glad I'm not the only one seeing that parallel. I'd be hesitant to use this for that reason, but maybe that's bias on my part? Just seems like you'd get stuck in a similar mess of "special" updatepanels aka hotwire frames that are trying to "save you from having to write javascript". Except it still uses javascript under the covers, so you still have whatever issues that may entail, only now it's more removed from the developer to be able to solve.
deleted 6y ago
[deleted]
hn_throwaway_99 6y ago
Interesting bit of history (and yes, I see the /s), XMLHttpRequest was actually invented by Microsoft in Explorer because the Outlook team needed better responsiveness for the web email client.
grishka 6y ago
Is this that web framework from Microsoft that hid the transaction-orientedness of HTTP from you by letting you set server-side click listeners on buttons and generated all the code needed to glue it all together? At the time, I didn't feel good about it because it abstracted away too much, and required Windows on the server. Little did I know about all the ways people would start abusing JS in 10 years.
merb 6y ago
webforms is dead, long live webforms.
EdwardDiego 6y ago
Yep, was using this approach in Java server-side frameworks 12 years ago.
hinkley 6y ago
jquery also had a function for doing swaps. Then there's Rails turbolinks, and now Phoenix LiveView in Elixir. I don't know if it's so much 'everything old is new again' as it is a problem of market penetration.
msie 6y ago
We need something like XMLHttpRequest right now. Google should integrate Dart into Chrome.

vittore 6y ago

good ol' ASP.NET 2.0

recursive 6y ago

AjaxContentPanels or something to that effect. Those things were a nightmare. At the time, asp.net pretended to be stateful by bundling up the entire state of the page into "ViewState" and passing it back and forth client to server. Getting that to work with those panels was more work than just ajax-ing the content and injecting it with jquery. In the Microsoft-verse, this might also draw some comparisons to the more modern server-side blazor.

mmastrac 6y ago
Oh yeah. I remember that ViewState could reach 100s of KBs on a page if you weren't careful. It was a huge juggling act between keeping state in your input fields vs ViewState.
toddwprice 6y ago
<UpdatePanel /> see here: https://docs.microsoft.com/en-us/dotnet/api/system.web.ui.updatepanel?view=netframework-4.8 https://docs.microsoft.com/en-us/dotnet/api/system.web.ui.up... I used it 13 years ago. It was fancy.

axegon_ 6y ago

My thought exactly, though I fully support that. I often rant about how the modern web is billions of layers of duck tape over duck tape and it has become an unmanageable mess of libraries, frameworks, resources, all while javascript remains the most outrageous and absurd language ever created. I'm by no means a fan of rails or ruby for that matter but I think things like these are a considerably better alternative than all the ridiculous libraries and frameworks everyone uses, which result megabytes of javascript and require corporate-grade bandwidth and at least an 8-th gen i7 and at least 8gb of memory to open. And all that to open a website which has 3 images and a contact form. I mean someone should create a package that analyzes websites and creates a minimum requirements manifest. It's good to see that there are people who are trying to bring some sanity.

ChrisLTD 6y ago
Preach! Websites don’t seem all that much better to me than they did 10 years ago [^fn], so what are we gaining with all these much more complex and fragile tools? [fn]: Arguably, the web is worse with chat bots, sticky headers, and modals constantly vying for your attention.
- craftinator 6y ago
  > Arguably, the web is worse with chat bots, sticky headers, and modals constantly vying for your attention. We can blame this on the MBA types. I've literally never heard a software engineer say "hey, let's make this pop-up after they've already been looking at the page for a minute!" or anything like it.
  - rorykoehler 6y ago
    Engineers typically aren’t tasked with increasing revenue/engagement.
    - Nextgrid 6y ago
      Unfortunately I have to disagree - if there weren't any engineers around to implement the dark patterns they wouldn't be as prevalent. Maybe this calls for an equivalent of the Hippocratic Oath but in the tech world?
      - rorykoehler 6y ago
        Brick layers. Developers develop, designers design was more my point, though of course this line is blurred in many organisations.
rektide 6y ago
There is plenty of duck tape yes, But there is suprisingly little layers on layers. Part of what has been amazing about the web is that the target remains the same. There is the DOM. Everyone is trying different ways to build & update the DOM. Agreed that there are better alternatives than a lot of what is out there. We seem to be in a mass consolidation, focusing around a couple very popular systems. I am glad to see folks like Github presenting some of the better alternatives, such as their Catalyst tools[1] which speed up (developer-wise & page-wise (via "Actions") both) & give some patterns for building WebComponents. The web has been unimaginably stable a platform for building things, has retained it's spirit while allowing hundreds of different architectures for how things get built. Yes, we can make a mess of our architectures. Yes, humanity can over-consume resources. But we can also, often, do it right, and we can learn & evolve, as we have done so, over the past 30 years we've had with the web. [1] https://github.github.io/catalyst/ https://github.github.io/catalyst/

shireboy 6y ago

Glad I'm not the only one seeing that parallel. I'd be hesitant to use this for that reason, but maybe that's bias on my part? Just seems like you'd get stuck in a similar mess of "special" updatepanels aka hotwire frames that are trying to "save you from having to write javascript". Except it still uses javascript under the covers, so you still have whatever issues that may entail, only now it's more removed from the developer to be able to solve.

deleted 6y ago

[deleted]

hn_throwaway_99 6y ago

Interesting bit of history (and yes, I see the /s), XMLHttpRequest was actually invented by Microsoft in Explorer because the Outlook team needed better responsiveness for the web email client.

grishka 6y ago

Is this that web framework from Microsoft that hid the transaction-orientedness of HTTP from you by letting you set server-side click listeners on buttons and generated all the code needed to glue it all together? At the time, I didn't feel good about it because it abstracted away too much, and required Windows on the server. Little did I know about all the ways people would start abusing JS in 10 years.

merb 6y ago

webforms is dead, long live webforms.

EdwardDiego 6y ago

Yep, was using this approach in Java server-side frameworks 12 years ago.

hinkley 6y ago

jquery also had a function for doing swaps. Then there's Rails turbolinks, and now Phoenix LiveView in Elixir. I don't know if it's so much 'everything old is new again' as it is a problem of market penetration.

msie 6y ago

We need something like XMLHttpRequest right now. Google should integrate Dart into Chrome.