Once again, Google has blown me away (it still is... no idea where this will land actually). Never heared of it, until yesterday. Google's Material Design. Material Design is Google's open source design system for Android, iOS, Flutter, and the Web. On a side note, the implementation for the Web isn't ready yet. I can't wait for that to happen though.

I came accross Material when searching for open source icons. As much as I like Font Awesome for pioneering this area, it looks like they got far behind on the competition.

I was thinking, there must be an alternative to Font Awesome. That's how I found Google's Material Symbols. 2875 open source icons, free to use (compared to only 675 in Font Awesome 4.7.0.)

All it takes is:

Because I was busy doing QS-stuff anyway, I gave this a whirl:

Even though this feels like restoring an oldtimer by repainting it, you have to admit... it makes QS look a little less 90's. And on top of that, I got rid of 68 ugly gifs in the QuickerSite codebase. Cheers on that! 

This feature is available in the lateste codebase (not released yet) on GitHub.

I've made a small cosmetical change to QS. The changes are available on GitHub. The only files that changed are /asp/includes/javascript.asp (needed) and some more in the /asp folder (but you don't really need those).

I have used some more padding, a less agressive border-color and rounded borders for text-boxes, selectboxes and textareas. This affects both the backsite and some modules in the front (forms, polls, myprofile, guestbooks, etc). It somehow makes QS look a little less nineteeny I think. Hope you like!

It sounds like a wrong idea to even search for and use it. But it's not. I'm hosting both pietercooreman.be and asplite.com on 100% free static website hosting for 3 years now. On GitHub pages. GitHub pages offers pure static website hosting (no server-side scripts allowed) for each and every project you have on GitHub. SSL is included for free as well!

Two minor limitations

1. Published GitHub Pages sites may be no larger than 1 GB
2. GitHub Pages sites have a soft bandwidth limit of 100 GB per month. 

I admit, I've become a big fan of GitHub pages, pretty much like I've become a fan of static websites builders like Mobirise and Nicepage. Or Bootstrap if you like to handcode your own. Combined with some embedded widgets, you're all set. Check out this list of popular website widgets. Why would you still need a CMS today? And what happened to Webmatrix, the most intuitive web development IDE that MicroSoft ever built? Why was it replaced by Visual Studio Code, the darkest and most depressing code editor ever?

You find a lot of tutorials on how to use GitHub pages. Check them out!

Update: the solution discussed below is generating CORS errors in JavaScript. Long story short, you need to allow CORS in IIS.

While VBScript is equipped with asynchronous components (httprequests, shell), when using them in ASP they're always synchronous. Classic ASP does not support asynchronous calls whatsoever. Classic ASP follows a strict set of sequences, which means that operations are performed one at a time, in perfect order, top to bottom.

Why would you need or use async calls in ASP? Imagine you want to run a véry long process after clicking a button: generate 10000 documents, or send out 10000 emails... This is not something you want the visitor to wait for. These things can take many hours.

There is a way around this limitation though. The solution: AJAX calls. Rather than perform async calls serverside, you can let AJAX do the job. AJAX calls are always asynchronous. The browser will never wait for an AJAX call to finish when loading or browsing away from pages.

However... Imagine you're browsing www.quickersite.com. You click a button that loads www.quickersite.com/ajax through AJAX. If www.quickersite.com/ajax takes 10 minutes to finish, your browser will wait 10 minutes before you'll be able to further browse www.quickersite.com. This is not what we want. We somehow shift the problem from the server to the browser.

There is a way around this. Instead of loading www.quickersite.com/ajax, you can load ajax.quickersite.com. Browsers assume that www.quickersite.com and ajax.quickersite.com are two different websites. Loading ajax.quickersite.com will not block visitors on www.quickersite.com whatsoever. Problem solved.

Be careful though. When calling ajax.quickersite.com, you cannot rely on the cookies/sessions/application/security you have on www.quickersite.com. You have to program your way around that shortcoming by making sure there are no security-risks when loading external urls. You may need passwords or tokens to ensure that urls load only once, or load only under specific circumstances.

