New post: Rebuilding processwire.com (part 1)

[ryan]

This post contains an introduction to our plans for rebuilding the ProcessWire.com website. In part one, we take a look at the initial strategy, framework, and concept for the new site, primarily from the development side:

https://processwire.com/blog/posts/rebuilding-the-processwire.com-website--part-1-/

[pwired]

Great to hear about the rebuilding plans. Will there be a place on the new site for a vertical news ticker ? Something like a vertical ticker that shows:
latest post by . . . . . . .

 

Quote

The new site uses . . . . . . along with the Uikit 3 front-end framework.

I know that the Uikit 3 framework is favorite for some reason, but why exactly ? Is it because it is a bit less bloat than Bootstrap ? When I look at the number of uikit3 classes that has to be written on a single line to get something accomplished, you need just as many and they look just as cryptic as the Bootstrap classes. Take a look at the Gridlex framework: it is so lightly without the need for writing x, y, z classes on a single line , and yet it is so complete. If someone can lighten me up what Uikit3 can do what Gridlex cannot do, that is of course for 90% of what is most of the time needed. Is the complete Uikit3 going to be used, or a compiled down version ?

[Jonathan Lahijani]

21 minutes ago, pwired said:

Great to hear about the rebuilding plans. Will there be a place on the new site for a vertical news ticker ? Something like a vertical ticker that shows:
latest post by . . . . . . .

 

I know that the Uikit 3 framework is favorite for some reason, but why exactly ? Is it because it is a bit less bloat than Bootstrap ? When I look at the number of uikit3 classes that has to be written on a single line to get something accomplished, you need just as many and they look just as cryptic as the Bootstrap classes. Take a look at the Gridlex framework: it is so lightly without the need for writing x, y, z classes on a single line , and yet it is so complete. If someone can lighten me up what Uikit3 can do what Gridlex cannot do, that is of course for 90% of what is most of the time needed. Is the complete Uikit3 going to be used, or a compiled down version ?

UIkit3 is a bit more of a utility class oriented CSS framework.  The benefits of utility based CSS are excellently summarized in this article, which I side with given my own evolution with CSS:

https://adamwathan.me/css-utility-classes-and-separation-of-concerns/

Gridlex is just a grid system from what I can tell.  If you need all the usual components (accordions, tabs, etc.), UIkit3 has it covered extremely well, especially compared to the other big CSS frameworks.  Many great options.  I rarely pull in other libraries since UIkit has it covered, and since it's all under one roof, it's very consistent and doesn't lead to conflicts.

[arjen]

Great post Ryan! I am really interested in your "inside out" approach. Would you mind keep sharing some details about your process in the next posts? I'm positive you keep an eye on the quality of the new website. 

[AndZyk]

Happy to hear that the website will be finally rebuild. I hope a modern design will attract more potential users. With UIkit you have made an excellent choice for a framework.

I would wish for a better search function, maybe powered by a service like Algolia. ?

4 hours ago, pwired said:

If someone can lighten me up what Uikit3 can do what Gridlex cannot do, that is of course for 90% of what is most of the time needed.

Having worked with UIkit for two years now, I am obviously biased, but in my opinion it is the best framework at the moment. It is far more complete as Bootstrap with more components and more active development.

Gridlex is a grid system, not a framework. The grid component in the UIkit framework is maybe 5% of the whole framework. So the UIkit framework can do 95% more than Gridlex. ?

[pwired]

Quote

Gridlex is a grid system, not a framework . . . . . So the Uikit framework can do 95% more than Gridlex

Yes I know that Gridlex is not a framework, and that the Uikit framework can do 95% more than Gridlex
also means that you are talking about uikit.min.css = 243 kB and uikit.min.js = 128 kB
with gridlex.min.css only 35 kB.

Do you really need that 95% more for every new project, or simply leave it untouched ?
Unless of course you are going to recompile Uikit for every new project. How many people are really
going to do that and figure out what can be left out and tweak compile Uikit for the next project ?

The other way around is much more effective: use only libs needed for your project the same way
you use your own snippets.

Besides that, I noticed that every new project you do with Uikit (bootstrap and the others the same)
starts to look the same like your other projects you did before. Problem is you are using same styles
as so many other web sites out there made with Uikit. Not a good thing for brand awareness.

Maybe I can make my point more clear with this article:

