Safe No Code Change Mode on Save

Feature Request
#1

I routinely use a CSS Pure tool to look through all the CSS files that get included in a typical Bootstrap project, for instance.

I gives me back one file CSS file, I choose the minified option. This one CSS file eliminates tons of CSS properties in a bunch of Wappler and Bootstrap files.

https://mywebsite.com/dmxAppConnect/dmxDatePicker/daterangepicker.min.css

before: 7.03 KB

after: 705.00 B

style properties used on the page: 9.79%

unused style properties: 90.21%

or

https://mywebsite.com/bootstrap/5/cerulean/bootstrap.min.css

before: 162.60 KB

after: 50.70 KB

used: 31.18%

unused: 68.82%

or

https://mywebsite.com/fontawesome5/css/all.min.css

before: 58.19 KB

after: 2.34 KB

used: 4.02%

unused fontawesome code: 95.98%

another example – when I simply want a date input to just pick a date from a calendar Wappler insists on writing this file when my page is saved. Yet, the report I get back on that page is that nothing in the CSS in dmxDatePicker.css is used.

https://mywebsite.com/dmxAppConnect/dmxDatePicker/dmxDatePicker.css

unused: 100%

So, I have to edit the finished Wappler pages outside of Wappler and know that I can’t use Wappler to edit them in the future. If I import that page back into Wappler it will change the code to push all of the CSS code I removed back onto the page.

It would help eliminate some steps in final code preparation for uploading a project if there was a Protect Code Option – perhaps set up in the Target tabs.

Target: Protect Developer Code (for instance)

In this target Wappler does not impose mandatory DMX styles-update-on-save.
Page editing while in the Protect Code Target mode allows hands-off modifications by the developer that can be updated here with no changes when saved. And FTP upload is enabled and project upload.

#2

There is a very old oustanding FR for this. Apparently related features were planned at the time.

#3

I have seen some people arguing, making a case for, “Why worry about css files sizes – today’s servers are blazingly fast, no problem!”

Which is an amazingly sloppy foundation to defend.

In regards to css libraries, which have more of a load THAN EVER in Web 2022, it is the obligation of the END USERS’ browsers and subsequent device internals to process then render.

Having to first evaluate what page css properties will ultimately COMPUTE as “used” means that all css lines from however many CDN and local files will have to be completed and evaluated up the ying-yang side-by-side with the page code that calls/uses just a fraction of all those lines.

If I can give a user device browser just what it needs in one file if I can, and no more, it is efficient, less drain on browser rendering resources ergo less battery drain, too.