AI driven Chatbots with industry knowledge

[MadeMyDay]

Hi there,

another one finished, up and running. 

https://bots4you.de/

The website informs about bots4you which is a German based Chatbot creator. Special with this chatbot is its b2b purpose, that means it is pretty decent in "knowing" what customers of several industries (real estate, insurances etc.) want to know and describe their efficiency with nearly 80% of success for common customer inquiries. 

From the ProcessWire perspective I mainly use Repeater Matrix with which I only have one template (even for home) but 8 content modules that can be arranged like the customer wants to create different pages. Other than that I used TailwindCSS for the first time, but I am not convinced, at least in a PW environment. Downsides where: 

• build time when in dev mode (hot reload takes up to 6 seconds)
• purge of my php files was less than reliable. I ended up putting most of the classes on an allow list in the tailwind config. Could be my fault, but the overall experience wasn't that great.

Anyway, client is happy, and I am, too:

?

 

[kongondo]

2 hours ago, MadeMyDay said:

(hot reload takes up to 6 seconds)

This is unusual. How does your setup look like?

[szabesz]

@MadeMyDay Thanks for the showcase.

Note that the contact form in the English version is 404.

[teppo]

22 hours ago, kongondo said:

This is unusual. How does your setup look like?

Got to agree with Kongondo here. In my case the dev hot reload takes < 2s, and that's with some recent slowdowns (not sure what's going on in my system, but it used to be < 1s). Of course this also depends a lot on what you're doing at dev stage: are you running purge here as well, what else are you running on each rebuild (pre- or postprocessors and whatnot), which files are you watching, etc.

Depending on your setup there may be steps you can take to get it down considerably. In our gulp based workflow, for an example, one major bottleneck was solved by adding gulp-cached — on a moderately large site this took dev build time down from what was originally probably 6-10s to 1-2s.

Quote

purge of my php files was less than reliable.

Never had this issue either. There could be something else wrong, but usually this would mean either that you're actually not going through all those PHP files in the purge step, or you're using some sort of "constructed" class names (px-<?= $x ? 1 : 2 ?>). Not saying that you're doing something wrong, but again: this has been working perfectly for us.

Note: I've got some beefs with Tailwind myself, but those are all about the general methodology. Tech wise it's been really, really slick ?

[MadeMyDay]

13 hours ago, szabesz said:

@MadeMyDay Thanks for the showcase.

Note that the contact form in the English version is 404.

Thanks szaesz, fixed. ?

22 hours ago, kongondo said:

This is unusual. How does your setup look like?

Pretty basic I guess. But I also assume that something in there is slowing down the process, extract from gulpfile:

// CSS task
function css() {
  var plugins = [
    tailwindcss(),
    autoprefixer()
  ];
  return gulp.src(srcPaths.styl)
    .pipe(plumber())
    .pipe(sourcemaps.init())
    .pipe(stylus())
    .pipe(postcss(plugins))
    .pipe(sourcemaps.write('.'))
    .pipe(gulp.dest(buildPaths.css))
    .pipe(browsersync.stream());
}

Knowing that it should be faster, I can iterate over it and try to eliminate the bottleeneck, thanks.

Quote

Depending on your setup there may be steps you can take to get it down considerably. In our gulp based workflow, for an example, one major bottleneck was solved by adding gulp-cached — on a moderately large site this took dev build time down from what was originally probably 6-10s to 1-2s.

Interesting, could you give an example of your setup?

The other issue still remains. A typical .php of the project file looks like this:

<?php
    $cssClass = "";
    $textoutput = "";
    $waveClass = $page->checkbox1 ? " wave" : "";
    $colClass = $page->checkbox2 ? " flex-matrix" : " md:flex-1";
    $containerClass = $page->checkbox2 ? " matrix" : "";
    $containerHeadline = $page->text1 ? "<h2>{$page->text1}</h2>" : "";
    $cardoutput = "<div class='boxes__cards flex flex-1 items-stretch flex-col lg:flex-row {$containerClass}'>";
    $cardClass = "boxes__card";
    foreach($page->cards as $card) {
        include('parts/card.php');
    }
    $cardoutput .= "</div>";
    $output = "
        <div class='element element--boxes{$waveClass}' id='{$sanitizer->pageName($page->text1)}'>
            <div class='container content pt-8 relative z-20'>
                {$containerHeadline}
                <div class='flex items-start'>
                    {$cardoutput}
                </div>
            </div>
        </div>";

    echo $output;

Most of the tailwind classes don't get caught by purge, some do. I assume it is looking for sth like class="...". And my classes are dynamic depending on settings. I don't know how to solve this without adding a lot of overhead to the template files.

Quote

Note: I've got some beefs with Tailwind myself, but those are all about the general methodology. Tech wise it's been really, really slick ?
   

Absolutely. I really see the benefits and also it makes a lot of fun trying things out and adjusting "on the fly". But with the above mentioned problems the benefits were reduced too much. I am also considering Tailwind for some vue projects, but the overhead for dynamic classes scares me off a little.

[bernhard]

On 6/26/2020 at 11:39 AM, MadeMyDay said:

Great looking site as always! What tool is this? ? 

[teppo]

32 minutes ago, MadeMyDay said:

Interesting, could you give an example of your setup?

I had to take a closer look, and it's actually mostly related to our PHP task, which runs PHP_CodeSniffer (which can be very time-consuming). You can use this with any files, though — check out https://www.npmjs.com/package/gulp-cached. It's really easy to add, basically just require the package and add a single line to your gulp task.

