Please do not move nopCommerce just yet. This would make a lot of installation pretty much useless. Lets wait for HTML5 to see what happens.
hehe :-) yeah, let's see how HTML5 (which is still a draft) will perform in IE6 and in all the other cool browsers from MS ;-) Seriously: With MVC it should be easy (easier) to build a HTML5 template.
Webforms is OK, but the viewstate is very heavy and more suited to internal/intranet applications where high performance, low bandwidth, and SEO aren't AS critical. MVC (and it's variants) are pretty much standard for high performing, highly reliable web apps.
There is no reason why the viewstate in NOP has to be so massive. I use other webforms apps that have tiny viewstates. It appears at present that things are being stored in viewstate that just don't need to be there. Optimizing this shouldn't take long (a lot quicker than moving to MVC).
My concern is that MVC seems to be touted as some panacea to sorting out the bottlenecks and problems we're finding in Nop at present. It is not. The current problems aren't inherent to webforms - other software I've used has staggering performance, small viewstates, excellent SEO, and its all running on webforms.
Webforms is OK, but the viewstate is very heavy and more suited to internal/intranet applications where high performance, low bandwidth, and SEO aren't AS critical. MVC (and it's variants) are pretty much standard for high performing, highly reliable web apps.
There is no reason why the viewstate in NOP has to be so massive. I use other webforms apps that have tiny viewstates. It appears at present that things are being stored in viewstate that just don't need to be there. Optimizing this shouldn't take long (a lot quicker than moving to MVC).
My concern is that MVC seems to be touted as some panacea to sorting out the bottlenecks and problems we're finding in Nop at present. It is not. The current problems aren't inherent to webforms - other software I've used has staggering performance, small viewstates, excellent SEO, and its all running on webforms.
You are right, it has to be said.
However, MCV is still the future for ASP.NET, that is plain fact.
The only concern I have in the current design is that the layout can't be changed or overridden without touching the original aspx or ascx files for most of the layout. Would MVC make it more configurable with lesser cost? and also think about doing upgrading. If MVC makes it easier to change layout and makes upgrade easier, I will vote for it. Also, I would like to see using the "Code First" in the Entity Framework instead of the EBML file approach.
The only concern I have in the current design is that the layout can't be changed or overridden without touching the original aspx or ascx files for most of the layout. Would MVC make it more configurable with lesser cost? and also think about doing upgrading. If MVC makes it easier to change layout and makes upgrade easier, I will vote for it. Also, I would like to see using the "Code First" in the Entity Framework instead of the EBML file approach.
Doesn't matter what pattern is used, you're going to need to modify an .aspx page to change the layout. There's no getting around that.
Webforms is OK, but the viewstate is very heavy and more suited to internal/intranet applications where high performance, low bandwidth, and SEO aren't AS critical. MVC (and it's variants) are pretty much standard for high performing, highly reliable web apps.
There is no reason why the viewstate in NOP has to be so massive. I use other webforms apps that have tiny viewstates. It appears at present that things are being stored in viewstate that just don't need to be there. Optimizing this shouldn't take long (a lot quicker than moving to MVC).
My concern is that MVC seems to be touted as some panacea to sorting out the bottlenecks and problems we're finding in Nop at present. It is not. The current problems aren't inherent to webforms - other software I've used has staggering performance, small viewstates, excellent SEO, and its all running on webforms.
Makes sense to me and sounds fair enough in the interim. Happen to know if there is optimization for the Viewstate in the works? If not, maybe I'll start to look into it.
I posted about this in a different thread, but optimization of javascript is also pretty important. A lot of the client side validation of fields (specifically in ProductsInGrid), is tons and tons of duplicate code. I was able to reduce my uncompressed pagesize by 44KB just by rolling my own client side validation and disabling the ASP.NET stuff.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