https://dev.to/bitersen/case-against-premade-css-frameworks--3jn

 

[Robin S]

Excited about the new processwire.com!

5 hours ago, AndZyk said:

I would wish for a better search function, maybe powered by a service like Algolia.

I agree that the search could be better - especially if processwire.com is to be advertised as powered by ProcessWire. I get why the forum search might be poor because that is not powered by PW, but it has long puzzled me why the Modules Directory search is so poor seeing as that is PW-powered. An example: right now in the "Latest Additions" section we can see a module from netcarver titled "Street Address". So how come when I enter the exact words "Street Address" in the search box that module doesn't appear as the first result, and even doesn't appear on the first page?

https://modules.processwire.com/search/?q=Street+Address

[horst]

Good point @Robin S.
When searching the class name StreetAdress in one word, it is the first result. But it has to be it also when searched in two words!

[AndZyk]

@pwired

I don't wanted to start a discussion about frameworks here. I just wanted to point out that UIkit is a good choice for a framework to rebuild the new ProcessWire website and comparing it to a grid system are two different things.

 

6 hours ago, pwired said:

Yes I know that Gridlex is not a framework, and that the Uikit framework can do 95% more than Gridlex
also means that you are talking about uikit.min.css = 243 kB and uikit.min.js = 128 kB
with gridlex.min.css only 35 kB.

The UIkit framework is (as most frameworks are) modular. So if you want to use only the grid system, you can include only the grid system in your stylesheets and it should have around the same size. I don't know how much exactly because I have never just compiled the grid system and I don't count bytes, because in my opinion the size of your stylesheets are the least thing to worry about.

 

6 hours ago, pwired said:

Do you really need that 95% more for every new project, or simply leave it untouched ?
Unless of course you are going to recompile Uikit for every new project. How many people are really
going to do that and figure out what can be left out and tweak compile Uikit for the next project ?

No, I think most of the people don't use the whole 100% of a framework. Personally I use probably around 40% and include the whole framework anyway, because I like to have a good set of components available. It lets me focus more on the content and design while developing a website and I don't have to reinvent everything (grid, utility classes, slideshow etc.) from scratch. But as mentioned, if you only want to use a part of a framework, you can simply don't include the rest. ?

 

6 hours ago, pwired said:

The other way around is much more effective: use only libs needed for your project the same way
you use your own snippets.

That is the same approach as using a framework. Except when using different libs from different developers with different support and compatibility, you use components from one developer that are always compatible with each other. Before using framework I also used one lib for a slideshow, one for filterable grid, one for lazy loading images etc. With UIkit I only need one framework or if some lib does something better, I use this lib instead.

 

7 hours ago, pwired said:

Besides that, I noticed that every new project you do with Uikit (bootstrap and the others the same)
starts to look the same like your other projects you did before.

That is true under the assumption when leaving the framework untouched and using it plain. The part of a good designer/web developer is to build styles on top of a framework and make it look different. In my opinion a framework should not be used plain and is just a foundation for an individual design.

 

Of course everything I say is my opinion only and everyone is free to choose whatever suits your projects the best. Using a framework is not always the best choice and for designs that are different, I also don't use a framework. But for a large project like rebuilding the ProcessWire website it can help a lot to have a good foundation and the UIkit framework is this. 

If you want't to discuss further @pwired, you can create a topic, invite me to an existing one or send me a PM. ?

 

3 hours ago, Robin S said:

I agree that the search could be better - especially if processwire.com is to be advertised as powered by ProcessWire.

Yes, the current search function is not really good, especially when you have build better search functions with ProcessWire. ?

In my opinion it should be able to search the whole website (blog posts, modules, docs, API, etc.) and have autocomplete suggestions.

A service like Algolia may be not necessary and this could be probably achieved by ProcessWire alone, but I had to work with a similar CMS for a while which uses Algolia on its website and it was a breeze to have a good search function for learning a new CMS. Of course the CMS is not as powerful as ProcessWire and you can remove the link if this is advertising.

Regards, Andreas

[pwired]

Hi, AndZyk

Thanks for sharing your post and perspective

Quote

If you want't to discuss further @pwired, you can create a topic, invite me to an existing one or send me a PM.

No it's ok. My post was not about Uikit3 it self, but more about why Uikit is going to be used in the new Processwire website.

