I have made it my goal this year to be as positive and encouraging as possible.
... 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.
:). The very first thing I ever put on HN in Ruby got blasted — hard — for not having tests.
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.
It feels like you are merely paying lip service to "being more positive" and generally biting at the bit to dig into the criticism. I somehow find this more way more irritating than the usual HN overly critical pedantry.
That’s fair — and I appreciate the criticism. Thank you. I don’t think it’s an entirely fair characterization and believe I was being earnest, but I understand why you feel that way.
Commenting (can no longer edit) to acknowledge I sort of contradicted myself. I meant it’s fair for you to feel that way, but I’m not sure the characterization is fair. Hope that makes sense.
I’m being pedantic about my own communication so you’re probably right that I’m pedantic in at least some sense ;).
> "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.
I'm not in a position to judge what is right or wrong, but I feel like he could have done better than form an opinion on the tool based on the first sentence of the website, and then provided no comments on the actual tool itself.
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.
I can not chime in with an opinion on the functionality of Mozart.js. I can only compare the first-looks of the docs to my experience with VueJS and Angular when I was a complete beginner to frontend development.
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.
After reading the documentation for 15 minutes, I still don’t fully understand what your framework can actually do and why one should use it.
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.
This is so bad. A step backwards into imperative hell. Imperative, magic, programming with strings hell. And it looks like this person hasn't used, or at least learned from, any of the dozens of much more mature and robust versions of this.
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.
Don't be put off by the negativity expressed in many of these comments. While I have my own concerns (why wouldn't I use Stimulus? and you might want to tone down the promises) it's just so easy to shit on other folks' contributions without anything positive to say.
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.
I can see the value in micro frameworks for the back-end as there can be tight constraints e.g. latency/throughput or startup time (serverless).
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.
Agreed for Vuejs. I'm trying more and more to push back on developping de-facto SPAs because they _seem_ just easier to build now with React or whatever cool framework, but actually bring so much complexities.
Unless there is a real reason for a complex SPA, I try to stick to normal MVC patterns, where each page is independently rendered from the server. In which case, Vue is to me the best framework to be able to t generate those type of "micro apps" for each page.
Was expecting it to be an interesting library related to music or audio, but it's just another JavaScript framework attempting to solve already solved problems. Also wouldn't use it because it extends String and Object.prototype which is bad practice.
For those who think this is actually intended for production use, don't fret...
> 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.
I appreciate any effort to make modern frameworks that can run in vanilla JS without compilation. I feel like the current JS compilation toolchain is still well in "uncanny valley" territory, where it can still be tricky to set up and the final product often still doesn't work quite right with browsers' dev tools. (I still find myself in situations where source maps aren't working for no apparent reason.)
I second the thought that you're trying to optimize here and bring in your own personal brand of efficiency, but that's the trouble, it seems too 'personal' to use.
jQuery... I am still in the process of purging all jQuery from my projects. It may be a mistake to use it in your code examples.
(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.
... 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.