Yes, those were the two I was testing for use in Foundry. In general I was able to get things to work rather well but there were a couple of places where it interfered with some Foundry stacks, tables in particular.
I’ll keep experimenting with it as there is a lot of potential from what I can see so far!
You’re missing one of the big features of Source in that Source does not load up all of the large framework files and other stuff that Foundry, Foundation, etc., all load up whether you are going to use those features or not. There are other significant performance enhancements too, in Source and when habitualshaker describes Source as a micro framework it is minuscule compared to others. This gives the best edit and preview performance speed up I have ever seen.
So a far better approach is to add the specific stacks that you want into a Source theme with Source and take advantage of the best stacks available which are always better than the framework ones anyway.
So if you want a slider or accordion or modal stack then use the best available. You will end up with a much leaner and faster web site using Source in this way.
As you have also probably found out, Source can do many things that no other framework can do and has set a new feature bar way above everyone else IMHO.
Actually, I did not miss that feature, it was just that I am not a point where I can recreate this site from scratch, but wanted to leverage some of the layout features from Source.
I will certainly be looking at rebuilding the site in Source going forward.
Although there are still some stacks that I use that don’t seem to play nice with it so once I find alternate replacements I will have to just keep experimenting.
I’m excited to see if I can reproduce this site with Source!
I’d like Source to be as compatible with as many third-party stacks as possible. I tested with a load of the ones that I’ve got and didn’t find too many issues. If you let me know where you do see issues I can try to fix.
As I come across them I will be sure to let you know.
But at the moment most of the problems relate to trying to use Source with Foundry. In general it actually works really well, except for Foundry Tables completely messes up the way they work, which is a little odd as everything else seems to work fine. What is happening with taels is that Source disables the ability for text to wrap within a cell in a table. So far that was the major issue I found with using Source and Foundry together.
So going forward I will need to find a good Table stack to use with Source.
You really shouldn’t use stacks from one framework with another, as you may think you get away with it, but you are storing up potential issues and problems that have you may have not noticed. Also, over time, frameworks get updates that make changes about where code is stored, e.g. what used to be in the stack can be moved to or dependant on the theme for the code. This has happened many times in the past.
There are many table stacks you could use with Source.
One of the first stacks that I use all the time that does not appear to work with Source is the doobox SVG stack. I really like this stack as it does not require me to enter SVG code I can simply point it to an SVG on my server.
When I try to use it in my experimental Source project nothing happens the SVG does not show up at all.
Then I tried to use the source code from the SVG in the Source SVG stack and it caused RW to put up a parsing warning, not sure what was going on there.
OK, I figured out the problem with the code in the Source SVG stack, it does not like to have anything (comment) ahead of the opening tag.
Just tried that SVG stack in my project and it worked as expected. Must be something else going on. Happy to have a look at your project if you want to send it through.
And yes - that’s right. It should just be the <svg> part of the code that is added.
Well the thing that is interesting is the the SVG shows up no problem while you are in edit mode, but as soon as you go to Preview mode then none of the SVG’s show up.
I switched to using your SVG stack for now but would like to get the doobox one working.
OK, I played around with it a little more and it does in fact work as long as you DO NOT place it in a GRID ITEM, which is what I had initially done. But then I pulled it out of the grid item and it worked just fine.
If you still want my project just let me know how you would like me to send it too you, thanks!
Ah ok. If you add a Container stack into the grid item and set it to be full-width, then add the SVG stack into that it should work fine. I presume that the SVG is set to be 100% width in the code but there is no inherent width in the grid item for that to apply against. I’ll have a look to see if I can set things up so the use of a container for this isn’t required for cases like this.
Why not just use the Source Image stack which supports warehousing and therefore, warehoused SVGs? The Source SVG stack is really powerful in that it allows you to change the colours of an SVG from the stack settings.
Yes, it is nice that it can do that, but it is pain to have to cut and paste the source code into the stack, be so much nicer if it could do that for you and simply allow you to point it at an SVG and go from there.
Will certainly use your suggestion of the IMAGE stack as that would be really easy did not realize it could handle SVG images, thanks for pointing that out.
I will certainly use the Source SVG where I need the ability to manipulate the colors.
So far I’m really liking the leanness of Source, but there are a number stacks I will need to find to replace some of the ones from Foundry that I have been using.
Awesome, that works perfectly. Yes, the SVG code was set to 100% by Affinity Designer.
At least now I can copy and paste many of the SVG stacks from my existing site to the new one I’m trying to build with Source. Will make life a lot easier. That will allow me to then more leisurely move the SVG’s into either the image stack or the source SVG stack.
However, it would be nice if one did not need to use the container to make this work, but it is a good trick to keep in mind.
Which ones out of interest? I have used Foundry a great deal and I have yet to find something that I can’t use an alternative for in Source.
The first ones that come to mind are the Vertical Tabs, Table, and Table (CSV) stacks.
But the most challenging ones are probably going to be the Alloy stacks for the blog on this site.
If you are using a ton of Bootstrap components and Alloy on your site then undoubtedly the most efficient thing to do is to stick with Foundry.
Frameworks are very efficient in the code they produce when you use framework components. In RW, frameworks make less sense when people just use them as a blank theme and stuff the page full of non-framework-stacks. Why? Because you just end up with duplicated code, much of which will never be used by anything on the page.
As per Stuart’s title to this thread, Source is a “micro” framework. We can argue what that means but in essence, it is a CSS Reset with typography styles. If you like, it is a blank theme that does not look like the Berners-Lee page when you just put a text stack on it.
This is great if you have a page to make that uses a small quantity of known third party stacks and you don’t want the additional Framework baggage. There is no built in grid (columns in non tech speak) and so you can choose your own - either the Source grid or 3rd party column stacks - flexibility at your finger tips.
This puts the you in charge of your page but with that comes responsibility. Bear in mind that you could add just one layout stack (which I shall not name - because its not mine) that will produce more CSS than the entire Bootstrap (or Foundation) framework!
As ever, the real skill in using RW is using the correct tool for the job from the vast array of stacks, plugins and themes available. Knowledge is power in this respect. Understand what and why you are adding to your page and its implications. We are at the pro end of the user spectrum in discussions such as these and so a lot more onus is on the user. There are no game changers, no magic bullets, just options.
Yes - if you are 100% invested in a framework such as Foundation or Foundry and generally make use of their own bank of stacks (and don’t have any issues or frustrations with speed in Edit/Preview modes) then it totally makes sense to stick with that.
If however you are using those frameworks simply as a base for a load of third-party stacks (which is a very common scenario as third-party specialised stacks tend to do their one thing better than the framework’s version of it) then Source would very likely be a better option.
As @tav says though, this is all about providing choices and the addition of Source just provides another great option as a starting point for your RW sites.
Indeed! Like here: https://www.caffeineinjection.com/
That site uses the Foundry theme, customiser stack, font control stacks and menu. But that’s it when it comes to Foundry. Unless I’ve missed it, there isn’t a single Foundry stack on any page, it’s all Tavs stacks.
Why have I built an entire site (and a pretty big one at that) using Foundry at the core but without using any of the Foundry stacks? Mostly, because without a framework at the heart of a site setting the styles is a PITA, plus I really like the Foundry Mega-menu. I prefer Tavs stuff over the standard Foundry stacks though, so I’ve not used any.
OK, but why is this an issue? Well, really, it’s not. At least from most peoples POV it’'s not. The biggest drawback as covered above is that doing things this way means there is a ton of code baked into every page that is never going to be used.
Why? Smart people above have explained it, but in lay mans terms…
All stacks need a load of gubbins to make them work. Third party “stand-alone” stacks have this gubbins built into them. With frameworks the gubbins tend to be baked into the theme. So if the framework has 50 stacks, that’s the gubbins for 50 stacks added to every page where you use the framework theme.
This is a poor explanation, but it’s kinda right.
So, in the instance of that site above, each page has the gubbins for however many stacks Foundry contains, when only about three are used.
It’s worth noting that in most instances this doesn’t slow down the page previews, but it can slow down page performance.
So, if I were to switch that site from Foundry to Source… What menu should I use?
Just a note to say that latest update (out now) makes a change to how this works so that the full-width Container workaround is no longer required for third-party stacks when placed inside a grid item.