Wasn’t that Source?
Usual Joe understatement.
One day, he’ll be less American.
It is not mysterious. F6 is right now not in the final stage. I would say F6 is on public beta ;) There are still some small things to do. Yes, F6 will change the way how I will build web sites. I would say that F6 is not for the average user, but It is really powerfull and amazingly fast.
1 Like
I would say that 3 or 4 months ago when Source appeared, that you could make such a claim and that it certainly has redefined how we build sites with powerful features and speed of edit never seen before, and given RW a new lease of life.
So this makes Joe’s claim even more interesting - if correct.
So you’ve tested and compared it to all the other frameworks out there? (Ignoring the fact that Source is a “micro” framework for the time being!).
I hadn’t and still haven’t seen anything that fast in Edit mode, when Source was released. That’s why a real world comparison such as the one discussed will be so valuable. I also base it on customer feedback I get from my Source Projects.
I’ve tried to keep my mouth shut but, as a scientist, I have to say something.
The frame of reference of this “experiment” means that it is completely invalid and will not provide any meaningful results for anyone other than those who are trying to reinforce their own opinions (on all sides). This is Mickey Mouse science - lets have some frame of reference or not bother.
If you choose a super simple page then a micro framework or no framework will always win if your only frame of reference is a crude size measure. (I could piss that page with just one Scribe stack and next to zero code but that would be equally ridiculous).
If you choose a complex site with many different components and different grid (column) setups then a “normal” framework will almost certainly win due to the large degree of shared code and class names compared to that of a disparate set of 3rd party stacks.
Most sites are somewhere in between and therefore the decision is blurred and most probably more dependent on perusal preference as to the methodology of use. Familiarity, of course, is often the most important factor followed by natural resistance to change and the need to get the job done.
Can we please move the debate on to something more measurable and tangible such as who has the best chip shop in their town.
OK, so you really needed to change your initial comments along the lines of "speed of edit I’ve never seen before.
Don’t want to be pedantic, but then, also we don’t need even more unsubstantiated claims on this thread ;-)
(Gonna go back now and read Tavs comments).
Please ensure that you have a valid answer to the chip shop question :)
2 Likes
Sadly not me.
I think the plan was to take this simple page and copy the content numerous times and then see how each framework handled it in Edit mode. Nothing to do with output size.
Though I would argue most RW built pages are actually of the type shown (and not built with a vast array of grids and columns). If that’s the case then size is key. The published Source version of that page is 350KB - which is more than 150KB less than the blank pages of the other frameworks.
Whether it is this proposed test or not, I think some test between the frameworks would be a useful guide for neutrals. But agree that the conditions and measures etc need to be valid and reliable.
You remember this is a RW forum, right? ;-)
But ya, your point occurred to me when we were discussing it. My thinking was get the initial testing done, with the simple page. Then start to add real world complexity (this will require third party stacks) to each demo project and see how the numbers change.
As for chip shops, never eat from them. The thought of doing so makes me retch. But, the local village to me has about seven of the damn things for a population of about 6000. Nuts.
Precisely why it is still skewed against conventional frameworks (which I am not here to defend, just trying to be valid).
Can’t agree with that.
Real pages are not a repeat of a few simple stacks - they are usually a catastrophic mess of tons of different stacks (examples from my extensive support list can be provided). Users in this thread are not the norm, many people just drop stuff onto the page like it is coke going up their noses.
I wasn’t aware that such a beast existed in the RW community :) If they do, they certainly don’t read threads like this. #cynical
I agree, some sort of real world comparisons between the frameworks would be fun and I’m sure helpful for some. Sure the outputs won’t be reliable, and it’s most likely end up that each framework is strong in some application, weak in others, but I think it will be worth doing.
Years and years ago I was involved in some bike tests. We got to ride around the same trails on different bikes then reviewed and rated them, ultimately picking a winner. It was of course pure nonsense, as some bikes were great going up, some great going down, some worked well for me, some worked well for others. We picked a winner but it was based on the amount the brand spent on advertising, not the riding.
Quote of the week.
4 Likes
I like chips 🍟
I think the test is a potentially very interesting one and in the absence of anything else, a good place to start. The Source Lawyer template is an existing good representation of what building blocks are used to build everyday sites. These are the bread and butter building blocks and for anyone looking for a new of better “Framework”, these are typical layouts. The test is just for Edit mode and just a test for RapidWeaver “Frameworks”.
I hope that a lot has been learnt about avoiding slow performance since the first generation "Frameworks like BlueBall Responsive, Foundation and Foundry, so that will be interesting to see what has improved with the new “Frameworks” such as Source, UIKIT, Platform and F6.
Best chip shop I ever saw was called “A Fish Called Rhondda” - great name but was probably crap.
This is precisely one of the reasons that it is invalid - there is no causal or non-causal link between those two parameters.
A framework (and size thereof) has little or no affect on the speed of RW edit mode and preview. This is 90+ % to do with the number of settings and the number of Stacks API conditionals in the stacks that you choose.
Carry on with this line and I will be forced to bring my TINAFOTS stack into the argument which, as you well know, can never be beaten on speed, size, library load time and usability! :)
90% of statistics are made up.
I would not trust a statistic I didn’t fake myself.
Well I’m a scientist too (not a data scientist or programmer admittedly) and thought it’d be interesting to have some side by side comparisons, was going to make a few suggestions along the way to make it a fairer comparison.
To be honest it’s been on my mind to make a better comparison of the frameworks, not necessarily performance but features and unique selling points.
I imagine every framework has it’s strengths and weaknesses, it’d be interesting to see what those are. For example Source is probably ideal if you have an existing and extensive stack set to are just wanting to start out and not break the budget. On the other hand starting out with only Foundation, Foundry, Platform or UIKit (is RWSkinz still on the go?) might be a better option as it has more to offer for the price.