materialize VS Caddy

The new, long awaited release is finally out there!!1 Please check it out at https://materializeweb.com/ and use it in your next project. It is still in alpha, but all features from the previous version should work as expected. Please use it and play with it. We are open for feedback and hope you save a lot of time during development / your creation process. Have a good day! best regards.

Check it out here https://materializeweb.com/

What do you think about our project Materialize? It is a Design Framework for Web Developers. Check it out at https://materializeweb.com

My first PR took much longer than my expectation since it was my first open source contribution. I was implementing a feature to add typing input capability to graphical timepicker (materializecss timepicker PR). It was pretty rewarding experience since my change is added to the site publicly accessed! After a while, they invited me to their organization. I haven't checked what's going on in the organization yet, but it is a good feeling that I can continue my contribution as a member of materializecss family. And people in other communities are very welcoming and friendly. I should definitely do more after Hacktoberfest and my OSD600 course.

So the key point is to use input tag for user to type while not harming any part of existing styling. input tag is tricky because I had to forcibly override basic CSS attributes. I think Materialize CSS has a consistent and well-defined styling that I don't want to ruin any part of it. I added an event handler with my main function inputFromTextField(). Existing function gets hour and minute input from graphical interface. Now I had to do the reverse. Once user inputs a number, the clock gets drawn. I wasn't 100% satisfied, but I wanted to ensure that my strategy is ok for the maintainer. So, I organized my code so that it looks ok for PR review. I was very nervous to send my PR but this is my first open source contribution trial. It is still under review but I feel positive that my PR will be accepted once I thoroughly address the feedback.

> The fact of the matter was that _servers aren't actually easy_. Caddy v1 tried to give the illusion that it is, but it just caused more problems, really.

You know, as someone who used Caddy v1 pretty extensively (still probably have it running on some of my homelab boxes), i never really ran into those supposed problems. Maybe they'd manifest in more complex configurations, but as a reverse proxy, file host, web server that's integrated with PHP or even something to allow setting up basicauth, i never found it to be lacking.

That's not to say that Caddy v2 is bad, just that someone for whom v1 worked perfectly might find it a bit cumbersome to move to the newer version, as the old one is no longer supported. Of course, you can say the same about JDK 8 vs JDK 11+ etc.

> Also, any time someone brings up the malicious fork "wedge", it saddens me.

If i recall correctly, it just took the project and rebranded it, which isn't necessarily malicious (for example, aggregating and selling users' data would). That's the nature of open source - anyone who wants to do that, can.

Of course, i think that the fork is also irrelevant because they couldn't actually be bothered to maintain the fork and nobody cared for it, much like how other projects, like Materialize.css, ended up.

For example, here's the original: https://github.com/Dogfalo/materialize

Then someone got upset that the project was abandoned (even though they were taking folks Patreon money): https://github.com/Dogfalo/materialize/issues/6615

They created a fork of their own: https://github.com/materializecss/materialize

Which promptly died down because there just wasn't enough interest in maintaining it. That's just how things go sometime.

There is actually a fork of this project as it is unmaintained currently that can be found here and is rather active: https://github.com/materializecss/materialize

These projects use Caddy as my local development server, Dart Sass for converting my Sass files to CSS, elm, elm-format, elm-optimize-level-2, elm-review, elm-test (only in Calculator), ShellCheck to find bugs in my shell scripts, and Terser to mangle and compress JavaScript code.

No, look at the associated unit test: https://github.com/caddyserver/caddy/blob/c6eb186064091c79f4...

If that test fails we could serve PHP source code instead of having it be evaluated, a major security flaw.

However, it's very unlikely that .NET developers will directly expose their Kestrel-based web apps to the internet. Typically, we use other popular web servers like Nginx, Traefik, and Caddy to act as a reverse-proxy in front of Kestrel for various reasons:

I think that recompiling with upgraded Go will not solve the issue. It seems Caddy imports `golang.org/x/net/http2` and pins it to v0.22.0 which is vulnerable: https://github.com/caddyserver/caddy/issues/6219#issuecommen....

Caddy [1] is a single binary. It is not minimal, but the size difference is barely noticeable.

serve also comes to mind. If you have node installed, `npx serve .` does exactly that.

There are a few go projects that fit your description, none of them very popular, probably because they end up being a 20-line wrapper around http frameworks just like this one.

[1] https://caddyserver.com/

Each app’s front end is built with Qwik and uses Tailwind for styling. The server-side is powered by Qwik City (Qwik’s official meta-framework) and runs on Node.js hosted on a shared Linode VPS. The apps also use PM2 for process management and Caddy as a reverse proxy and SSL provisioner. The data is stored in a PostgreSQL database that also runs on a shared Linode VPS. The apps interact with the database using Drizzle, an Object-Relational Mapper (ORM) for JavaScript. The entire infrastructure for both apps is managed with Terraform using the Terraform Linode provider, which was new to me, but made provisioning and destroying infrastructure really fast and easy (once I learned how it all worked).

So I dug a little deeper and came across this gem: Caddy. Caddy is this fantastic, extensible, cross-platform, open-source web server that's written in Go. The best part? It comes with automatic HTTPS. It basically condenses all the work our scripts and manual maintenance were doing into just 4-5 lines of config. So, stick around and I'll walk you through how to set up an automatic SSL solution with Caddy, Docker and a Node.js server.

Let's use Caddy which can act as reverse-proxy with automatic HTTPS coverage.

Even if it may be simple, it doesn't handle edge cases such as https://github.com/caddyserver/caddy/issues/1632

I personally would make the trade off of taking on more complexity so that I can have extra compatibility.

One of the most heavily used Russian software projects on the internet https://www.nginx.com/blog/do-svidaniya-igor-thank-you-for-n... but it's only marginally more modern than Apache httpd.

In light of recently announced nginx memory-safety vulnerabilities I'd suggest migrating to Caddy https://caddyserver.com/