Community Concerns

All of this is being considered.

Using SemVer (Semantic Versioning) MODX has slightly changed its versioning number policy. Breaking-Feature-Patch. Version 2.4.3 is in progress with quite a number of improvements such as PHP 7 compatibility, as is 2.5.0 with some nice new features like an unzip option in the file manager. You can find them in their branches on github.

MODX 3 is also in development, and beyond that, what is called for lack of a better designation "MODX Next".

MODX Next will provide much the same functionality that MODX has ever had and more, but with (again) an entirely different codebase based on Slim, Twig and a much more modular API using the micro services architecture pattern. The Javascript library that will be used for the Manager has not been settled on yet, but it's possible that it will be HTML-first with progressive enhancement.

OK - I totally understand it if it's a resource problem (manpower and or money). And it’s really amazing what people did and do for free in the open source community – of course. Actually this discussion is part of all that (I hope).

Never the less I would rethink the decisions, when talking about the frontend of the backend (the manager), because the more complex a system gets in the UI, the more you will want to have the ability to have an actual programing language with good libraries, frameworks etc. And I strongly believe that for browser based web UIs this will be at least for this decade JavaScript. (Flash is dead – always was a zombie in my eyes anyways, Silverlight and other proprietary stuff is really not made for such things …) I also know that js behaves a bit like cancer – once you have it it’ll spread in your system. But on the other hand pure HTML and CSS is by far not enough especially for a CMS. The problem then is that adding only a little bit js here and there will always produce solutions that are not really smart, handy and performant. But I see the problems with resources …

Oh, just saw the post from sottwell -- These are very good news I think - so I'll shut up my anoying mouth now.
[ed. note: vik0xs last edited this post 8 years, 4 months ago.]

Its some good points and a good discussion of how to navigate this sea of changing technologies. I don't think anyone has the perfect answer. More passionate exchanges are probably helpful!

I would say this criticism is valid in the sense that (1) the manager is the first thing users see of modx and therefore can make a strong first impression, and (2) it is clunky for novice users and hard to simplify the manager when we want non-tech users to be able to use the manager interface (getting better, though, as I understand).

However I think the comparisons to sites like Facebook are not very fair (github perhaps being the exception). Those sites cater to general users and must keep things simple, also users are doing only a limited and defined number of actions. Building a Facebook page with many bells and whistles, as challenging and time-consuming as it may be, is nothing like using Modx to build and maintain a website.

Its like Modx is a great basic recipe for making cake, and that recipe can be customized to *any* requirements, and you are arguing that its easier to use a store-bought cake mix. Yes, its easier to set up a photostream or a poll for your friends to vote on something in Facebook. But just try arranging your friends list in Facebook according to the number of likes you have given their photos, a "Favorite Friends List" and then you will see the limitations, unless the Facebook devs have provided that particular functionality to the user base. Which is something you could do in Modx in an afternoon perhaps if you had a friends function between users and an upload pics function.

My internet is pretty awful to start with, so I know from slow. So I don't want to save unnecessary things. But what I really care about is that it saves and allows me to develop. Heck I usually click on that save button twice to be sure.

MODx seem rather too quite these days. What's the direction? Last release was in October. How about a manager that functions like this https://www.youtube.com/watch?v=QixcGyrZA94

Join the Slack community. http://modx.org/ Lots of discussions of what's to come, and also a channel that is attached to the github repository showing the issues and pull requests as they occur.

webflow CMS is good for some people I amd sure.
Asking me to run a race without running ain't going to happen soon ... getting my sites up without coding ...hmm!

Quote from: vik0xs at Dec 16, 2015, 08:14 PM

But on the other hand pure HTML and CSS is by far not enough especially for a CMS. The problem then is that adding only a little bit js here and there will always produce solutions that are not really smart, handy and performant. But I see the problems with resources …

On principle I disagree with the assumption that HTML and CSS is "not enough". In fact, I think HTML alone is enough.

I don't think this should not be an HTML vs JS discussion because the two don't oppose each other – they compliment each other. HTML is slow without JavaScript and JavaScript doesn't have a DOM to enhance without HTML.