The basic idea is that gulp-cached keeps track of files, and makes sure that files are only passed downstream if they've changed since last run. What this means in practice is that when using watch, the initial build may still be slow (none of the files being watched are cached) while subsequent ones are going to be much, much more performant, as all files that didn't change will be skipped over.

Other differences I can see with our setups:

• You seem to be running sourcemaps on every build. If this is really the dev/watch process, then I don't really see a reason to do that, and it's definitely going to slow things down. We're using gulp-if to check for env and only setting sourcemaps up if it's a production build (basically gulp build vs. gulp watch).
•  I'm not seeing anything related to purge here. If you're using the purge setting in Tailwind config, this is a relatively new thing and I really can't say anything about that — for me it seems easier to just run purge as a part of the gulp task:
   

// Tailwind extractor for purgeCSS
const tailwindExtractor = (content) => {
	return content.match(/[A-z0-9-:\/]+/g) || []
}

...
		.pipe(gulpif(argv.prod, purgecss({
			content: [
				config.paths.base + '**/*.php',
				config.paths.base + '**/*.js',
				config.paths.site + 'modules/InputfieldCKEditor/*.js',
			],
			extractors: [
				{
					extractor: tailwindExtractor,
					extensions: ['php', 'html', 'js']
				}
			]
		})))
...

32 minutes ago, MadeMyDay said:

Most of the tailwind classes don't get caught by purge, some do. I assume it is looking for sth like class="...". And my classes are dynamic depending on settings. I don't know how to solve this without adding a lot of overhead to the template files.

Actually it shouldn't — just having something like px-3 in a file with nothing else should be enough. Again this is based on the code I've posted above, so if the native feature is using some sort of "advanced" matching algorithm, it could be a major problem for a lot of code. Weird.

Note also that unless Tailwind has a mechanism for disabling purge on dev builds, you're going to be doing a lot of work that you probably don't need there. That could be another bottleneck. I'd probably just stick to a manual purge declaration in gulpfile. There's good documentation for that here, in case you need more details: https://tailwindcss.com/docs/controlling-file-size/.

[teppo]

11 minutes ago, teppo said:

Note also that unless Tailwind has a mechanism for disabling purge on dev builds, you're going to be doing a lot of work that you probably don't need there.

Quoting myself here, but just wanted to add that they do indeed have a solution for this ?

Quote

Now whenever you compile your CSS with NODE_ENV set to production, Tailwind will automatically purge unused styles from your CSS.

... so if you're using purge as defined in the Tailwind config file you need to make sure that NODE_ENV is not production when you're doing your dev build.

[MadeMyDay]

22 hours ago, bernhard said:

Great looking site as always! What tool is this? ? 

Danke Bernhard ? This Lighthouse score, built in in Chrome/Chromium. Look in DevTools -> Audit.

21 hours ago, teppo said:

I had to take a closer look, and it's actually mostly related to our PHP task, which runs PHP_CodeSniffer (which can be very time-consuming). You can use this with any files, though — check out https://www.npmjs.com/package/gulp-cached. It's really easy to add, basically just require the package and add a single line to your gulp task.

The basic idea is that gulp-cached keeps track of files, and makes sure that files are only passed downstream if they've changed since last run. What this means in practice is that when using watch, the initial build may still be slow (none of the files being watched are cached) while subsequent ones are going to be much, much more performant, as all files that didn't change will be skipped over.

Seems a very good idea. Will try that!

21 hours ago, teppo said:

You seem to be running sourcemaps on every build. If this is really the dev/watch process, then I don't really see a reason to do that, and it's definitely going to slow things down. We're using gulp-if to check for env and only setting sourcemaps up if it's a production build (basically gulp build vs. gulp watch).

well, I use/need sourcemaps in dev more than in production. But sourcemaps are not the bottleneck. The thing is: This is my standard gulp setup and it is usually so fast that I cannot even see the refresh in the browser because my eyes cannot switch so fast from editor to browser ?

22 hours ago, teppo said:

 I'm not seeing anything related to purge here. If you're using the purge setting in Tailwind config, this is a relatively new thing and I really can't say anything about that — for me it seems easier to just run purge as a part of the gulp task:

Purging is only done in production builds. And yes, I am using the purging in tailwinds config like this:

module.exports = {
  purge: {
    content: ['./src/*.php', './src/**/*.php', './src/php/*.php', './src/fields/layout/**/*.php', './src/fields/layout/parts/*.php'],
    options: {...}
              
  }
}

In dev the whole tailwind declarations are used (2MB css file). BUT: This is it! Thinking about it it doesn't make sense to bundle everything (including Tailwind) up in development and distribute one (large) CSS file. It would be better to distribute the Tailwind CSS as it is in dev and only process my own css/stylus files like I always do. Will try that. Thanks for the rubber duck debugging ?

22 hours ago, teppo said:

Actually it shouldn't — just having something like px-3 in a file with nothing else should be enough. Again this is based on the code I've posted above, so if the native feature is using some sort of "advanced" matching algorithm, it could be a major problem for a lot of code. Weird.

yes, this is the other major problem. I really don't see why this just doesn't work. I already quoted the tailwind config above and you see I already tried to add more sources and be more specific, but somehow a lot of the classes just don't get recognized. Problem is the first time I purged or better tried to purge the project already was pretty complex. So I have no clue which classes are missing and why. I will try to set up a test case with an empty PW installation and then try to observe what the problem is. But thanks for pointing out that it should work even if the classes are not in a proper HTML syntax.