Too much overhead with App Parts, and also they require iframe usage. Script Editors are a bit "wild west" and don't provide structure for editing custom properties.
Working on it and first release is in the Preview, like mentioned in the comments – See more details from SharePoint development center under dev.office.com – http://dev.office.com/sharepoint/docs/spfx/sharepoint-framework-overview
Ad van den Berg commented
The PnP Widget Wrangler definitely gets us closer to this sort of model, I'd still like to see this OOB. http://dev.office.com/blogs/introducing-widget-wrangler
Juan Pineiro commented
Indeed! The Script Editor Web Part is pretty sad and yet it's what we seem to use the most. Create a client side API to Web Part Settings to allow us to add custom properties. IMO, The SEWP should be more an online IDE with a larger code editor window, intellisense, formatting, find/replace, etc. A feature to save the code into a deployable and re-usuable web part would be ideal too.
Csaba Urbaniczky commented
Enable to use ECMscript 2015 or Typescript
I elaborated on this a bit more in the Yammer Client Side Dev group. https://www.yammer.com/itpronetwork/#/threads/inGroup?type=in_group&feedId=6027656
I'll copy the content here:
A few different people throughout the community (including Rob Windsor ) have discussed using ScriptEditor and persisting properties into the script/markup itself tapping into the "Save" button click event to save web part properties. [b]My concern with these approaches is that they rely on undocumented APIs and/or UI elements that could change and break any solution not provided by Microsoft.[/b]
The PnP AppScriptPart (https://github.com/OfficeDev/PnP/tree/master/Samples/Core.AppScriptPart) is good, and that's generally the approach I take, however with this approach the developer of the "web part" has to roll their own "editing/configuration" experience (if they want to offer one), which is not consistent with the OOB edit properties dialog. This could get confusing for content managers of sites.
I equate this to the Visual Web Part concept (aka Smart Part) from SharePoint past where I'd point at an .ascx file and it had the right hooks to customize display and edit experience.
Bonus: some way to store only one copy of a custom script file and reference it from any site using a site relative path, similar to how _layouts works in On-Premise installations. For example, in each tenant, a single library that is the "shared" library. Maybe only tenant admins have ability to manage this library. Then enable a way to make it so that I could reference the same file in this library from different urls.
For example: I create a custom .js file - MyCoolWebPart.js. I upload this web part to the tenant "shared" library. I can then access the same file from different urls, like:
and they all point to the same file. This way I don't need to copy it out to every single site collection/site. In alot of places I've seen the root site in a web application used for this, however, this falls down with multiple web applications (i know, not an issue for o365) and/or host named site collections.
I know, I know...host the file myself in a custom site/server. In my current role I can do this rather easily, but I am sure there are many scenarios where this isn't as easy to do (thinking of smaller companies). Plus, it centralizes the assets and, assuming it's done using a (or similar to) a document library, you get the automatic browser cache busting when the file revs.
with each having subfolders for each customization.
Piyush Shah commented
Totally vote for this. Even a newer version of script editor webpart would do which allows persistence of the personalised databag/propertybag via an encoded attribute value within the wrapper element of the webpart or queryable via the object model using webpartid. being able to detection of editing mode would be a bonus compared to current method of hacking hidden variables or ribbon elements. Webpart should also support azure cdn sourced js files
This is really needed
This is long over due.
I intended to say "I don't have the bits" :)
SharePoint vNext? - I'm not in a TAP program and do have the bits - would love to know how these things are shaping up...
Having constructed both Provider and SharePoint hosted Apps, I would love to see a story/framework having these elements.
* Seamless iframe integration (or an alternative altogether) that easily merges within the current UI of the existing page without all the ceremony during construction - further abstraction of all the cross domain baggage
* Frankly, the full page experience blows IMHO unless its a firm requirement of the project
* Better story around themes/CSS when using Apps
I could go on, but in general do I love App development despite the mess
Marc D Anderson commented
I’m totally with you that this type of “non-app” approach needs to be a supported option. The reality is that apps/add-ins are overkill for smaller n, and are out of reach for citizen developers. An approach *like this* would be a step in the right direction if it were "supported".
These types of workarounds exist, but this is along the lines of what I'd imagine SharePoint being able to provide a better client-side API around (and perhaps not need jQuery): https://olescorner.wordpress.com/2015/06/04/49/