There is another thing to keep in mind when using ASP for long processes, like sending out 10000 emails. Make sure to set Server.ScriptTimeout to a large number (default is 90 seconds). There is no (documented) maximum value. You may want to set it to 10800 in specific circumstances, allowing an ASP page script to run for 3 hours.

The bigger issue is though: is it a good idea to let an ASP page run, unattended, unmonitored, disconnected from the browser...  for hours? Maybe not... or maybe not always. ASP pages are not designed to run eternally, that's for sure. IIS can - at any time - reload applications, be reset, or simply crash a site when it eats too much memory, just to name something. In some cases though, where pages are running for few minutes only - or do not need loads of memory -  this is a legitimate workaround. I have used this technique several times with success.

Some sites report that classic ASP is "end of life". The funny thing about this is, these are articles written between 5 and 10 years ago. Even Wikipedia reports that "ASP was supported until 14 January 2020 on Windows 7."

This is fake news. There is no official EOL policy for classic ASP. As from IIS7, classic ASP is implemented as an ISAPI filter in IIS, configured to kick-in ASP.DLL as soon as an *.asp file is requested. It's therefore more accurate to say: classic ASP will be supported as long as IIS supports ISAPI-filtering. Or even better: the end-of-life of classic ASP is inseperable from the end-of-life of IIS itself. That will be the day MicroSoft pulls the plug on its Server-products.

Same story for VBScript. VBScript is as dead as ASP, but it's actually a (default) part of Windows Script Host (wscript.exe). Again, there is not a single reason to believe that VBScript will no longer be supported in WSH in the future. WSH is part of the Microsoft Windows Operating System ever since ... Windows 95.

Both classic ASP and VBScript are underlying technologies. ASP is a toolset for web developers. VBScript is a visual programming language. Other services and softwares depend on them (both MicroSoft and non-MicroSoft). They're not to be confused with end-user products that need security-fixing, updates, support, legal follow-up, etc. Classic ASP nor VBScript are even included in the "Microsoft Products and Services" lifecycle database. IIS is included though. It follows the Component Lifecycle Policy, meaning that it's supported as long as the product where it's a component of is supported. That is the Windows Server family.

Therefore, I truly believe that classic ASP and VBScript will be available in Windows OS for at least another 10-15 years, probably longer. Nobody knows what happens next. This is also true for any other technology you'd use today. So there is not a single reason to not consider classic ASP/VBScript to develop web applications. I can tell. I'm still doing so. And I love it. As long as someone is coding ASP/VBScript, it's alive. I must admit however that I'm more and more feeling lonely. It appears that most web developers don't even know what classic ASP exactly is/was. I'm trying to turn the tide. But that will never work on my own...

The problem: by default classic ASP developers face a 200kB (200000 Bytes) upload limit in IIS Express. Unlike in IIS5-11, IIS Express has no GUI-way to configure this value.

IIS Express is available as a development-host in various MicroSoft IDE's like Visual Code and Visual Studio. I use it in Webmatrix, an IDE that MicroSoft decided to stop developing some years ago, but still available on my 7 year old laptop.

The solution: change the ASP limits for maxRequestEntityAllowed in
C:\Users\XXXX\Documents\IISExpress\config\applicationhost.config

Search for "<asp ". Change the entry to:

The maximum value for is maxRequestEntityAllowed  is 2147483647 (integer / 2GB). But in my experience the real upload limitation in classic ASP is 100MB approximately. When uploading larger files, I get a "Microsoft Cursor Engine error '8007000e' - out of memory"-error.

Not only will this enable uploading larger files. It will also allow to submit large datasets to urls (in an ajax call for instance). 

You can read more about the ASP limitations in IIS here.

For a customer I recently setup an easy way to create PDF flyers. They had to be printable in various formats (ie: A5, A4, A3). ChromeASP turned out to be a lifesaver once again.

