No centralized framework. Everything is decomposed into "behaviors" that have no direct dependencies. Attributes are used for configuration and storing the running "state" of all libraries. Liberal use of CSS selectors as a kind of query language to remove the need for tree-traversal code.
The interesting thing about this approach is that it enables libraries/behaviors to interact and effectively "compose" at run-time without any direct code dependencies. It has some similarities to the idea of agent-oriented programming, which I think is a powerful idea worth a deeper look.
Of course, this is more of a proof-of-concept than a complete set of libraries needed for a complex website. However, I find this "behavioral" approach very enjoyable to use, because it makes development very immediate and incremental. Add an attribute, observe that it works, add another attribute, observe that it works, etc.
You also get progressive enhancement "by default".
Nowhere does it say this is a project intended to be used by non-technical people. Yet both times this got posted here everyone assumes it is. Am I missing something? In the Smashing Magazine blog post, it clearly states:
>Make a website that non-technical folks (clients? family members?) can edit right in the browser
I think the author is well aware that your average Joe is not gonna pump out web apps only "because it's just HTML". Saying that Mavo is simple to use can be misleading in this context. Simple compared to what? As developers, behaviour-enriched HTML seems simple to us because we have frontend stacks as an anchor for comparison. In almost all cases, average Joe won't even know about the structure of HTML documents, nor will he have a GitHub account to authorize against.
I think if you take Mavo for what it markets itself as, namely a "new, approachable way to create Web applications", it is great work.
HTML is a simple "programming language", but my experience is that when non-programmers see anything that even resembles "code" they throw their arms up and scream "UNACCEPTABLE!".
I love the concept though. It kind of reminds me of Excel. It's really hard to tell if "the users" will like it or not, you have to test it on them. But I think "the users" will want some sort of GUI/WYSIWYG.
Note that as is mentioned on the website, this has indeed been tested on users, and the results of the study have gone through rigorous peer review and published at a top tier academic conference on HCI.
And yes, the audience is programming novices who do know HTML and CSS. For now. Since Mavo is a language, one can easily imagine an integration with a visual editor, to make it accessible to the average Joe.
i'm creating a mavo project right now and
i wanna use a simple textarea as a mavo field.
(tinymce makes me feel a little icky inside.)
but i didn't see anything in the documentation
about how i would do that. can i? if so, how?
edit: oh hey. i just acted like it would work,
tried it out, and bingo! hey, that makes me happy...
(functionality is now a better differentiator of
the worth of a markdown converter than speed.)
mavo's choice of converter is more consequential
than it might appear at the first glance because
follow-on effects of differential functionalities
will surely impact the success of a mavo project,
as will the inconsistencies that will bite users.
all this aside, mavo is a fascinating little tool. :+)
I don't think the audience here is "non-programmers", it's traditional front-end web developers who are comfortable with HTML and CSS but have no formal scripting knowledge.
This is really impressive. It combines a lot of good ideas for making collaboration easier for non-technical users (Github auth, live editing). I see some negative comments about HTML but I see this being a great solution for marketing sites with basic interactions.
I wouldn't call this for "non-programmers", but I have lots of customers who can handle HTML and some basic server code, but who find Angular a bit of a leap. They want a way to crank out modern web-based forms-on-data apps with little ceremony. Will definitely keep an eye on this.
I don't get the JSX vs. HTML argument. The whole point is that non-technical people can use this to create websites that work well enough, and it'd be simple (comparatively) to build a WYSIWIG on this.
You would have to nest functions to get proper order of operations. Using function names instead of actual symbols. Seems like it would be easier to do something like math(a+b/2) and have it know that whatever was inside that function is math to be parsed.
I honestly couldn't gather from the documentation that it did support operands. My apologies if I was wrong, I will be re-reading it and slower this time.
I think the gist is the person creating the app would not write any javascript at all. Just the markup and reference the mavo js/css. In Angular and any other framework, you would typically write a JS component and HTML or other format template that eventually renders to HTML. There could be pros and cons to each approach, but I can see a niche for something like this where there isn't a need/desire to do anything besides _just HTML_
After working with JSX, HTML/templating just feels like a step backwards.
Web pages these days are far less about the template and far more about the logic and interactions involved.
Subsequently building up from HTML the way pages used to be built and then embedding code doesn't really line up with the way modern web apps are developed.
While it may have a niche in front-end design, for the kind of work I do at least it comes off as though the platform "allows" devs to build web apps entirely written in CSS.
> Subsequently building up from HTML the way pages used to be built and then embedding code doesn't really line up with the way modern web apps are developed.
Unfortunately the data doesn't agree with you. JSX, react and all that jazz is not used by 99.99% of the web. And NEVER will be! In fact react/vuejs/front-end frameworks are fancy only these days, the majority of web developers don't even use preprocessors for CSS or a templating engine like HAML/Markdown to begin with [1].
There's a reason why writing HTML has been kept simple. And forgiving.
I suppose that could have been worded differently, I meant it in the context of the original person mentioning HTML is their least favorite part of web design.
For your 0.01% of us who use all that jazz HTML-first design feels like a step backwards and especially trying to inject application logic comes off as a ham-handed method of design when compared with a logic-first design that spits out and manages the UI (HTML/CSS).
I'm not sure what CSS preprocessors has to do with that, but I'm also confused - what is your opinion of Mavo?
> I'm not sure what CSS preprocessors has to do with that…
That even simpler step-ups like preprocessors with lower learning curves have not been adopted by the majority. Simplicity and lazy has a very high bar for any sort of competing tech.
I agree with you that technical simplicity of HTML-first would feel a step backward because you have already climbed over the fence and accepted the issues of over-engineering that come with React/JSX/Webpack and 1000 other components.
This of course doesn't mean HTML-first approach would be replaced anytime soon. Even with likes of Facebook betting their entire ass behind it.
On Mavo: Not tried it yet, but I do see a promise in it. Also, coming from Lea Verou makes it all the more compelling.
It's true, there is a steep learning curve. I'm not sure that's a good comparison though, for example I don't use CSSPS but it has nothing to do with the learning curve.
So for comparison, how do the majority of people design sites? Say you're making a HN or Twitter clone, what is the process from cradle to production to get the site up and running?
To make markup expressive enough for general purpose logic, you have to extend it to such a degree that it becomes much more complex than the tools it replaces. This is especially so when dealing with an XML-like syntax, with its verbose, interleavable end-tags, rather than the much more succinct S-Expression style of Lisp. Mixing data and logic basically requires homoiconicity or else tooling requirements explode.
That's why I design all my web pages with S-Expressions and my Lisp server converts them to HTML on the fly. It works great unless I ever need to hire a designer who wants to work with raw HTML and CSS, and then I'll be slightly hosed.
It's possible to make arbitrarily sophisticated websites without serving any HTML except a script tag. The browser shows you HTML to represent the DOM, but it doesn't mean sites are serving any significant amount of it. (most still are though - I was just pointing out that it's possible to avoid it almost completely)
It's worth noting this is tailored towards web applications where as HTML can be used by any website - marketing, brand experience or otherwise including web app.
Jokes on them -- I have JS turned off on my phone except a few websites. I'm not paying outrageous mobile bandwidth fees for bloated websites and ads that cost me more in bandwidth than they make.
So for 90% of my browsing, I'll click on their page, see nothing, and move on with my day.
Many websites use JS that is slow and jumpy -- bloated -- on a phone, especially a cheaper one like I use.
Also, I like to use Chrome on my phone, so installing an adblocker is a lot of work for little benefit. It would slow down the already laggy rendering and require I either use a different browser or let an app intercept network traffic.
I'm perfectly happy not using JS (or for that matter, media) on my phone.
Sure, you can do that. Serve a JS file that happens to create the HTML on the fly that someone had to code beforehand. Serving just a JS file that outputs HTML is still using markup.
Official website : http://mavo.io/