Sage 9 - Bloat or not?

sage
1

Just a thought …
At very early stages of Roots theme, when I first started to use or at least trying it, theme was a bit bloat by my opinion with to many hooks.
Don’t recall the right version, but it was something like ~ 4, if memory serves me well.

There were hooks in each template above and below every div. It was a hype probably back then to do everything with hooks and not modifying templates ‘good old fashion’ HTML way.
At first I didn’t get it, but after I understood what’s going on I just deleted everything from template and did it my way instead of hooking - much simpler.

By default it came with bootstrap, and while there is nothing wrong with having bootstrap at some point that started to be another bloat to me. So I kicked out bootstrap and started to use Susy
My CSS files dropped by 50%.
I would use a framework if I’m building web app, but for custom themes with custom .psd design not likely it will save me any time or work.

Then at some point (I think v6) things started to get slimmer, everything marked as ‘clutter’ was cut out.
Cleaner templates, better file organisations, better build process, etc …
I liked that one with couple of my personal tweaks.

Now, I’m just checking version 9 to see if I can update myself to latest trends, and I’m just browsing trough the files and checking what’s changed and I must say that I feel like it’s going back to bloat again.
It’s started to be to complicated again, I need a manual for this one now.

WordPress already has a way of managing templates. What’s with the Blade now.
I can understand moving from grunt to gulp, and now to webpack … but why would we use twig or blade.
I feel it’s like a template for template, or xzibit would say: I put a template in your template, so you can use templates while you use templates.
Wrapper class is doing a decent job on it’s own.

Font awesome? (I know it’s optional)
Why not custom font (eg: fontastic) or svg sprites.
Who needs a bunch of font awesome icons in each theme, they don’t cover all needs, not the every designer is using them.

Maybe it’s just me, but don’t like much.
I’ve build more then 100 themes in past 4-5 years. Now when I go back to some of them and need to make some changes, updates to website for some I need to first think and figure out how were we doing it back then.

Tools change, workflow change, requirements change.

In a year from now, there will be no blade, but something else maybe.
Then I will have 10 websites using grunt, 20 using gulp, 10 with webpack, 10 with blade, others with wrapper class, then 20 websites with different combinations of the above.

Not really sure, what’s the goal and what’s the future of theme development with Sage.
Is it for building websites or building web apps?

How do you people manage your things?

7 Likes
2

In my opinions, it’s experience. Part of being a web developer is learning new tools, trying new paths and seeing what makes our work more efficient. You need to know how to use many tools cause each one of them is useful for different kind of jobs.
So yes, if I look back at the stuff I developed years ago, it’s much different to what I do nowadays, but it’s also unrealistic to expect that every single project goes through so much maintenance to be updated/redeveloped with the latest tools. Sage provides the tools, it doesn’t enforce anything. You’re free to clean it up or add more. It depends on what you have to do!

3 Likes
3

Web development in general rarely sits still, in fact it’s evolving faster than ever before. So you can’t expect a theme framework to rely on old technology for very long. For instance, Bower is no longer active, so Sage needs to look towards better replacements like Yarn. The new tools you use in Sage 9 also don’t deviate too much from what was used in Sage 8, and consolidate a lot of what was originally required - eg. yarn = npm/bower/gulp.

For a beginner there’s a lot to take in, but 90% of all your questions are covered in the ReadMe file, and Sage 9 docs are being worked on fairly regularly.

Compared to v8, Sage 9 offers much more flexibility to suit your particular preferences for frameworks (for example, in the Composer setup script you can select between Bootstrap, Foundation, or nothing at all. Same applies to FontAwesome). You also don’t have to use the Blade templates in Sage 9. Just take the old Sage 8 PHP template wrapper files and drop them in. (However I’d suggest sticking with Sage 8 if that’s the case).

This is the unfortunate reality any theme dev faces. Over the years we are required to know and maintain multiple versions of things, and learn newer and better workflows regularly. If that’s not desired, you can stick with a particular framework version (eg. version 8) and fork it if you need to. But website templates have a shorter life these days (some of my clients have a new website design every year) and that generally affords the opportunity to keep things current and up to date.

At the end of the day, Sage is what you make of it, and the more you tinker around and learn how it all works, the greater the rewards. I personally like the freedom of choice and “currentness” that it has over other frameworks that don’t know what the term “theme wrapper” even means.