Starting with HTML first is the most performant and reliable way to build any web experience. CSS is optional decoration. JavaScript is optional progressive enhancements that bring forth an asynchronous experience.

As a Thinkful Mentor I like to use real world examples to explain the front end stack (HTML, CSS, JS) to new students. We've noticed this analogy "clicking" with students very well. Think of your web page like a house. Why do we build houses? To make them pretty? No. To do things quicker? No.

The primary reason we build houses is shelter. HTML is the frame of your house. It provides the shelter. It is the reason people occupy the house. Like with building a house, this step should come first. People don't search for "show me a pretty blue website" they search for content. HTML is content. HTML is shelter.

Anything else (CSS and JavaScript) are completely optional. You don't need to paint the walls of your house certain colors to have shelter. You can survive with boring white walls. You'd rather make it nice, so you decorate the house with a little CSS.

JavaScript provides asynchronous enhancements that you could live without. JavaScript is your garage door opener. JavaScript is your dish washer. You don't need a dish washer to have a roof over your head but you sure can get things done quicker with one. JavaScript is progressive enhancement.

All CSS does is decorate HTML. All JS does is update the HTML. It's *all about* the HTML.

Quote from: dinocorn at Apr 17, 2016, 06:03 AM

On principle I disagree with the assumption that HTML and CSS is "not enough". In fact, I think HTML alone is enough.
...
All CSS does is decorate HTML. All JS does is update the HTML. It's *all about* the HTML.

While I disagreed with vik0xs' first assumption, I have to say, I don't completely buy this statement either. At its basic level, your view is true, yes. HTML in of itself is a frame and the foundation, but that isn't enough for the modern world. A cave offered shelter, but that doesn't mean our prehistoric ancestors were content to live in one.

HTML by itself in the context of a modern CMS does absolutely nothing if you don't also have a back-end processing language to save the input, then parse it back into a readable format. Therefore, HTML-only is absolutely useless for a Content Management System.

To take it further, HTML plus (server language) alone isn't going to win over the masses that it will take to keep the CMS viable. You don't necessarily have to have a beautiful interface, but you do have to have an efficient, readable and easy to use interface. HTML without CSS cannot accomplish that - at least without using tables for layout, which if you are a purest, is a cardinal sin (not to mention the havoc that causes on mobile devices).

Lastly, without Javascript, many modern UI techniques just aren't possible, and it degrades the experience and the levels of possibilities you can achieve with it.

So the question of how to use Javascript in an application isn't, “Should we or shouldn’t we use Javascript?” — we absolutely should use Javascript. The question then becomes, “Do we rely on Javascript so heavily that the application breaks without it and we are stuck with this framework for the foreseeable future? Or do we use Javascript as it was meant, which is to say to compliment the application in areas that could benefit from its use?”

My view is, Javascript should never do the job of HTML or CSS. That is the biggest problem with the current iteration of the MODx manager. Javascript should process variables, gently manipulate the DOM, attempt to smooth over differences in browsers and platforms (CSS can accomplish this even better), and offer feedback to the user. It should not create HTML, and it should not create CSS. Your fingers and brain create CSS, the server language creates the HTML and the end user creates the content. Only then do you have a fully functioning home, not just a drafty shack.

Quote from: dan971 at Apr 17, 2016, 06:28 PM

Quote from: dinocorn at Apr 17, 2016, 06:03 AM

My view is, Javascript should never do the job of HTML or CSS. That is the biggest problem with the current iteration of the MODx manager.

Completely agreed. Start with HTML (dynamically generated by a backend). Decorate it with CSS to make it cozy. Progressively enhance it with JavaScript to make it convenient. Ideally one would be able to use the MODX Manager as raw HTML. This would be as boring as an empty house with white walls, but it keeps us out of the rain. Once the house is built you can decorate it and add async enhancements like dishwashers and garage door openers (JavaScript).

Wordpress recently made a significant announcement with their commitment to supporting WCAG Level AA in their core and anything that ships with the core. I think we could learn a few things from their success in this area:
https://medium.com/@jpdevries/let-us-learn-from-wordpress-28b0803530d8#.r29s75rqz