Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Source code of ASP.NET

github.com

Post reply on HN
Print view View original

91–100 of 104 posts

Re: Source code of ASP.NET

#91

Post by bunderbunder »

skrebbel wrote: post #81
Jaecen wrote: post #56

Earlier quoted context omitted.

"ASP.NET" is the name of Microsoft's .NET web platform. To answer your rhetorical question, ASP.NET MVC is an MVC framework for Microsoft's .NET web platform. "Microsoft MVC" would not be clearly constrained to web development.

"Microsoft's .NET web platform" What does that even mean? In this case, a bunch of libraries and a protocol for dispatching HTTP requests to .NET code. If I use Mono's XSP server, and use it to host a ServiceStack backend, am I using "the ASP.NET platform"? It's 100% non-Microsoft open source. Am I using ASP.net when I host the same backend on IIS instead? Or when I host ASP.NET MVC (which is just a library) on Mono/…

First 4 words of content at https://github.com/mono/xsp are "Mono's ASP.NET hosting server". So yeah, you're using ASP.NET. In the same way that working with Mono is using .NET.

Or maybe not. Perhaps someone means to specify that they're using Mono/XSP as opposed to one of Microsoft's implementations. But then it'll probably be obvious from the context.

Re: Source code of ASP.NET

#92

Post by flomo »

UweSchmidt wrote: post #80
flomo wrote: post #69

Earlier quoted context omitted.

IMO, there was nothing horribly wrong with WebForms itself when it was introduced -- So long as you were writing your HTML by hand and using HtmlControls rather than the drag-n-drop stuff. ViewState was far better than other frameworks that shoved the client state into a server session object and broke the Back button . Plus the clients were saving state instead of wasting server memory. If it got too ugly, you didn'…

There are AJAX controls for webforms, so it hasn't really "broke[n] down hard"? Drag an AJAX control on the form, and whatever is in there, that part of the page will be ajaxed.

I should have added a disclaimer that I haven't worked with web forms in many years, so my commentary is probably not the most infomred. The ajax controls always seemed a bit ugly to me.

Re: Source code of ASP.NET

#93

Post by snarfy »

graycat wrote: post #62
eftpotrm wrote: post #53

Earlier quoted context omitted.

Trust me; that's a good thing. Nasty, deeply misguided platform - whoever came up with the idea of PostBack and trying to make the web look like VB6 is definitely not on my Christmas card list. Ties you in knots trying to make the web something it fundamentally isn't. I'll be quiet now, and get back to working on my MVC code. The day when I can finally stop having to work on WebForms code too will be a happy one :-)

Not a rhetorical question: What's so wrong with Web Forms? Postback? That's really part of HTTP. What the browsers send back to the server is as specified by HTTP, not Microsoft or Web Forms. Viewstate? Okay, it's a bit of a tricky thing, but really can mostly ignore it. Else it provides a somewhat useful service. Controls? Yes, for each HTML 'control', there is an ASP.NET class so to send the HTML for the control to…

Web Forms treats the browser as a dumb terminal. Everything is processed on the server. Javascript is relegated to making the boilerplate work. Almost nothing happens client side.

This is all fine if you are on the local network, but it ignores all the issues that go along with the network, such as latency. There is no silver bullet for latency. It's a physical constraint. The same goes for bandwidth. Throwing an UpdatePanel on the form doesn't solve the problem. Try using a Web Forms page on your phone some time with a 3G connection.

Re: Source code of ASP.NET

#95

Post by graycat »

snarfy wrote: post #93
graycat wrote: post #62

Earlier quoted context omitted.

Not a rhetorical question: What's so wrong with Web Forms? Postback? That's really part of HTTP. What the browsers send back to the server is as specified by HTTP, not Microsoft or Web Forms. Viewstate? Okay, it's a bit of a tricky thing, but really can mostly ignore it. Else it provides a somewhat useful service. Controls? Yes, for each HTML 'control', there is an ASP.NET class so to send the HTML for the control to…

Web Forms treats the browser as a dumb terminal. Everything is processed on the server. Javascript is relegated to making the boilerplate work. Almost nothing happens client side. This is all fine if you are on the local network, but it ignores all the issues that go along with the network, such as latency. There is no silver bullet for latency. It's a physical constraint. The same goes for bandwidth. Throwing an Upd…

Thanks.

Right, Web Forms, and, really, HTTP and HTML, treat the client like a 'dumb terminal', one with some quite amazing capabilities but, still, 'dumb' in that the Web browser is just displaying some pixels and the user is just entering data via the standard HTML 'controls', text boxes, radio buttons, check boxes, etc.

For my site for now, treating the user's Web browser as a dumb terminal is what I wanted. One reason: There is less, hopefully nothing, new for a user to understand about how my user interface (UI) works.

But, yes, at times, a more 'dynamic' Web page could be of interest.

Right, JavaScript running in the client's Web browser can yield much more 'dynamic' Web pages. And, with AJAX, still more can be done to have 'dynamic' pages.

But so far for my Web site, I have yet to write a single line of JavaScript. Somehow ASP.NET writes some JavaScript for me and sends it to the user, but I don't know what that JavaScript code does and hope not to care.

My guess is that if I want to write some JavaScript somehow there is a way in ASP.NET Web Forms for me to do so, i.e., maybe just put my code in the file of JavaScript code that ASP.NET writes and Microsoft's IIS sends.

You mentioned a phone: My Web pages are just dirt simple and each just 800 pixels wide -- I hope that the pages will look good on nearly any device with a Web browser right up to date as of, say, five years ago.

For a 3G connections, at

http://www.pcworld.com/article/253808/3g_and_4g_wireless_spe...

