Mozart.js
adamjgrant.github.io
adamjgrant.github.io
... which is a bad sentence to begin with.
To the creator of this project: it is fantastic that you are thinking about abstractions at this level. You are fucking awesome. Keep it the hell up.
Real criticism: this microframework is obtuse with too much “magic”. First, $ is a symbol that most developers associate with jQuery. If your API isn’t jQuery compatible, _$ won’t save you.
Second — honestly, this is way too complicated. The _$ might be a contributing factor. I can’t understand or develop a cohesive internal framework for this Library from this documentation page. This might be a fault of the documentation, the abstractions, or both.
Keep iterating: it seems like you’re compiling views from data- attributes programmatically. Good call. I just can’t piece together why this is something I’d use and how the abstractions save me time versus any other framework.
I never released OSS without tests again.
It’s hard to discern rigorous criticism from kneejerk reactionary responses. I’m hopeful that the narrative is helpful in showing I’m appreciative and impressed by the effort, but have real concerns about the project and implementation itself. It’s not bad. It’s difficult to understand. Which is a classification of software we’re all likely to create at some point, and we can all help each other be better at writing about what we create as well as building the right tools and abstractions.
I’m being pedantic about my own communication so you’re probably right that I’m pedantic in at least some sense ;).
The front-end landscape does not need another hegemonizing framework, particularly one with suspect motivations and even more suspect coding patterns.
> "Why Mozart will be your new indispensible tool"
No, thank you. This is pure hubris.
Rather, explain to me: "Why would you use Mozart?"
And then remove the entire first chapter if you will, and replace it with a subtitle such as: "Mozart is a toolset for developing simple single-file javascript frontend applications"
Or something similar. And THEN you can compare Mozart.js to Vue.js, angularJS, JQuery etc.
(Edit: fixed typos)
He can write whatever he wants. Would benefit him a lot though to not be put off by the first 5 words of anything, and instead have patience to form a well rounded opinion of whatever he's looking at.
The docs of this do not appeal to me. First of, I need some sort of Hello World, to understand the basic structure of an application written with Mozart.js. I have that both in Vue and in Angular. I am a simple being, I manage to do 'Hello World', and I promptly get excited.
Then I would want something that demonstrates handling User-Input (i.e. dynamic data and databinding between JS and HTML). How do I react to a button? Again, I am a simple being. I see things happen, and I promptly clap my hands with joy.
There is only one concrete full example I have found on the introduction page[0], and it doesn't seem to work for me (clicking the button does not produce a report). On top of that, the example is written in CoffeScript, and I have never in my life read code in CoffeeScript.
The rest of the code snippets that are presented in the docs are just fluff to me. I cannot read it, I do not understand the context, and I am not compelled to dive deeper into it. Disclaimer: I am dumb as a stack of hay, reading code is hard for me and I need stuff to be spelled out for me.
TL;DR I cannot comment on the tool, since the first look provided by the docs does not inspire me to try the tool.
[0]: https://codepen.io/ajkochanowicz/pen/zwYWGy?editors=1010
edit: fixed missing part of a sentence
I had a lot of trouble understanding your example code. In your framework, everything is built upon the m$, _$, and $ objects (or is the $ actual jQuery and not part of your library?). Maybe, instead of starting by showing us much code, you should explain what these symbols can do and what the most important methods on them are. Just by looking at your code, I could not create a mental model of what each of these symbols is capable of. Without this explanation, it seems a bit like magic.
What wasn't too clear to me, was the distinction between a component, and it's many instances... I suspect this is a deliberate and actually quite good design decision.... many instances of the same component are merely clones of the base component....
I think a massive need exists for more simplicity, patterns and much more lightweight mini frameworks. See for example the moon js framework as a much lighter weight alternative to vue and react
I would also suggest that you ignore the haters, and keep working at improving your documentation and how you communicate your ideas.
I quite liked the minimalism of your docs too, and I understand most of what you said, simply because I have also written my own mini frameworks a few times.
But people who have not written their own GUI or component frameworks may not be able to make out head or tail of what your docs are talking about or why you have made many of the unconventional design decisions.
Most of the major frameworks like vue and react contain massive design flaws and beat you over the head with loads of incidental complexity.
I suspect that this project would be well served by some concise before/after comparisons of the specific use case scenarios where you can make a great case for the use of your library vs the incumbents. If you have 60s to sell us, don't bury your lede.
On the front-end though, I don't see why I would need to know more than one. You can pick up Vue in a day to make a simple ToDo or other app with REST calls with or without central state. You can then add to that knowledge for other uses and share knowlege other devs and google for what you don't know.
With bare-bones type frameworks, you're pretty much on your own just rebuilding patterns in JS. This is the most common reason for why Lisp isn't more popular. It's because they use Lisp and build a custom DSL/framework for the app then build the app with it. This means that two app developers who might have built almost the same product at different companies can't share what they've learned.
The only time this might make sense is if it's almost all static HTML and you want some jQuery to update a small part of it. Even then it's hard to know that it won't grow into an SPA eventually.
Try to enjoy yourself
> I wanted to spend my time I had remaining on this project focusing on telling the story of this exploration but do not plan to regularly maintain this project.
The creator seems to have intended it as a research initiative. Given this context, I find some of the ideas in here to be really neat, like attempting to unify the API and the front-end UI while still maintaining a separation of concerns. It definitely needs some polishing to really be "fun" to code with, but it's a great start IMO.
(my personal opinion/experience is that front end devs are moving away from it entirely, and it's only going to be used for eye-candy and minor public-facing user interaction in the future if at all.)
Vue... I looked briefly at the example with the table... and it seems it would be much easier with Vue, but maybe I am missing something?
I do like the "idea" of my code getting close to the intended web components we've been promised [0] ... So I suspect you are on to something here concept wise.