Hacker News Reader

Comment by martin1b | Hacker News Reader

Reminds me a lot of webforms.. Code behind per page. Page events (OnGet => Page_Load).

It doesn't seem anything like webforms. This looks much more like most other server side templating systems. It just couples the standard HTTP verbs to the templates.

Webforms was this whole other beast that had UI controls connected to the backend which heavily relied on synching state between the backend (through page loads) and front end for user actions on those controls. It did mean you could write a lot of your UI code in your server side language ( C# / VB.NET ).

> UI controls connected to the backend which heavily relied on synching state between the backend...

This sounds like React with SSR or so-called Universal Web Apps.

So that feels like saying ASP.NET AJAX was way ahead of the game. And in some ways it was.

And in other ways you had this massive __VIEWSTATE hidden input field that would have to be sent in order to recreate state. But I will say, it was very cool technology at the time.

The closes thing I think would be a Java Servlet + request forwarding to a JSP page.

But I thought we've moved on from that.

Webforms was all about composition of rich components with an elaborate scheme to hide the fact that everything is playing out over http. This is completely different, it looks more similar to old school php than to webforms.

That was my first impression too. Feels a bit like Webforms done 'right', taking the best part of webforms (page organisation, view-to-code co-location) and the best part of MVC (closer to raw HTTP, no guff around viewstate or pretensions at not being stateless etc).

I didn't know MS was advocating it as the default choice for server side apps however. Does MVC just become a vehicle for exposing rest APIs then? MVC and Razer Pages can co-locate in the same project without issue.

Agreed, not personally a fan. Maybe I've just been using MVC for too long to appreciate the benefits, though..

As someone who has really only learned MVC (I've done some old Webform Umbraco-based stuff which is terrible but I think that's probably more Umbraco's fault) from an organization standpoint this feels much cleaner. I think the only piece that's missing that I don't really understand is being able to manipulate the routing to my will.

I would agree... but perhaps I am looking at it code first. In the past a ThingController could return multiple Views (with possibly different models) for each action Get/Post/etc.

Get -> return View(GetResponseModel) -> Get.cshtml

Post -> return View(PostResponseModel) -> Post.cshtml

Can the Razor OnGet and OnPost only return one "model" to the "page"? It appears the page can only take one model.

OnGet -> ThingModel -> ThingPage

OnPost -> ThingModel -> ThingPage

The entry point Page (aka a View) seems to dictate the model returned and hence limits what type any "Action" can return. Am I reading this right?

And how about returning other types besides 'Pages' - like JSON (a la JSONResult).

Reply on news.ycombinator.com