there is a graph of 3G speeds by various vendors, etc. and about the slowest is 0.59 Mbps. Fine with me: One of my Web pages sends, including the JavaScript file, for about 400,000 bits. So, the page should download on the slowest 3G connection in about 1 second. If I take the extra blanks out of the JavaScript ASP.NET writes for me, then the page should load a little faster still.

At least at my site, Web Forms is sending mostly just some HTML; maybe, I don't know, ASP.NET Web Forms is slow on the server, but I'm not seeing just why what Web Forms is doing should be slower for the data transmission or the user's Web browser than some other way of sending HTML.

Re: Source code of ASP.NET

#96

Post by pmelendez »

bunderbunder wrote: post #90
chanced wrote: post #87

Earlier quoted context omitted.

"Uninspired rails port" is a far cry from accurate. I've worked with both rails and asp.net mvc. I started with rails in the 1.x days but also had clients that used .net. I despised web forms for a variety of reasons so I jumped on the mvc bandwagon as soon as the fist community preview was released. Hack, Connery, Hanselman, & Guthrie openly acknowledge that rails was a source of inspiration in their book http://www…

> They opted for configuration over convention. . . I believe you meant "convention over configuration", right?

convention over configuration is the motto on Rails and ASP.Net MVC is actually the opposite so that's why OP says it was the biggest differentiator between the two frameworks.

Re: Source code of ASP.NET

#97

Post by pmelendez »

V-2 wrote: post #85
dev360 wrote: post #30

Earlier quoted context omitted.

I say that a lot and I feel like .NET is loosing relevance. Embracing open source and making Linux a first-class citizen in the eco system would be the only way for .NET to increase adoption or stay technologically relevant, and unfortunately its happening too slow.

Without Linux it's surely doomed. PS. I heard 2015 will be the year of Linux

"PS. I heard 2015 will be the year of Linux"

I heard that too in 2012[0], 2013 [1] and 2014 [2]

[0] http://www.linuxtoday.com/it_management/2012010900341OSOO [1] http://www.finnbay.com/linus-torvalds-leadership-defines-201... [2] http://meshedinsights.com/2014/03/14/2014-year-of-the-linux-...

Re: Source code of ASP.NET

#98

Post by pmelendez »

eropple wrote: post #54
brainling wrote: post #19

Earlier quoted context omitted.

Visual Studio a) will never run on Unix, and b) is not required to do .NET development. I know people who do their .NET work in Sublime Text with a nant build chain. It's not my preferred method, but it works great for them. Hell, I know a guy that uses ASP.NET to host an Angular app, and to unify his build system, he has Grunt pick up the heavy lifting of running his MSBuild files whenever he does the pre-deploy ste…

> If you think you need Visual Studio to do .NET development, it's because you fundamentally don't understand the technologies at play and just wanted to say something provocative and witty. On the off chance you're not just being knee-jerk and defensive because Something You Like is under fire--people think that VS is necessary because life is way too short to spend building something half as good as the other optio…

>"I mean, could write Scala in TextMate, too, if I had the jones for it. But I could also not, and use IntelliJ, because I value having tools that are able to improve my productivity."

I would argue that it would depend on the person behind the keyboard. I love VS but I happen to be working all day on vi at work and here I know colleges that are as fast or even faster than a lot of people relying on Intellisense. So my guess is that YMMV

Re: Source code of ASP.NET

#99

Post by pmelendez »

davidfowl wrote: post #73
WoodenChair wrote: post #68

Is this snippet of code bad? I was just randomly browsing https://github.com/aspnet/KRuntime/blob/dev/src/Microsoft.Fr... private bool IsDifferent(ConfigurationsMessage local, ConfigurationsMessage remote) { return true; } private bool IsDifferent(ReferencesMessage local, ReferencesMessage remote) { return true; } private bool IsDifferent(DiagnosticsMessage local, DiagnosticsMessage remote) { return true; } private b…

I should have put a TODO in there :)

It happens in the best families... :)

Re: Source code of ASP.NET

#100

Post by skrebbel »

chanced wrote: post #87
skrebbel wrote: post #48

Folks, not much of this is new. Both Entity Framework and ASP.NET MVC were already open source for quite some time [0][1]. All the other repos are nearly empty. The only real news here is that, indeed, ASP.NET vNext is going to be developed in the open, or at least to some extent. But right now, not a lot of code seems to be released that wasn't already out there (although I did not go through all the repos). I don't…

"Uninspired rails port" is a far cry from accurate. I've worked with both rails and asp.net mvc. I started with rails in the 1.x days but also had clients that used .net. I despised web forms for a variety of reasons so I jumped on the mvc bandwagon as soon as the fist community preview was released. Hack, Connery, Hanselman, & Guthrie openly acknowledge that rails was a source of inspiration in their book http://www…

They also filled it up to the edge with Ruby-like magic all over the place.

ASP.NET MVC is the only place I've ever seen in mainstream compiled languages where the code can break in untraceable ways if you change the name of a method parameter (f.ex. for controller actions). Or where models suddenly don't get data because you forget to add "{get; set;}" to the code somewhere. Absolutely no way to find out why it went wrong. The data just isn't there.

Sure, you can learn this and then not make the mistake again, but the reason I don't use Ruby or Python much anymore is because I've had with with having to spend a full day going through a framework's source code to find out why my bug is a bug. In an ecosystem and language like C#, you expect things to either work or to get a pretty OK error message, preferably at compile time. The more magic, the more time I waste tracing bugs.

What's the point of using a compiled language if half your code is a dynamic viewbag of string keys and liberal JSON parsers that just ignore fields it doesn't expect or can't fill?

It's just Ruby, but then in Visual Studio.

Post reply on HN