I just tried publishing a little test site to see what the output from Elements is like and I noticed a few things:
There’s a lot of .js files (/rw/elements/com.realmac.corepack/alpine-*, gasp-*, etc)being loaded that aren’t used in my little test project. TBF the /rw folder is somewhat annoying, why not just use /elements?
The meta and opengraph data is a bit sparse.
There are font files defined that are not used (Playfair Display). I suspect these are from the theme, but if they’re not used, it’s probably worth getting rid of them.
If I use the same SVG multiple times, multiple copies are included in the HTML. Why not set them as <defs> in a general page assets SVG element, and then simply refer to them via <use href="#embedded-file.svg"/>?
There are files output that don’t seem to be used (/files/image-square.png, /files/image-square.jpg). I don’t know why we need the same file in two different bitmap formats?
The output (html, css, js) isn’t minified. Compression (gzip, brotli, etc) on the server/CDN is great, but minification of files squeezes out that extra bit of performance, especially over mobile networks.
I’m assuming there’s still lots of work to be done with regards to tree-shaking and publishing, but thought I’d just mention these so that they are on your radar.
I’ve noticed this and want to believe these issues can be addressed. I know it’s tough being a website design app, and perhaps part of the “noise” could be legacy code from RapidWeaver Classic. However, you’re right—it needs to be resolved before I push a website live with Elements.
My websites are very large but simple in terms of structured HTML and CSS. Since a page will have a single optimized picture and text that can range from 800-1,200 words, or even up to 3,000-4,000 words, the code must be efficient and clean. For this reason, I have always hand-coded these elements and used HTML includes to build common parts. Simple, but large-scale.
I’m also noticing that pages within folders in the Pages tab have no influence on the site output (whereas folders in the Resources tab do), with folders and filenames required to be defined for EACH page using the little page inspector disclosure button at the bottom right of the panel, {folder}/{filename} which isn’t ideal as it’s about as visible “as sticking it the cellar, in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard’.”
I can see this being a very tedious and error prone process if you happen to have more than a couple of pages.
Thanks for all the feedback on this — The publishing and export is overdue another pass, so rest assured this will be greatly improved in the coming months!
@dan I also noticed that each page has it’s own CSS file (ie. index.html, index.css) which is REALLY weird. Any chance that any CSS specific to a page will just be included in the <head> of the page, and the rest is loaded through a global css file?
Also, any chance the ability to rel=preload some assets (fonts, critical images, etc) might be exposed in a future build, along with loading="lazy" on elements that aren’t critical? It’s nice to see that defer is already being used on <script> tags though, and that immediately executed code is placed before the closing <body> tag.
Lastly, any possibility to deploy sites using anything other than SFTP/S3 (ie. via GitHub to Cloudflare Pages, AW$ Amplify, etc) would be most welcome.
@Dan, The extra feature “Remove Elements Branding” in the higher pricing tiers does not include within the output source?
rw
elements
realmac
So branding is gonna be riddled amongst the source? I’m fine with Tailwind, Alpine, GSAP, etc., as they are all common industry libraries. Though wasn’t expecting to see Realmac branding living in perpetuity within the page source / site structure.
I think out of necessity there will need to be someplace to reference used components, which are defined by a reverse domain id (ie. com.realmac.corepack, com.bryanrieger.mediapack, etc.), with com.realmac.* likely to be common to most (if not all) projects. Whether this place needs to be a /rw folder in the root is debatable, but the components will have to live somewhere. Personally, I’d be fine with an /elements folder in the root containing all required components, styles, themes, etc for the site.
Sure, you could see an /elements folder as branding, but it’s a fairly generic term, much like /resources that doesn’t stand out too much. You’ll have components with com.realmac.* in your site regardless. You could also call it /components, but I’d argue that’s a better name for the current elements[1] folder contained within the output structure.
[1] are they elements or components? This still seems to be a common point of confusion.
Could be just me. I’m just not an advocate of seeing software references (branding) in source code even with such apps. Especially given the detailed care of using vanilla Tailwind within Elements.
It’s not likely that I personally will be using third party components within Elements. But I suppose structure needs to be in place, would personally be fine with elements without the rm, realmac.
I consider Branding to be something placed on the individual pages that are viewed by whomever is viewing them. I don’t consider folders placed behind the scenes as branding. Doesn’t matter what the folders are called.
I purchased the plus license, but I actually have placed the Elements logo in the footer of my home page because I am very happy with it. I have no problem advertising it to whomever is viewing my site that it was made with Elements.
Since Elements is using Tailwind CSS, shouldn’t ALL (or at least, most) of the CSS be inline with the HTML, and there shouldn’t be CSS files (or at least very few)??
Since there is a page manager and a resources manager in Elements, assuming that the individual takes the time to organize the files within each manager respectively, should not that files organization be the basis for the organization of the files uploaded to the server for the project??