I always loved to experience Processwire as a system that stays as close as possible to the core of things.

Take a look at this thread that is going on about designing responsive:

Edit: replaced wrong link with the correct one: (sorry Horst)

https://processwire.com/talk/topic/19964-building-a-reusable-function-to-generate-responsive-images/

That is much more in the spirit of Processwire instead of using things like Uikit.

[Tom.]

20 hours ago, pwired said:

I know that the Uikit 3 framework is favorite for some reason, but why exactly ? 

Well, I use personally use UIkit 3 + TailwindCSS. Tailwind you are going to hear a whole lot more about in the upcoming months. I know you are talking about file size and this is exactly why UIkit + Tailwind is great! 

I don't really use UIkit's CSS at all. I just use the JavaScript because the amount of utilities they have manage to pack into 130kb (less than most images) is amazing. I'm talking Parallax, Sliders, Lazy Loading Images, Srcset utilities, placeholder generators, scrollspy, sticky. Most of which can be and usually is utilised in any project. I challenge you to get all of that under 130kb. Also it doesn't have any dependencies. 

Tailwind you can get down to about 3KB per website using Purge and Gulp/Webpack. It truly is amazing and Utility first CSS is such a refreshing way to work with CSS. I know all the arguments, and I'm a minimalist. I don't like all the classes too. But Tailwind's benifits out weigh the cost. 

1. You don't have to struggle with inherited styles, or coming up with class names to define each section, some of which may look the same but be very different in content. 

2. Consistency, it puts pressure on you to keep things consistent. So you hardly stray to loads of different type sizes and colours. 

3. With Purge, you can have an entire website styles in ~3kb. 

I believe Ryan chose UIkit 3 because he has learnt the classes and is confident with the framework, and is impressed with the JavaScript utilities. And because you can build website much quicker using it. I see it as a hybrid between utility and a standard framework. It offers many utility classes. You could also Purge UIkit's CSS and get it around 160KB. 

I don't believe that this isn't a good fit for ProcessWire as you have previously mentioned. Many who use ProcessWire love UIkit. It follows the same philosophy: A powerful framework, that is easy to understand and learn to get things done quicker. Just like ProcessWire gives developers confidence in that they can do challenging bits of functionality easily with the power of ProcessWire's amazing API (like seriously, I built a real estate system using ProcessWire, something I wouldn't have dreamed of doing on any other platform). Well UIkit also gives that confidence to the front-end. 

But if I was to choose for myself, I much prefer pairing Tailwind for the CSS and UIkit for the JavaScript. That ~140KB (Tailwind + UIkit) covers me for most websites I build. 

[tpr]

4 minutes ago, Tom. said:

I don't really use UIkit's CSS at all. I just use the JavaScript because the amount of utilities they have manage

So you style the js utilities on your own?

[pwired]

Hi Tom,

Thanks for picking up my question and answering it first in the light of Processwire, and not Uikit3.
This was exactly what I was hoping for someone would be able to do.

Quote

Well I use personally Uikit 3 + TailwindCSS, I don't really use UIkit's CSS at all. I just use the JavaScript pairing Tailwind for the CSS and UIkit for the JavaScript.

Very good example of bringing things together in a much more efficient way.

 

Quote

Quote from Tailwind
Tailwind is different from frameworks like Bootstrap, Foundation, or Bulma in that it's not a UIkit.
Tailwind is a utility-first CSS framework for rapidly building custom user interfaces.
It doesn't have a default theme, and there are no built-in UI components. It also has no opinion
about how your site should look and doesn't impose design decisions that you have to fight to undo.
Tailwind provides highly composable, low-level utility classes that make it easy to build complex
user interfaces without encouraging any two sites to look the same. if you want a huge head start
implementing a custom design with its own identity, Tailwind might be just what you're looking for.

Exactly my point and also, such an architecture has the same spirit to pair with Processwire.

Thanks for sharing all this.

 

[Tom.]

1 hour ago, tpr said:

So you style the js utilities on your own?

Yeah, I usually just copy the code over the CSS just for that utility then customise it to how I want it to look. It also means I only get the CSS for the utilities I'm using. Very few utilities actually require CSS. Things like masonry grid, grid filtering and parallax don't require UIKits CSS.  You can get to the CSS of just a component on GitHub: https://github.com/uikit/uikit/blob/develop/src/less/components/slider.less