This is what I was able to deliver with ChromeASP. Behind the scenes, a basic HTML-file gets converted to PDF with ChromeASP. Live example: http://pdf.asplite.com/ (test 5). Even though I use a good old table driven design, it's still possible to have all sorts of objects (like the QS logo) float anywhere you like.

As Chrome (headless) is creating the PDF files, there are absolutely no limits when it comes to HTML/CSS/JavaScript support. Chrome simply supports it ALL, and how! Chrome even automatically fixes all sorts of errors and inconsistencies in your html. Even the most powerful and well known PHP PDF-libraries are looking at headless Chrome as their unbeatable successor. No way you can compete with Google. Google has always created the best softwares around (Search, Android, Chrome, Youtube, Gmail, Drive, Photos, Ads,…. )

Google (the open-source Chromium-community that is) is currently completely refactoring headless Chrome. I am silently hoping in the future headless Chrome could also be used to easily (un)zip files and folders, create all sorts of binaries, easily edit pictures, etc. from within a classic ASP application. This would be a big thing and – sadly – take lots of open source projects down. But for once classic ASP developers would be able to shine again. Let’s pray for that. Amen.

In my search for a mobilefriendly email template to use in QuickerSite, I quickly realized that most designers stick to a table-driven setup, even in 2023. Unlike most browsers, some email readers are ridiculously outdated. Outlook 2003, 2010 or Outlook Express... remember ? They're still in use though.

For QuickerSite, this template is about the most basic mobile-friendly email template I could come up with.

This is how it shows on my mobile phone:

and this is how Gmail displays it on a Windows laptop:

It acts responsive, right? And it's pretty readable in both cases. I do not specify a default font-size. I have seen some designers set a default font-size of 13px. I don't think that's necessary, but it looks like that's a good font size on both large and small screens.

Anyway... happy to be able to send mobilefriendly newsletters in QS... after all :) 

UPDATE 31/03/2023: A bug in Chrome currently breaks the "export as screenshot" feature that I liked a lot. Screenshots now default to 800/600px and do not respect the window-size parameter anymore. This should be fixed in Google 113. 

UPDATE: I turned this into a GitHub repository. Make sure to give it a try and report any issue! Thanks!

For a customer, I needed to create pdf files in my classic ASP web app. After looking into both commercial and free PDF creating software, I found out that it can easily be done with Headless Chrome. For free!

You need to have Chrome installed on your computer/server.

Here's the code:

In short, this script launches a command line app, changes the directory to the chrome application, runs Chrome with the parameters needed and finally creates a PDF file from the QuickerSite website. Not only a PDF is generated. I also added a screenshot. "Exit" closes the cmd line app. 

Don't get too excited though. This only works if your IUSR has the necessary permissions. This will never work on shared hosting. But if you run your own Windows Server, this might help you out. You also have to create a folder ("D:\Chrome" in this case) where the Chrome user can dump its logs and errors. That's it! 

Creating PDF files and images on the fly is something I'm looking for for quite a while in classic ASP. It looks like having this headless Chrome-thing at my fingertips, is going to help a lot! The most exciting thing about this, is that classic ASP developers are - for once - not forced to use outdated or badly supported (or expensive) COM dll's or one or the other open source PHP library to get the job done. This is Chrome people... probably the best software on the planet. Being able to use Chrome features like creating PDF files and generating (complex) images from any HTML/CSS/JavaScript is a big big thing. This opens up a lot of opportunites to classic ASP developers, as long as you run your own Windows server. Have fun!

For me personally 2022 was a good year. I made some new friends. A new band. New great development in Classic ASP. For my employer in Belgium, I built a big application on top of aspLite. aspLite turns out to be the most versatile and powerful AJAX-library I've ever written for Classic ASP. It could even get much better if other Classic ASP developers would join and contribute. Most Classic ASP developers however feel too much shame about being stuck with a dead technology. But they shouldn't. Classic ASP is going nowhere. And that's exactly what makes it a very attractive and solid technology. I hope MicroSoft never touches it again actually... they would mess it up no doubt.