7 Likes
4

WordPress doesn’t have “templates”. It has PHP files :slight_smile:

But seriously, what WP does to “manage” templates is what Sage 9 is using. In fact Sage 9 is only possible because of the new WP template hierarchy filters. Sage maintains everything WP does with template loading via the hierarchy. It’s the best of both worlds since it maintains compatibility and you can still use plain PHP files just as easily.

The only additional thing Sage 9 really added was Blade. Nothing else you mention is 1) a default, or 2) part of your deployed theme.

So I understand your concern, I just don’t really think it’s that true. Yes, Blade adds overhead but we think it’s worth it.

5 Likes
5

Will not reply everyone, just wanted to raise the question to get some opinions on the subject :slight_smile:

Personally I think frameworks are good for prototyping and for web app development, but for custom .psd design not.
Everybody has it’s own way of doing things and I personally believe that everyone should use what is best for him and what is most comfortable with. There is no ultimate best way, that would be boring life I guess.

I do realise the evolution of tools and don’t think we need to use same tools, that would be mistake. Instead need to evolve and keep up. This is why I am here after all.
In javascript these days it’s to many of them and it just reminds me on this article: https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f#.imhpv0ouf

2 Likes
6

@bobz_zg I agree with your concerns. I cannot understand why they would implement Blade either. It’s just not needed. I count it as just one more “dying” tool which web developers need to learn while another tool is developed. I think the killing of bower and implementation of full npm and webpack is a must. The society decided this, not a group of developers like Roots. However, a group of developers like Roots, decided Blade – and there should be very good, crucial reasons for this, as we don’t need to make problems for ourselves.

That being said. I love having wrong, so I can learn something new. Thus I might get an epiphany regarding Blade so that I can use this for a long time and really work more effective. However, the trend tends to be that always learning new stuff (like Blade, like webpack, etc) takes so much time, especially in a stressful work environement, that - cumulated - works the opposite. Meaning that by the time you’ve gotten the new tech under your skin, a new one pops up. We don’t really need it, we need to settle down for a while and be happy with what we’ve got. Soon there aren’t possible to work any faster, because we’re still humans. Don’t get me wrong, big and important changes like npm over bower and webpack over gulp is a must! But all these small things? Come on!

@bobz_zg I don’t understand what you mean when you say that frameworks (preferably Sage(?)) is not for PSD design. What do you mean and why? I use Sage, love it, and I always design my sites on Photoshop first. Are there any others way to do it? Can you please explain why Sage is more for app development and also explain what the alternatives are to frameworks and why these are better for PSD design?

Another thing: can Blade be added as an option in the Sage setup, please? If it already isn’t, can you consider this a feature request?

4 Likes
7

Sorry, I was not clear enough maybe. I want to say that css frameworks like bootstrap don’t work for custom psd design because you end up overwriting bootstrap styles.
Changing variable values wouldn’t do because you end up with more code than you need.
I prefer susy for grid and the rest custom and as lightweight as possible.

Regarding ‘the bloat’, I wanted to say that I’ve been using sage/roots for years and the point was that I feel like trough the years it’s been jumping trough hypes at some points, but hypes come and go.

There can be arguments pro/con this is why I created a post to see what other developers think.

Tools change fast in our industry I personally dont need to be on the edge all the time.
Im still running gulp + bower, and it works fine.

3 Likes
8

I would say it’s leaner than previous version. No bower, has PSR-4 loading, etc.

Blade is the only new thing, which takes about 15 minutes to learn and has major benefits when separating logic and templating.

2 Likes
9

Bootstrap is modular so you don’t have to overwrite anything unless you want to. You can simply exclude the modules you don’t need.

2 Likes
10

I’m not sure why there are so many comments doubting the addition of blade.

Blade syntax is more elegant, concise, readable, more powerful, and easier to write than just PHP tags. You could even bind PHP data to Vue.js properties using blade.

The most popular PHP framework Laravel has been using blade for a while now, and has been nothing but great.

You shouldn’t be against it just because it’s 1 more thing you have to learn. Functionality-wise, blade is just amazing IMO.

6 Likes
11

Yea I’m loving Blade, it makes me want to work with PHP frameworks all over again because it is so readable and just beautiful.

2 Likes
12

Is moving towards an MVC like setup a good move considering the Wordpress architecture with hooks and filters?