For future versions are we still using Smidge for bundling and minification or taking the opportunity to use newer frameworks such as Vite?
Smidge is not in Umbraco 15, so I guess we donāt use it anymore?
1 Like
Since Umbraco v14, the backoffice uses Vite for bundling assets at build-time, (pre-bundled/minified in the release itself), there was no longer a need for bundling at runtime in the backoffice, and the dependency on the Smidge library was removed.
If you are using Smidge on your own frontend/website, then you can continue to do so by referencing the NuGet package directly.
Thanks @leekelleher that was my understanding too.
Have you any community feedback of using Vite for front end minifying and bundling?
Iām not sure of the pros and cons other than Smidge was designed for .Net
I havenāt heard any feedback myself about the lack of runtime bundling in the new backoffice.
As far as Iām aware, Smidge was direct .NET Core replacement for the ClientDependency library on .NET Framework (v4.5).
Iām curious if you have concerns about this?
Whether thatās from a CMS core, or 3rd-party package perspective?
In terms of Vite, it does more than just bundling/minification, as it offers a local dev server + hot reload. For core development, we also use it to run the backoffice against a mock server, meaning that the client has no dependency on a .NET server. For faster dev iterations.
For 3rd-party packages, if you donāt want to use Vite, thatās all good - use whatever you like to bundle/minifyā¦ or not. Vanilla JS is perfectly fine in the new backoffice. 
Sorry @leekelleher I meant have you heard of anyone using Vite for bundling specifically out of the box umbraco razor pages client side front end (not headless where you could also use it) css and js.
Just asking out of curiosity as people will be using Vite for packages anyway it might not be a bad replacement for smidge for the website itself.
Ah okay. No, I havenāt heard of any usage of Vite for frontend/websites.
I mean, Iād guess many folks do, but Iāve been out of the website implementation game for the past couple of years nowā¦ when I was building websites, it was all Grunt/Gulp to bundle/minify. I donāt recall seeing any Razor pages using Smidge to bundle assets.
Hehe fair enough Lee
Smidge is pretty nice for bundling and minification to website JS and CSS.
As for Gulp and Grunt I still have to use them on some of our old sites, not so much fun, especially when your getting node dependency errors.
Teams I have worked in have been using vite/webpack for a few years for the builds, mainly because it suited them as frontend developers and it means no runtime overhead
nvm āsolvesā the node version issues
Thanks @MattW thatās what I was asking.
I think I am going to give Vite a go for FE then.
I was using NVM for years but @glombek convinced me to try Volta which so far so good
Just to add my two cents;
In our non-headless Umbraco sites, I was using Webpack for a long time for almost everything we needed, so compiling sass and bundling css, bundling javascript etc. Mind you, these were simple stylesheets ans scripts for the frontend of the site, not really an āapplicationā as such.
In that scenario I got so tired of all dependencies. If you want to compile css with webpack, you need a plugin specific for webpack that in turn references a plugin for actually compiling css. The downside was, that if the webpack css plugin wasnāt updated, you could sometimes have a dependency on an old sass/css compiler. So when we reworked everything, I wanted to stay as close to the basics as possible.
- I used NPM scripts instead of gulp or grunt
- I used the sass package for sass compiling. Since sass is from the actual developers of sass, you got the latest features a soon as they were ready.
- I used rollup for javascript compiling.
But in the context of an āapplicationā - like an Umbraco backend plugin - I really like Vite so far. I could have used webpack, but itās so configuration heavy and complex.
Seems to be a scenario here that is missing.. Eg Umbraco is a CMS that allows for scripts and css to be updated via the backoffice.
So frontend were now missing a filewatch/rebuild to combine and minify if one of the scripts/css is changed by an editor in the backoffice?
But maybe this is now down to the starter kit to provide something? (and it was just nice that the backoffice runtime minification engine could be used frontend)
Prob a different discussion here.. but over time UmbracoCMS has grown up, shall we say, to require this developer pipeline of needing to now have to build and deploy. When I first started using v4 the beauty of UmbracoCMS was that as a dev with very limited experience I could install umbraco on a server and just use the backoffice to do lots of backoffice things without requiring anything other than the backoffice and ftp. 
I wonder if weāve lost that simplicity along the way?
1 Like
By default, the Umbraco 15 template sets Umbraco to Production runtime mode, which doesnāt allow backoffice editing. Not sure what happends when you put in back to the Umbraco 13 default āBackofficeDevelopmentā
not seeing this in a default install of v15+ā¦
[DefaultValue(RuntimeMode.BackofficeDevelopment)]
public RuntimeMode Mode { get; set; } = RuntimeMode.BackofficeDevelopment;
Also is there some override that detects localhostā¦
As running under localhost with runtime:mode=production.. and I can still edit in the backoffice?
Iāve also tried dotnet publish -c Release and dotnet www.dll --urls=https://localhost:44589/ --configuration Release --environment Production
with the recommended appsettings.Production.json as per the docs.. and can still edit in the backoffice 
Runtime Modes | Umbraco CMS
Yeah the default of Umbraco itself in code is BackOfficeDevelopment. But when you create a new project with the Umbraco template, runtime mode is as far as I know set to production in the appSetti gs.json. When set in production runtime mode you shouldnt be able to edit in the backoffice.
just spun up a vanilla 15.3.2 and 15.0.0 just to check and appsettings.json has no runtime:mode set.. and no appsettings.production.json is created.
But as I say following the docs for adding production and running in release with environment as prouction, either in VS or via dotnet run www.dlā¦ Iām not getting any restrictions in the backoffice 
Iām obv missing something simple.
making the same apsetting changes in 13.5.2 and do get backoffice lockdown..
but css/js arenāt locked down 
can happily update those.
Bit more playing with 15.3.1 and seems like views/(aka templates) do fail to save the physical file but do add the DB entry and we donāt get the nice message like in v13 warning we are in production mode.. and actually canāt edit.
Is this just a not quite finished part to v15?
and to finish up on my findings.. RazorCompileOnBuild doesnāt seem to be enforced in v15 like in v13?
<PropertyGroup>
<!-- Remove RazorCompileOnBuild and RazorCompileOnPublish when not using ModelsMode InMemoryAuto -->
<RazorCompileOnBuild>false</RazorCompileOnBuild>
<RazorCompileOnPublish>false</RazorCompileOnPublish>
</PropertyGroup>
But as for css/scripts which was where this started.. they arenāt locked down in production mode as far as I can see.