1. 16
  1.  

  2. 22

    What bugs me is that the kinds of developers who see libraries like Mithril as objectively better are usually quick to make judgements and are easily mislead. The fact that the author tries to point to performance as a key advantage of Mithril on multiple occasions (while making sweeping estimations of ‘load’ and ‘render’ speeds) tells me they are over-concerned with performance and finds that an important metric in the quality of a library or framework.

    Both can be compiled, but React’s compiled templates still have function calls for each virtual DOM element, making them slower, while Mithril compiled templates turn into static Javascript data structures.

    This demonstrates the author has no idea what actually matters for performance, but that they completely gloss over any other details, remarks or advantages of React. I’d walk away from this article assuming the author has never developed an application in any of the mentioned frameworks outside of AngularJS. I could easily point out how Mithril doesn’t discourage developers from “inlining event handlers because it forces the mounter to re-assign event listeners on every render,” and how that “makes React objectively faster and better than Mithril,” but I won’t because that’s a pointless remark and anyone with qualified knowledge would agree.

    Annotations are nice when they work which is 80% of the time, but when they don’t work or you need to understand how they work, can you set a breakpoint in them? At that point they become mysterious magic. In a lot of Java frameworks like Spring almost everything is an annotation rather than a function call, and because of this you can’t debug them or understand the program flow control. You don’t immediately know when they are processed or in what order…or even if they are processed at all. […] Do we really want the same situation for JavaScript?

    Annotations in JavaScript are incredibly simple and yes, you can, set breakpoints in them. Unless the author here actually refers to the ES7-proposed decorators, which go indifferent to annotations in the context of Angular, there is no excuse for his critique of them as ‘too complex’ and ‘mysterious magic.’ Annotations are simply the initialization of classes; they annotate your corresponding data structures; when an annotation class or a decorator starts to mutate or mask computations, or when you find a need to debug the parts of your libraries that leverage them: it’s not the fault of annotations, it’s the fault of you or your library.

    You can make the same arguments for a lot of language features such as prototypal inheritance, object literals, operator overloading, interfaces. The quick dismissal of annotations tells me the author really just doesn’t understand them well enough to be comfortable using them in JavaScript.

    Mithril.js is the fastest, smallest, and easiest to learn JavaScript MVC library. [emphasis mine]

    Not only did the author never point to any other frameworks or libraries than React and Angular, but they also chose to make bold and sweeping statements about something (I’d assume) they’ve never professionally used, without having any text or pretense to back it up.

    I feel like libraries such as Mithril, Riot, Mercury and Ampersand have everything to do with how they are marketed, and the features that “these kinds of developers” really take interest to. When they see a library that markets itself as ‘simple,’ ‘lean,’ ‘fast,’ ‘scalable’ and ‘modular’ it makes me cringe. I’m sure there are plenty of teams who can adapt to those types of libraries or frameworks, but in most cases they have traction because of their appeal, but not because there was any innovative design behind it all.

    1. 7

      Yes. The comparison to react was particularly underwhelming and light on detail.

      Usually in a post like this, I like to see a bit more first person. Tell me how you fared with each framework. This reads like a post that could be written by anyone who has read the documentation for each framework.

      1. 3

        As a side note, what’s going on with lobste.rs community cognitive dissonance here? 17 people upvoted this comment which states that the author doesn’t have enough experience and doesn’t make a balanced argument. Yet there are 13 upvotes for the article and no downvotes.

        How can that be? Do we already have a Facebook ‘Like’ brigade who are upvoting stuff completely absent mindedly, without comprehending the content of an article or of a comment?

        17 is a bit too close to 13… are people upvoting both the article and this comment? If so, why!?

        (Edit: My preference would be that people stand up for their opinions to improve the quality of content on the front page - if 17 people think this is a poor quality article, I expect it to be downvoted off the front page)

        1. 9

          I upvoted both, and you. Just because I don’t agree with the article doesn’t mean I don’t think it’s not worth reading, especially with the above reply too.

          1. 6

            Same as Steve, I think it’s against the spirit of Lobsters to flag a post if you think the argument it makes is flawed or simply incorrect. I tend to always read the comments if there are any. Flagging is intended to only be used when a post shouldn’t belong on the site, is improperly categorized or has a misleading title.

            1. 1

              There is no “low quality” downvote on here.

              I wish it was more expensive to like something but I am not sure how to do it.

              1. 1

                There was, but then everything was tagged low quality.

                1. 2

                  I’m not surprised. I wish there was a way to make up or downvotes expensive. For example any downvote requiring the author to post a comment with why.

          2. 16

            <rant>To be frank, as a backend engineer, the rotating door of JavaScript libraries is why it’s hard to take the community seriously. This is a complaint I see levied against backend engineers often and you frontenders do it to yourself. The choice of frameworks for backend things is large, sure, but mostly static. Python only has three or four serious choices and they have been around for awhile. Ruby has only a few as well. Etc. I have tried to learn frontend dev a few times and it’s just infuriating. By the time I’ve learned how to do what I want the in framework X.js the community has moved onto Y.js. It’s not even clear what the community is trying to optimize for! Is it speed? Download time? Simple APIs? I don’t know because the framework of the week is always so different from the previous. Next time you, a frontender, feel like backenders aren’t treating you like grown up professional devleopers, well damn straight, start acting like one, then.</rant>

            1. 7

              My reaction to this article was, “Good fucking lord, another one?”

              At this point, it’s nearly impossible to take frontend development seriously.

              1. 1

                Well, Web frontend anyway. Native mobile dev lacks this problem.

              2. 5

                To be frank, as a backend engineer, the rotating door of JavaScript libraries is why it’s hard to take the community seriously. This is a complaint I see levied against backend engineers often and you frontenders do it to yourself.

                Translation: I don’t understand why the “frontend community” (whatever that is) seems to do things differently than I would. Therefore, they aren’t worth taking seriously.

                The choice of frameworks for backend things is large, sure, but mostly static. Python only has three or four serious choices and they have been around for awhile. Ruby has only a few as well. Etc.

                There are only a few “serious choices” for frameworks in the frontend world as well. Angular, Ember, and React are the big three, and have been for a while. Most others are “flavor of the month” and never achieve critical mass. They just make a lot of noise.

                I have tried to learn frontend dev a few times and it’s just infuriating. By the time I’ve learned how to do what I want the in framework X.js the community has moved onto Y.js.

                What do you mean by “moved onto?” Blog posts are a poor metric for assessing where the “community” is actually at.

                It’s not even clear what the community is trying to optimize for! Is it speed? Download time? Simple APIs? I don’t know because the framework of the week is always so different from the previous.

                Is it really surprising that largest programming language “community” in the world is composed of lots of different people with lots of different priorities, levels of experience, knowledge of different paradigms? And that the frameworks reflect those differences?

                The kind of JS framework that will make a Java developer happy is different from the kind that will make a Lisp developer happy, which is different again from what a Ruby developer wants. In JS, we have all of these communities bumping up against each other and doing things their own way, then cross-pollinating ideas.

                It’s inevitable that there will be a lot of churn among smaller frameworks. And it’s inevitable that authors (and those ideologically similar to the authors) will want to promote their framework of choice. Thus the persistent “X is outdated, use Z” blog posts. This is further exacerbated by the fact that many frontenders come from a design and marketing background and are quite aware of the power of marketing and simply shouting louder.

                Next time you, a frontender, feel like backenders aren’t treating you like grown up professional devleopers, well damn straight, start acting like one, then.

                I can quite easily believe that there are more unprofessional JS developers than there are in other languages. (It has a pretty low barrier to entry, after all.) However, that doesn’t mean you get to just label JavaScript developers your inferiors and bask in your awesomeness.

                1. 3

                  Translation: I don’t understand why the “frontend community” (whatever that is) seems to do things differently than I would. Therefore, they aren’t worth taking seriously.

                  Actually, no. This is not my complaint at all. The rest of your response is all reasonable but this opener is completely missing the rant. It’s not that things are done differently than how I would do it, it’s that to an outsider the JS world is still solving problems via a Random Walk. I don’t like how the Java world solves a good bunch of problems, but there is method to the madness that I can at least understand.

                  1. 2

                    Perhaps I phrased my response poorly, but your clarification here is actually what I understood you to mean. On rereading, I also see that my response comes off as hostile. Sorry about that.

                    I intended my opener to emphasize the idea that there is not a single JS community in the same way that there is a Ruby community, a Clojure community, etc. And the seeming randomness that results from this misidentification of the “JS community” as a coherent entity is more apparent than real.

                2. 2

                  I don’t think that’s fair. If you counted all the changes in every backend language, you’d see just as much chaos. It’s just that web frontenders only have one language to work with so every new tech gets put in the same bucket.

                  Plus, it looks like chaos, but over the long term you can see slowly converging best practices in the frontend world. Most new frameworks seem to agree that virtual-dom diffing and unidirectional data flow were a good idea for example.

                  1. 2

                    I don’t think that’s fair. If you counted all the changes in every backend language, you’d see just as much chaos. It’s just that web frontenders only have one language to work with so every new tech gets put in the same bucket.

                    This comparison isn’t valid. Being in different language means you have no choice but to rewrite things. Many of the frameworks across different languages are copying each other and reusing ideas.

                    Your point is roughly that: the number of solutions to a problem that will be created is constant and it’s just a question of how concentrated it is (one language vs many languages). That might be observably true but doens’t seem like a good reason to do something.

                    Plus, it looks like chaos, but over the long term you can see slowly converging best practices in the frontend world.

                    How many iterations does it take to get MVC right? Maybe the actual stats disagree with me but I would expect the rate at which these new frameworks come out to be decreasing but that doesn’t seem to be the case.

                    1. 2

                      How many iterations does it take to get MVC right?

                      Hard to tell, since there is not one universal “MVC” nor is there one universal “right way” to do it. Though we do seem to be moving away from “traditional” Rails-style MVC toward something more component-oriented.

                      I would expect the rate at which these new frameworks come out to be decreasing but that doesn’t seem to be the case.

                      My personal theory is that is because knowledge of front-end MV* is now dispersing more widely, leading more JS developers to try writing their own, just like jQuery clones were popular a couple of years ago.

                  2. 2

                    You have three or four serious python choices NOW, but that wasn’t always the case.

                    Also remember that JS has so many more people using it because they’re basically forced to. The JS community is the largest by default, so it has the most variation in libraries of people wanting to code like they did in whatever their favorite/previous language was.

                  3. 6

                    I came to Mithril not from some article, but because I saw the author link to it once on a hackernews comment thread. I looked over the source and thought “this will help me not spend hours showing someone the ins and outs of angular.” I’ve spent so much time over the years explaining how to use API docs to developers that I just don’t want to spend more time than necessary doing it again. The fact that the source of mithril is so small lets any developer read and understand it within hours. There’s no need for the API docs, but they’re there if you need them. I look at them occasionally, but most of my understanding of the framework comes from reading the source.

                    I think it’s a bit of a falsehood to say that you’re only coding in plain JS with mithril, though. You still need to learn the conventions for it, especially around the templates, which isn’t necessarily going to pay off with some future framework that replaces it when you rewrite your app.

                    I was using angular for a while at my previous job and, while it was kind of cool, it also felt kind of like I was stuck in the world of angular. Then add on the fact that the 2.0 announcement came and people were feeling disillusioned with 1.x and the entire future of angular, it ended up leaving a bitter taste.

                    I would use angular again if I had coworkers who were really into it, but I wouldn’t pick it if I had the choice. It’s just too much. Too much source code, too much perceived instability (with releases, not the code itself), too much API searching, too many “I do it right and you don’t” posts. No thanks.

                    1. 2

                      While I don’t care for the article, Mithril itself looks fairly interesting: http://mithril.js.org/