Benefits of 'native' web part over a Page Viewer web part

Question

I have a number of web 'components' that have been developed or need to be developed that provide simple web functions

• data input, setting target figures (some permissions based input)
• data visualisation (colours, tables, images, 'are we on target', etc)
• various textual and graphical information tied to a database
• dynamically generated content

I've built some of these as stand-alone web pages, mostly using MVC templates. This works fine, and I 'embed' these into SharePoint within Page Viewer web parts.

My question is around the pros and cons or writing web parts to replicate this functionality.

I'll need to write some more components (think 'dashboard') and I should have the opportunity to develop for SharePoint specifically. Assuming development time is the same, what are the benefits and disadvantages of developing natively for SharePoint as opposed to stand-alone pages presented through Page Viewer web parts?

Obviously the SharePoint web parts will be SharePoint-only, which is a minor disadvantage. Anything else?

Answer 1

Developing web parts is not SharePoint specific, but standard ASP.NET webforms, even though most only use it for SharePoint. And nothing prevent you from embedding the web part into a bare page which can be used in Iframes from other systems.

The main thing is who do you want to empower? The end user or the developer?

In SharePoint development you goal should be to give the power to the end user by providing building blocks for them to create a great experience. It's right that in a lot of organisations not all users should have that power, but it's still the right goal even though you may be the only "end user" given that power initially.

Advantage: Clean HTML
Pageviewer inserts the content as an Iframe showing the other page, whereas a native web part inserts pure HTML which can be styled as appropriate for the location.

When developing the web part you're in control of the HTML inside it, if you use controls then you loose some of the control especially of IDs., but that's partly because you don't know how many times your web part is included on the page.

The chrome around the web part is ugly, but you also have that around the pageviewer.

The main differentation is the IFrame created by the pageviewer which just is UGLY. This cause all kinds of problems:

• CSS of page not affecting content
• Links opening inside iframe
• either wasted space or scrollbars if you don't get the size exactly right.

Advantage: Configuration
Web parts gives the end user a nice UI for changing configuration

Advantage: Connections
Web parts can be connected such that a selection in one changes the content of another

Disadvantage: Developer experience
Developing web parts you can't use the latest and gratest: .Net 4, ASP.MVC, node.js, ...

Answer 2

I like using Page Viewer Web Parts, but they have some drawbacks. As Pier said, the layout and styling are trickier than with content in the main page (although sometimes this sandbox behavior can be an advantage). Some other concerns:

• for the users it is a 2 step process, fetch the PVWP then connect it to the external page
• you can't take advantage of features like Web Part connections
• you load several pages, which increases the number of http requests