I personally think that the best alternative is statamic. I've built two large sites with it without touching a line of PHP. No themes or crazy plugin dependencies in the manner of Wordpress, so its a roll everything yourself type deal, but the data model building GUI is excellent. Not super interested in selling/explaining it, but certainly I would look into it as a viable alternative - it works how I think CMS's should work, incredibly refreshing after building websites for 20 odd years.
There’s a million standalone CMS’s (headless) and standalone site builders (ranging from pure technical to no-code to no-design) and even sitebuilders with robust CMS’s attached these days (eg. Webflow).
I’m not entirely sure why you’re comparing Kirby to Webflow. They’re completely different tools built with completely different target audiences in mind.
Also
“many clients sites are now dead because their web host didn’t want to support old PHP versions anymore”
Isn’t the solution to that as simple as upgrading your CMS?
The comment I was responding to was criticizing the idea of having to provide hosting support for other CMS's.
That fact that you constantly have to upgrade Kirby and pay new licensing fees (and bill your customers for this) because no web host wants to support an old version of PHP...betrays the idea that Kirby is a way out of this. Sure it doesn't have a database to hassle with like Wordpress so it's better in that regard. But it's still objectively worse than any cloud platform.
If you're on a cloud subscription platform you're completely hands off (no upgrades necessary) and the client now has permanent support from said subscription they're paying for. It's fundamentally a better model than dumping websites on clients and letting them slowly rot away while they forget how to do anything with them.
> If you're on a cloud subscription platform you're completely hands off (no upgrades necessary)
Sure you’re just letting someone else do the job but at a significant higher price. It’s a trade off like everything else. In some situations a cloud solution is probably good. But in other cases it might be way too expensive in the long run. So it’s a balance and every situation is different.
don't write off those that setup a WAMP and then make it public facing. the time to get a LAMP setup running is pretty close to <1min after a simple double-click on an installer. getting a sane/secure LAMP setup running is an entirely different story that you did not specify as being a qualification.
What I was implying was the cost of services, who are you going to host with?
Cost of maintaining, whos going to keep up with latest CVEs?
Cost of domain, registrars, SSL certificates.
Cost of all adds up. A non-tech IT business has minimal resources for all of that. They want "pay $, click, it works". Not a dedicated IT worker to serve all of above.
If you take say a tutor, a bassist, they don't want all that overhead. They want a platform where they can advertise their tutoring costs, a contact form and be done with it. WP isn't ideal but it works.
For someone who can host WAMP/LAMP, fine. But for the average folk, it's not. There was a reason why WP gained popularity to begin with and it was because it was easy to adapt and junior PHP developers were plentiful, just as junior python developers are now.
> If you take say a tutor, a bassist, they don't want all that overhead. They want a platform where they can advertise their tutoring costs, a contact form and be done with it. WP isn't ideal but it works.
Yeah and especially if they want to update it themselves. Wordpress makes that easy even for the non techies so the customer can do it themselves.
Of course the big Achilles heel of WordPress is the plugins and their vulnerabilities. So really you still need someone technical to keep it up to date, which is often forgotten.
Depends on what exactly you're getting out of Wordpress and what you dislike about wordpress. But Ghost, Strapi, Payload, and Craft are all really good CMS.
When it comes to e-commerce, Shopify. Or if open source and control is important to you, Saleor.
the funny thing is, to the vast majority of people that use WP, they won't even care if even know about all of the drama. even people that took some sort of WP bootcamp and earn a living managing other people's WP site probably are blissfully ignorant of this drama.
the people that might have some actual interest are the devs that create the various plugins/templates. but as someone else mentioned, if everything goes nuclear and everyone loses their damn minds, a more sane party can just fork the thing and call it something totally different without using the terms like "word" or "press".
There really aren't one-to-one replacements for WordPress and the whole ecosystem that comes with it.
I've actually been pretty happy with Pocketbase, though it really straddles the line of rolling your own CMS. You aren't technically writing the db wrapper or visual editor itself, but any functionality you need beyond authentication is up to you to build.
I've enjoyed GravCMS [1], another php based CMS that used markdown for its content instead of a database.
For those interested in migrating away, I wrote an exporter from WordPress to Grav [2], which, given recent events, I've pulled back out and am updating again.
The main one I've read is Joe Buff's Deep Sound Channel series, found it after a recommendation from someone else on HN even so glad to continue the chain. Fell off it a bit in book 4 but that might have been me burning out on them, I ripped through the first 3 and focused too hard on them.
>and adding features to solve all of them will make the language much bigger, overall causing greater harm (even those who don't themselves use the feature need to learn it to be able to read code).
I agree that adding too many features can make a language too large and bloated. However, I disagree that this is always the case. For example, adding features that make it easier to code math is not necessarily a bad thing. In fact, it is a good thing, as it can make programming more accessible to a wider range of people.
Additionally, math is often used in fields that require high speed, such as computer graphics and game development, Computer vision, Robotics, Machine learning, Natural language processing (NLP), Mathematical modeling, all kinds of scientific computing (Computational physics, Computational chemistry, Computational biology...) As a result, low-level programming languages are often used to implement the core code in these fields.
As you see, Math is essential for many fields.
I think Odin is terrifically designed overall. There are design choices that I was initially very skeptical about but when I decided to use the language they actually made a lot of sense.
Some overall differences between Odin and Zig and how I relate to them are:
## Exhaustive field setting
Zig requires you to set every field in a struct. Everything everywhere has to be initialized to something, even if it's `undefined` (which means it's the same thing as missing initialization in C, etc.).
Odin instead takes the position that everything is zero-initialized by default. It then also takes the position that everything has a zero value and that zero value is a valid value to have. The libraries think so, the users of the language think so and what you get when everything works like this is code that overwhelmingly talks exactly only about the things that need talking about, i.e. we only set the fields right now that matter.
Exhaustive field setting does remove uncertainty and I was very skeptical about just leaving things to zero-initialization, but overall I would say I prefer it. It really does work out most of the time and I've had plenty of bugs in Zig caused by setting something to `undefined` and just moving on, so it's not really as if that exhaustiveness check for fields was some 100% solution.
## An implicit context vs. explicit parameters
Zig is more or less known for using parameters to pass around allocators, and so on. It's not a new concept in most lower-level languages but it's one of the first languages to be known for baking this into the core community and libraries.
Odin does the same thing except it uses an implicit parameter in all Odin functions that is called `context`. When you want to change the allocator for a scope, you only need to set `context.allocator` (or `context.temp_allocator`) and every function you call in that scope will use that allocator. We can also write functions that take an optional parameter that defaults to the current allocator:
This way we get the same behavior and flexibility of talking about allocators but we can also default to either the basic default or whatever the user currently has in scope. We *can* also be more explicit if we want. The ability to have this implicit again makes it so we only need to talk about the things that are special in the code.
The context is also used for logger information, by the way, and you also have a `user_data` field that can be used to hold other stuff but I haven't really needed it for anything so far.
## Error information
Zig is known for its error unions, i.e. a set of error codes that can be inferred and returned from a function based on the functions it calls. These are nice and undoubtedly error handling in Zig is very neat because of it. However, there is a major downside: You can't actually attach a payload to these errors, so these are just tags that you propagate upwards. Not a huge deal but it is annoying; you'll have to have a parameter that you fill in when an error has occurred and you need more info:
// `expect_error` here is only filled in with something if we have an error
pub fn expect(self: *Self, expected_token: TokenTag, expect_error: *ExpectError) !Token {
}
Odin instead has a system that works much the same, we can return early by using what is effectively the same as `try` in Zig: `or_return`. This will check the last value in the return type of the called function to see if it's an error value and return that error value if it is.
The error values that we talk about in Odin are just its normal values and can be tagged unions if we so choose. If we have the following Zig definitions for the `ExpectError` example:
They are normal tagged unions and in contrast to Haskell/Rust unions we don't have to bother with having different constructors for these just because a type is part of several different unions either, which is a big plus. We still get exhaustiveness checks, something akin to pattern matching with `switch tag in value { ... }`[0] and so on. Checking for a certain type in a union also is consistent across every union that contains that type, which is actually surprisingly impactful in terms of design, IMO.
## Vectors are special
This isn't going to have a Zig equivalent because, well, Zig just doesn't.
Odin has certain names for the first, second, third, etc., positions in arrays. This is because it's specifically tailored to programmers that might deal with vectors. It also has vector and matrix arithmetic built in (yes, there is a matrix type).
It seems like a small thing but I would say that this has actually made a fair amount of my code easier to understand and write because I get to at least signal what things are.
## Bad experiences
### Debug info
The debug information is not always complete. I found a hole in it last week. It's been patched now, which is nice, but it was basically a missing piece of debug info that would've made it so that you couldn't know whether you had a bug or the debug info was just not there. That makes it so you can't trust the debugger. I would say overall, though, that the debug info situation seems much improved in comparison to 2022 when apparently it was much less complete (DWARF info, that is, PDB info seems to have been much better overall, historically).
Thank you so much.
It look like Odin is really a beautiful language to program with.
Did you encounter memory bugs? Essentially what memory safety feature Odin offer? (From what I read here, Zig and Rust offer some features to eliminate entire classes of bugs which remove the nightmare of hours of debugging)
Anything you dislike or wish Odin has that other languages offer?
>that the debug info situation seems much improved in comparison to 2022 when apparently it was much less complete (DWARF info, that is, PDB info seems to have been much better overall, historically).
I believe Odin was developed on windows and other system come later, probably that why PDB is much better.
> Did you encounter memory bugs? Essentially what memory safety feature Odin offer? (From what I read here, Zig and Rust offer some features to eliminate entire classes of bugs which remove the nightmare of hours of debugging)
Odin is essentially in the same ballpark as Zig in terms of general safety features. Slices make dealing with blocks of things very easy in comparison to C, etc., and this helps a lot. Custom allocators make it easy to segment your memory usage up in scopes and that's basically how I deal with most things; you very rarely should be thinking about individual allocations in Odin, in my opinion.
> Anything you dislike or wish Odin has that other languages offer?
I would say that in general you have to be at least somewhat concerned with potential compiler bugs in certain languages and Odin would be one of them. That's not to say that I've stumbled on any interesting compiler bugs yet, but the fact that they very likely do exist because the compiler is a lot younger than `clang` or `gcc` makes it something that just exists in the background. Multiply that by some variable amount when something is more experimental or less tried and true. The obvious example there is the aforementioned debug info where on Linux this has been tried less so it is more likely to be worse, and so on.
In an ideal (fantasy) world I'd love something like type classes (from Haskell) in Odin; constraints on generic types that allow you to write code that can only do exactly the things expressed by those constraints. This gives you the capability to write code that is exactly as generic as it can logically be but no more and no less. Traits in Rust are the same thing. With that said, I don't believe that neither Haskell nor Rust implements them in a way that doesn't ruin compile time. Specialization of type classes is an optimization pass that basically has to exist and even just the fact that you have to search all your compiled code for an instance of a type class is probably prohibitively costly. It's very nice for expression but unless Odin could add them in a way that was better than Haskell/Rust I don't think it's worth having.
UFCS works really well in D but D also has ad-hoc function overloading whereas Odin has proc groups. I think UFCS only really works with exceptions as well, so I think it can become awkward really fast with the amount of places you want to return multiple values where your last one represents a possible error.
> Odin instead takes the position that everything is zero-initialized by default...
> Exhaustive field setting does remove uncertainty and I was very skeptical about just leaving things to zero-initialization, but overall I would say I prefer it. It really does work out most of the time...
Vlang does this as well (also influenced by Wirth/Pascal/Oberon/Go). Overall, this is an advantage and greater convenience for users.
You could extent your UI toolkit and profit from it. make it open source and make it free for open source projects and with fee for commercial projects.
It's very beautiful and sleek UI and the market of UI are lacking in this area. a lot of people demand this UI toolkit and asking you to release it is a prove that it will be a successful product.
Nim not only faster than Go but have a very similar syntax to python. It make more sense for Python developers to use Nim when need more speed instead of Go.
