
Mozart.js - voldemort1968
http://adamjgrant.github.io/Mozart/
======
keithwhor
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.

~~~
twoslide
constructive resolution tip: next time omit the info on the resolution

~~~
keithwhor
:). 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.

------
cuddlecake
The first chapter of the doc already puts me off:

> "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.

~~~
philtar
Do you have anything to say about the tool itself?

~~~
hennsen
Why should it be wrong to tell how someone doesn’t like the textual
presentation of the tool?

(Edit: fixed typos)

~~~
philtar
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.

------
Sukram21
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.

------
stevebmark
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.

------
andriesm
I really liked a couple of the ideas here.

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

[https://kbrsh.github.io/moon/](https://kbrsh.github.io/moon/)

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.

------
peteforde
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.

------
karmakaze
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.

~~~
jypepin
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.

~~~
korm
Curious why, React can do that just fine. It doesn't force you to build a SPA.
What's different with Vue?

~~~
gammateam
They do the same things

Try to enjoy yourself

------
miguelmota
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.

------
gedy
Looks neat, but also seems a lot like KnockoutJS[1] or StimulusJS[2].

[1] [https://knockoutjs.com](https://knockoutjs.com)

[2] [https://stimulusjs.org](https://stimulusjs.org)

------
tomphoolery
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.

------
a_lieb
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.)

------
surajs
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.

------
Vanderson
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.

[0]
[https://caniuse.com/#search=web%20component](https://caniuse.com/#search=web%20component)

------
calahad
Looks cool, definitely some good ideas in there.

------
synthecypher
I can smell what the rock is cooking... but I'm not buying.