As classic ASP is available for Windows 2022 servers, the end-of-life for classic ASP will never be before Oct 14, 2031. In all honesty, I can't think of a single reason why classic ASP would not ship with any future Windows server edition. That makes it the most reliable web development technology one can use on a Windows server (Windows NT 4.0 (1996!) onwards). Any ASP.NET version or variant has been given up or has been replaced by yet another version over the years. So stay away from ASP.NET... Use classic ASP, or better... go PHP. PHP is even older than classic ASP. The older the better... I'm getting old...

For nearly 10 years now, QuickerSite is in idle mode. And more and more I tend to look at this as an asset, a "selling point". No bugs. No security issues. No critical updates. No urgent hotfixes or patches. QS is fine as it is. And the longer this takes, the better it's looking. I have setup a couple new QuickerSites in 2022. I used QS for a formbuilder (basically only using it for all sorts of forms) and another acts as an online journal, reconverting the QS catalogs to a basic library-manager. Nothing spectacular. But very efficient and nobody cares or even knows it's classic ASP and nothing but QS in the back. Love it.

I do feel like bringing Bootstrap 5 into the QS backsite would be a great idea though. And it would not necessarily be too complex. It would not cause any security or any other blocking issue in any way. But it would drastically improve backsite usability and looks count too. It would also be great to finally get rid of anything that still relies on or refers to Artisteer. Teaming up with Artisteer was the worst decision I ever made in QS. I should rather have chosen Bootstrap back in 2010. Bootstrap could have been a major selling point for QS. Artisteer never was.

Happy 2023 to all of you!

Pieter

I have recently installed QuickerSite on a Windows Server 2022 (hosted on Azure). No problems as such. Still the exact same things to keep in mind:

• Install IIS and ASP using the Server Manager
• Enable 32-bit applications in the IIS application pool
• make sure permissions are set (ie make sure Everyone has full permissions on the fysical directory of your QS)

But I faced another problem. There is a bug in the built-in SMTP server.  In short: it does not work. I hope MicroSoft will fix that in the coming months. But I doubt so. The built-in SMTP server dates back from Windows 2003 and still needs IIS6 to configure it. I guess it's time to move away from that SMTP server. I installed a 3rd party SMTP server named MailEnable. I used MailEnable before on a Windows 2008 Server. So far so good.

To summarize: QuickerSite is fully compatible with Windows Server 2022. But you need a 3rd party SMTP server to get the emails working. That's some good news at last. 

I feel like ... writing a blog post. It's been ages.

asplLite is doing pretty wel. It's doing great actually. I get very promising feedback from users all over the world on a regular base. asplite is also very well received on Github with nearly 40 stars. Not bad for classic ASP development. I'm currently working on a first huge web application using aspLite and the results are very satisfying. aspLite is reliable, bugfree, fast, lightweight, secure, slick. Especially the ajax formbuilder is a huge step in the right direction when it comes to modern web applications built in classic ASP. And Bootstrap... I love Bootstrap, no doubt one of the most powerful CSS-frameworks around.

Did I mention this before? Classic ASP being left for dead by M$ has caused it to be one of the most stable and secure web development frameworks around. No upgrades, no fixes and no security issues basically means: no surprises and no headaches for our applications. They just keep on running. Always. Go tell WordPress users. 

On a sidenote, I won a regional singer-songwriter contest few months ago. As a result, I'm having much fun performing on lots of stages these days. In a few weeks from now, I'll be performing on a TV show with over 1.000.000 viewers. Looking forward to that. There was a time that I was dreaming of being as successful as a singer/songwriter then I was back then as a web developer. Today it's the other way around. It turns out that the grass is always greener on the other side after all :)

Cheers! Pieter