[ryan]

My interest in using Uikit for this particular site is largely for the collaborative aspect. Having a common, already-known, well documented and tested framework for the front-end just seems better for collaboration here. I know a lot of people here are already familiar with it as well. There's also the aspect of being able to develop the site without necessarily knowing the final look of it. Uikit is designed for this kind of prototyping and gives us a result that can be tailored using already known/documented means (collaboration again). That there's a lot of crossover between Uikit's components and what we will need for this site is also helpful, and will no doubt save time. 

The current site was also a collaborative one, but it didn't use a framework. Instead it used various strategies that may be quite good and efficient, but I've never understood as well as I would have liked. So when it comes to making updates on the code side, I feel like I'm working around things rather than with them. Since I've got to ultimately maintain the site for the long term, I like having the familiarity and consistency of an established and documented framework behind it. 

In the context of the ProcessWire site, these aspects are more important to me than size of the eventual css files. If I was developing a different site the considerations might be different—I might still use Uikit, or I might go a different route, or go sans framework, all depending on the context and needs of the site. So I'm not suggesting that everyone should be using Uikit, just suggesting it seems like a good fit for this particular project, as it has been for some others. 

[pwired]

Processwire lets you make websites not the way how processwire works, but the way how you work.
Processwire has no system restrictions and does not impose any system rules, it gets completely out of the way how you make websites.

This is what Processwire sets apart from so many other systems out there and the reason why we love it so much.

Frameworks like Uikit are a set of pre-styled and themeable components. If you want to build a design, that stands out,
you end up fighting with default styles and undoing things. This in contrary to Processwire.

So, why not chose a system that gets out of the way how you make a design that stands out, in the first place ?

Yes I know, Uikit is great for working in a team on the accepted format for CSS, but I am sure that there are systems out there
that both get out of the design way and are good for working in a team.

Think about systems out there with a configurable set of utility CSS classes. Some of them even have the tools to quickly build your own.

I rest my case.

[teppo]

20 hours ago, pwired said:

Processwire lets you make websites not the way how processwire works, but the way how you work.Processwire has no system restrictions and does not impose any system rules, it gets completely out of the way how you make websites.

This is what Processwire sets apart from so many other systems out there and the reason why we love it so much.

Frameworks like Uikit are a set of pre-styled and themeable components. If you want to build a design, that stands out,you end up fighting with default styles and undoing things. This in contrary to Processwire.

I know you already rest your case, but still wanted to point out that Uikit is actually very configurable, meaning that you can pick and choose the components you need. You don't have to include the full framework, and when using SASS or LESS you can easily recompile the framework at any time. There's also another thing that in my opinion makes it a great fit for ProcessWire: Uikit also includes the concept of hooks. You quite literally modify it the same way as you'd modify ProcessWire.

The point behind front-end frameworks is that you don't have to reinvent the wheel every single time. In most cases our grids, carousels, cards, and whatnot are not really that different from project to project. Sure, they are styled differently, and may even behave differently, but the basic structure and function is similar. So, why write a new component every single time when you can reuse the old structure/behaviour and just give it a brand new bespoke look and feel?

What you're essentially claiming is that every Uikit site looks the same (or requires a lot of hacks to not), yet I disagree. Again if you take an out-of-the-box version of Uikit and use the ready-made default theme (you did notice that using it is completely optional, right?) then yes, it's going to look like... well, an out-of-the-box Uikit with a ready-made theme. Just don't do that, and you'll be fine.

Yes, with a framework there will always be some amount of configuration and hooking/overwriting involved, but that's a small price for the benefits you reap.

For arguments sake: if we thought that all pre-made components were pure evil, we shouldn't be using ProcessWire either. ProcessWire doesn't dictate your sites look and feel, but it sets a baseline for how it'll work behind the scenes. Uikit does the same for the front-end. Both are easily configurable and modifiable. One might even go as far as say that they are natural allies – two parts of a whole.

For the record, before writing this post I was not fully convinced of Uikit: I've been using Foundation, which in my opinion is superior in many ways, and has a rather different method of modification – essentially a massive config file for modifying pretty much every single thing you can imagine. But diving into the Uikit docs made me like it a lot more, and not least so because it really does have certain similarities with ProcessWire itself. In short: Uikit is a great choice for the new processwire.com.