Quick score update: Tav 6, everyone else -14
1 Like
Just because @tav can pop on his âi am scientistâ hat doesnât make his statements any less full of hyperbole and conjecture as anything else said here.
Finally a good discussion.
I donât think that is a good way to chose a framework. The more is better doesnât make a lot of sense and I would argue that less can be better because you can add the best in class stacks if you need to provide something not in the framework. The more stacks that are included in a framework means that there are more to maintain for the developer, and update if necessary, and in addition, the user has to learn how to use them all.
I agree that a fair comparison of some form, between frameworks would be useful. New users and users looking for a new age framework, must find it very difficult to make the best choice. In addition there is certainly a lot of hype flying around elsewhere making claims and doing things that are already done elsewhere.
Whatâs more important than anything else is an understanding of how frameworks work. This seems lacking in many users.
Iâm no expert, but this is what Iâve picked up and has helped me make informed decisions for the tools I use.
The core css for all the stacks within a framework are in the theme. So, if you have a framework with 100 stacks, the core css for those stacks in added to the page, no matter you use those stacks or not. This makes for some great efficiencies, so long as you are using those stacks. If though you for instance use framework X and only use the style stacks and say the menu stack (as in the case for me a while back), then use third party stacks for everything, you are loading a massive chunk of css that isânt needed or used.
For this reason (IMO) itâs vital to choose a framework that can actually do the things you want, without having to resort to third party stacks as a matter of course.
That is assuming you care about the weight of your pages and general efficiency of your website.
The other thing that is important for people to get their head around is the number of stacks on a page, at least the number of times the same stack is duplicated, wonât effect the speed of preview much. This is mostly down to the amount of settings each stack has, my settings I mean options in the right hand column.
If you drop a stack on the page, no matter it part of the frame work or a third party, if it has loads and loads of settings, it will slow down the preview rendering of the page in RW.
The the past a dev releases a stack, people love it and request features. The dev agrees and adds them. Sooner or later the people who love the stack start complaining that using it slows down preview. Catch22!
What do you want? Preview speed or loads of features that are easy to adjust? You canât have both.
Until now.
Some devs have smarted up to this issue and have come up with clever solutions. You have the child stack (more or less pioneered in RW by Tav but becoming common with many devs now). The idea is the main stack has the basics with minimal settings. Features are added by adding child stacks.
So letâs take as basic container stack: You could add all the responsive margin, padding and width stuff to the main stack settings, but itâll slow it down. So instead you add the container stack to your page, then to it add your margin stack, or padding, or width, or all of them. Itâs a great solution and means you only have the settings you want, so preview is as fast as it can be, given your requirements.
UIKit does things slightly differently. Instead of having child stacks, all functions and features are split out in to separate stacks, which you later up as required. Itâs like global chid stacks. The other way UIkit differs massively from the rest is the use of classes. Classes are little bits of css that you apply to a stack by adding to the class, a la stacks 4. Again on this one, to give me his dues, Tav was one of the first to do things this way.
This is a very quickly typed out rough overview, it might contain inaccuracies, but itâs important for people to under stand this stuff before making a decision on a framework.
1 Like
Well perhaps not put in the best way, i was more going for the best value tool for the job you are trying to do.
I agree that stack numbers in a frame work is a dubious metric and sales point, better to have the a few good tools that work well.
@steveb interesting to hear about UIKit and how it is different.
I was also catching up on Joeâs Foundation 6 live streams last night, looks very good and also is pushing using classes to achieve specific and global styling. Was also very impressed by the options to build your own menu and the Accessibility options built in. Loved the Form updates, looks better than other options out there at the moment.
So back to the main point, does anyone fancy trying to make some sort of framework comparison, because it is bewildering and lots of superlatives are thrown about. Particularly for new users it can be a bit overwhelming.
Isnât that the plan? Iâm doing the UIkit version, Stuart is doing the Source, I think Webdeer is doing Foundry? Just need someone to offer to pick up the others and weâre good to go.
I think the plan is to start simple, based off the Source demo theme linked above. Then add in complexity. Itâs not going to be in the least bit scientific, but in light of the fact there isnât even the most basic of comparisons out there that donât rely purely on personal opinion, itâs a good enough starting point.
It seemed to be going in various directions for a bit!
I volunteered for Platform as I have it but did warn Iâm far from expert on it.
Someone with Foundation 6 would be good too
I think this was the original subject of the post. It was split from a post about removing JavaScript to reduce data being transmitted to the end user.
Edit/preview speed and how much data gets sent to the browser(aka page weight) are two entirely different things. The edit speed impacts only one person, you the developer. The speed the page loads influences everyone who visits that page (hopefully tens of thousands of people a day.
The core CSS, JavaScript and external libraries (jQuery for example) are load even if you donât use them, but if theyâre loaded in the theme they are cached by the browsers. So on subsequent pages (assuming the user goes to additional pages), that CSS and JavaScript doesnât have to be loaded.
If the code is built into the stacks, the CSS and JavaScript would have different URLâs for each page and need to be read again from the web server not from browsers cache.
You might also have a framework that loads jQuery with the theme (both Foundry, Platform and Foundation do, Source doesnât, I donât have UIKit yet) then add a non framework stack that requires jQuery (many do) so stacks will also load a second version of jQuery.
I think I started this whole âwhoâs the fastest frameworksâ debate. I was speaking of page weight to the end-user not edit or preview speeds.
Source being a much smaller âmicroâ framework will of course win.
My advice is if you are going to use any of the full frameworks, then use the stacks that comes with the framework. Donât just use them as a âblankâ theme.
This should never happen normally if the stack is correctly written. The Stacks plugin arbitrates and loads the correct version to cover the requirements specified by each stack on the page that uses it.
Only stacks that do it âthe wrong wayâ by loading their own jQuery in Script tag (or one framework that loads it twice -I donât know why so I canât comment on this) result in more than one copy of jQuery.
Stacks also loads jQuery.migrate to mitigate for stacks requiring deprecated versions of jQuery .
Just as an update on this, I see F6 is now out. So maybe we need to hold off slightly on this and invite @joeworkman to the party to add F6 to the mix.
Weâll discover if those claims of âfastest everâ etc. actually stand up in the real world. ;-)
And it will be most interesting to see Stuartâs @habitualshaker framework comparison chart updated to include F6. Not sure if anyone has built a site with F6 yet and promoted it.
https://shakingthehabitual.com/stacks/source/blank-page-comparisons/
I think to compare any full blown framework to Source (mini-framework) is unfair. A framework (full blown) will always lose out to a mini-framework on small sites built with only the stacks in the mini-framework.
Full blown frameworks only start to become economical in terms of preview speed and page weights once you start to use a amount of the built-in stacks.
If we build any site using only the Source stacks then replicate it in any other framework, Source is gonna win, as itâs a loaded test. But, it is a test worth doing and a good starting point.
This test will only start to offer some proper stats once the demo site we propose to build starts to grow to incorporate a full range of features and stacks. At this point, assuming the frameworks in question have the native stacks, Source will need to start to use third-party stacks to keep-up, and then a truer picture will appear.
That graphic is a great selling tool for Source, but when you consider the other frameworks can do an enormous amount more than Source, things start to look very different.
Iâm not knocking Source, but I do think we need to keep the playing field level.
It will of course be hugely interesting to put F6 up against the others though. Weâll very quickly separate the men from the boys ;-)
It may not seem fair to any framework that loads over half a gigabyte of extra code to a page but Source certainly isnât a reduced feature or function set of stacks. Iâm currently building a site that is already 22 pages and I have not needed to use any stack outside Source.
Although, Source may seem that it is a small number of stacks, but it can create complex layout that would be counted as stand alone stacks and âbig featuresâ of frameworks. E.g. Source can build Hero sections, multi Card layouts with positioning that you canât find elsewhere, Jumbotron layouts, complex footers, etc where each one of these could have a unique stack name and a whole page of marketing documentation and hype to big it up. So it may be termed micro or mini but in functionality it is very complete complete. I think the days of offering high numbers of stacks are looking very dated and users donât need all that stuff.
The other thing is that if you want to add additional functionality like video or animation or sliders or modals or Google Maps, you will use BWD no matter what framework you are using, unless you want to accept a less than best solution. If you need a form or gallery then you can use the best form or gallery for the job which we already have in our toolbox.
Also I think that chart is pretty illustrative and informative. Maybe Frameworks and stacks should come with a sort of UK Food Labelling or warning system detailing how much JS or external fonts and icons are loaded.
1 Like
Only out by a factor of one thousand !
Sorry. I meant Terrabyte.
Shit, its getting bigger - the internet is about to die :)
1 Like
To be fair, I fully acknowledged this myself when posting the chart.
Proves nowt.
My point precisely!
I can (and do) build fully featured sites with videos, animation, tabs, accordions, hero headers, video headers, tables, sortable content, overlays, underlays, three peice suites, the whole lot, with only UIkit. Using a mini framework youâd need to use all those awesome BWD stacks, which is exactly my point: To get a complete and fair comparison at the end of this, the Source demo project will need to have such features added to it using third party stacks. Only then can this thing get anywhere near close to something of value.
I get that you love Source, but you need to be more subjective if this is going to work.