Trying to bring volunteers in to build the platform.
I’m leaning towards PHP just because it fits the extensible HTML/CSS widget model the best. Other frameworks are more opinionated and favor encapsulation. If we were building widgets for everyone, that would work, but I want other template and widget developers to offer their extensions to the platform. PHP seems to work well that way.
To be honest, if you’re trying to attract developers to an open-source project – PHP may not be the way to go; it’s pretty much universally hated as a platform nowadays by anybody who hasn’t worked in a PHP shop for the last twenty years.
If you want something that’s very unopinionated, well, there are lightweight frameworks like Flask and Sinatra. And then there’s just plain Node. This is an interesting project, but I’m not sure I have the technical chops and/or time to contribute meaningfully, unfortunately.
PHP is hated because it’s easily abused. If its idiosyncrasies are managed by good developers, it does offer patterns synchronous with CMS building.
Python and Ruby frameworks are really foreign to me, but I will look at Flask and Sinatra. This is all still in the very early stages and choosing the platform is wide-open.
I like Node, so looking at Express may be relevant.
Well, I’m not necessarily going to say that hate for PHP is 100% justified – I honestly don’t know. But I do think the environment in the open-source community is one where PHP projects will have a harder time attracting developers than Pyhton or Ruby or JS projects.
Building a CMS – or more generally an application that delivers web pages based on the content in a database – is kind of the core task of web frameworks, so you really have your pick there.
Here’s my suggestion: building without a clear audience and hoping people will come is always a risk. I’d recommend finding an established author who is frustrated with what the web ecosystem is capable of now (and there are many!), and make a single product with them, but designing it as you said in a generic fashion.
I agree on both points. For now, I’m the established author (well, established author-like person). It’d be nice to find a collaborator, but it’s my baby for now.
And TypeScript/Node is my preferred technical path while using Bootstrap for style.
I would actually favour pure JavaScript over TypeScript right now; the reason being that Node now supports the important features of ES6 by default, which frankly makes current JavaScript a more useful language than TypeScript unless you are building a very complicated system with a huge number of programmers that really needs the added “safety”. (For code that is meant to run on the browser, you can use Babel, of course).
I’ve been writing JS for a few years now and TS for about 6 months. There’s no comparison in the level of productivity. Using TS eradicates a host of common errors when writing code.
And I want this code base to be readable and structured, which is just as important as working code.
I find that that’s only true for people who come from Java or C++, whereas for people who come from Ruby/Perl/Python/JS like I do, our eyes just glaze over whenever we see the keyword “static”.
I would do the core in TypeScript, but allow 3rd party libraries in JS where there is no TS equivalent. Although if you’re looking, you’ll notice a lot of GitHub libraries have TS versions of their code.
No matter what, this still leaves open how to build the CMS. I’ve been looking through existing systems and they’re either server based (old school) or if they are client-side, they’re more specialized. Still looking around for code that inspires something.
Some design questions include, are widgets in TS or are they TS and HTML? Do I use SASS for CSS management (I don’t know SASS at all)? If the HTML is in templates, do I use an existing template framework? Which one?
For CSS management, I suggest using Less. It’s more familiar (valid CSS is also valid Less), and it runs on Node (as opposed to the Ruby-based SASS). It doesn’t take very long to learn a CSS preprocessor, but it makes a huge difference in keeping CSS organised.