Proposal for Blaze 2

core
21

@mitar

But if the thing is stable and there is no need for you to fix/change things on a production system?

Iron router has 400K installs, arguably production ready and maintained, but reportedly, it does not even work on Meteor 1.2 and I don’t want to have to be at the mercy of the maintainer or have to learn coffeescript. Heck, Meteor itself is supposedly stable and here you are using a forked library to apply a fix to core meteor code :wink: Also, blaze-components@0.13.0 does not exactly scream stable either however stable the code acutally is. In fact, you have made bugfixes as recent as 3 months ago with further commits as recent as yesterday!

@brajt

what exactly makes it difficult to convert them to JS for your own use, if you prefer JS?

I’ve tried converting CS to JS before and never liked the result. The generated javascript may technically be correct but it is not even close to what a javascript programmer would have written. And blaze-components is not a couple of lines of code which makes the converted js even harder to follow. Besides, converting means losing touch with the base packege, rendering it impossible to commit back a PR, track upstream changes (there’s even been commits on blaze components as recent as yesterday) until your fix is implied there as well etc. It is basically a different package from that point onwards. So from a technical absolute meaning, yes you are correct, but from a reality check perspective, it does not even make sense to use a CS package by converting it to JS.

Blaze Components is just a few CS files

800 lines of code written in some language I don’t understand plus a fork from core meteor with some patches being discussed in an issue tracked in that you need to follow on yet another tracker is not just a few CS files to me.

4 Likes
22

Iron router has 400K installs, arguably production ready and maintained,
but reportedly, it does not even work on Meteor 1.2 and I don’t want to
have to be at the mercy of the maintainer or have to learn
coffeescript.

I think you are mixing here two things. First, maintenance problem of open source projects and use of them in the production. I think there the issue is the size of the community and number of users. For example, if more people would be using packages and maybe even be willing to donate to maintainers, then maintainers could maybe dedicate more time to packages. Hey, being able to full-time maintain few open source Meteor packages sounds like a pretty good job to me. But, it is currently not possible. And probably because of this cycle you are mentioning. Packages not being quickly maintained, then people not using them in production, so there is no production-sourced money being available to contribute.

The question here is, can we turn around this cycle? Based on your arguments, it seems not, and things will stay like this.

So think about what would you like as an end result and how to get there. Complaining that packages are not maintained quickly enough is a problem, I agree.

The other issue you are pointing out is that you do not want to learn CoffeeScript. I must say that I do not see this as a really big problem because it is a language you can learn completely in 6 hours. Now, if you think it is not worth it, no problem. You can keep using other lesser libraries and packages. :slight_smile: But I think that in the business you are in, we are learning new technologies all the time. One more language, is this really so hard?

here you are using a forked library to apply a fix to core meteor code

Which forked library? All the changes needed for Blaze Components are in the Meteor core:

Blaze Components just wrap Blaze in a OOP way in a more reusable way.

Also, blaze-components@0.13.0 does not exactly scream stable either however stable the code acutally is.

That is a valid point. I should maybe release 1.0.0. :slight_smile:

In fact, you have made bugfixes as recent as 3 months ago with further commits as recent as yesterday!

One small bugfix in the past three months. And further commits are making sure that tests work with Meteor 1.2. You know, maintaining the package? You are complaining that Iron Router does not work with Meteor 1.2. So yea, commits are sometimes necessary to keep things working.

800 lines of code written in some language I don’t understand plus a
fork from core meteor with some patches being discussed in an issue
tracked in that you need to follow on yet another tracker is not just a
few CS files to me.

You can learn the language quickly. And which fork are you talking about?

23

The fork I’m referring to is lookup.js and here’s what’s written at the very top:

This file is a direct copy of Blaze lookup.js with modifications described in this pull request: https://github.com/meteor/meteor/pull/4036 TODO: Remove this file once the pull request is merged in.

My point about maintenance is, javascript speaks to and is understood/used in detail by millions of developers whereas the reach for CS is merely a fraction. That means, should a package maintainer neglect to provide a fix for an issue, as in the case with iron router now, a community member can step in within minutes of reporting the problem and propose a fix in no time and I am at liberty to use that fix in a fork. But with a CS package, the odds that someone will fix an issue that fast is much less.

Although my concern does align with maintenance problems of open source projects, it is not my main point. I’m all for using open source projects and contributing back to them, which I often do. My main point being a package written in CS is more likely to fall behind, fail or get abandoned.

And especially months/years after delivering a project in which you’ve used some open source packages, where you barely even touch the code any more, you kind of want to be nearly sure that should a problem arise with a package, you know someone will attend to it before you yourself get to have to roll your sleeves up.

[coffeescript] is a language you can learn completely in 6 hours

I here this a lot from CS enthusiasts a lot. What they neglect to say is the language has so many sutleties like a space here an arrow there an @ for a special case etc that it takes the next 6 months to actually digest them into intuition and master it. I’m fine with javascript and there’s even more every day with it now (the new annual feature release cycle!) that I won’t have time to spare for mastering CS. And who is to guarantee CS itself will be able to keep up with new and improved javascript will have to offer every new year and it won’t just become redundant or even obscure? But again, I’m not arguing against CS, I’m arguing its lack of wide spread adoption posing a maintenance threat that may affect me.

2 Likes
24

The fork I’m referring to is lookup.js and here’s what’s written at the very top:

Yes, and if you clicked on the pull request you would see that it was merged in. I am keeping this file around for now for backwards compatibility with older versions of Meteor. You know, useful for production to not break things for those stuck with older versions of Meteor.

My main point being a package written in CS is more likely to fall behind, fail or get abandoned.

Do you have stats to support this claim?

But yes, I agree, developer base is smaller. But development is quicker and there are less bugs introduced because of the quirks of the JavaScript language. Pick your trade-off.

I here this a lot from CS enthusiasts a lot. What they neglect to say is
the language has so many sutleties like a space here an arrow there an @
for a special case etc that it takes the next 6 months to actually
digest them into intuition and master it.

I am basing this on my experience with students here at UC Berkeley learning CoffeeScript. They manage to grasp it over the weekend. And again, here I am talking mostly about reading CoffeeScript. Writing big codebases I agree require a bit more experience to learn good patterns and anti-patterns, like with any tool/language. But reading and understanding of the program can come pretty quickly.

These days learning a new language is really not something one should have aversion from. More of them you learn, faster you can learn a new one. You can list them on CV. I do not know, for me this is like a normal part of our profession. To learn a new tool every few weeks at least.

But I hear what you are saying. I just think that using Blaze Components would save you so much time that you could not just learn CoffeeScript with that saved time, but also contribute some stuff. :slight_smile:

1 Like
25

you would see that it was merged in. I am keeping this file around for now for backwards compatibility

Perhaps you should mention this in that comment because that line alone, regardless of my cs-phobia, was a showstopper for me and did not even care to follow the link to see what was being forked.

Do you have stats to support this claim?

Yes: “But yes, I agree, developer base is smaller.” :wink:

I am basing this on my experience with students here at UC Berkeley learning CoffeeScript.

I think this is a rather important yet subtle distinction between executing the software engineering profession in academia vs private sector. I believe learning something even entirely new and trying things is itself a satisfying experience and even the job description itself in academics, but for us it is only a privilege we get to have every once in a while. Since programming with Meteor itself is an all new endeavour, I feel I should tread lightly in experimentation :wink:

These days learning a new language is really not something one should have aversion from

I agree completely. One even needs to reinvent themselves every few years. But the thing is, I don’t see (completely personal opinion) CS worth exploring, I even consider it a risk whil JS itself is evolving even more rapidly now.

Blaze Components would save you so much time that you could not just learn CoffeeScript with that saved time, but also contribute some stuff.

Again, I agree completely. The thing is, if some piece of tech saves me some spare time, I’d like to prioritize other tasks for that space and learning CS is not high priority for me. But what I triple-agree in this remark is that Blaze Components is a huge time saver. So much so that here I am using my spare time discussing the merits of converting BC from CS to JS (although probably highly unlikely) with you :slight_smile:

26

Ok, so Blaze 2 topic is CS-JS flame now :thumbsdown:

6 Likes
27

If I had infinite time I would just try to make a JSX to Blaze view transpiler :slight_smile:

28

I think actually basically all of these are off-topic. I’d love to see a thread discussing Mitar’s Blaze Components, and then maybe a thread talking about the benefits of plain JS vs. transpiled languages when it comes to open source.

The original proposal is basically dead, but these two conversations still have merit.

4 Likes
29

This is, on the contrary to what it seems, not a CS/JS discussion and certainly not a flamewar. I’d like to think of it as a civil and constructive debate of the affect, if any, of preference of CS over JS for package development in relation to its long term sustainability.

But you are certainly right that this should have been carried out in a linked reply and I apologize for letting my keen interest in this discussion get the best of me.

30

This is, on the contrary to what it seems, not a CS/JS discussion and certainly not a flamewar.

For you who is not on a receiving side of this maybe feels like that it is “just a debate”. But for me it really saddens me that when I spend weeks working on something and proudly give it to the community, the reaction of people is “oh, CS, I will not even look into this” (see here, and everywhere). So much hatred for CS that it simply blinds everything else. No discussion about the content, technical merits of my package/solution, no sharing of stories of how people are using it, no feedback on what looks good and what bad, no, just attack (or polite discussion, does not really matter, because of the lack of the other discussion) on the choice of the implementation language. Which should completely not matter if the package/library is made well. Implementation details should not leak through.

I really do not understand from where this entitlement in the community comes. Entitlement that it is not enough to give your work for free to them, no, you also have to do it in the language they prefer, with full documentation because otherwise no go, without ugly forks which you know that they are ugly and work hard with MDG to get merged in, but are needed to push the bar higher for everyone. Do it yourself then better. It feels really like complaining without making your own hands dirty.

Really, how much time I spend dealing with those attacks/discussion I am wondering if it is really worthwhile open sourcing my work. I would be better of not doing it.

And don’t worry, it is not your fault @serkandurusoy, you just do not realize it, because for you it looks just as only you. Only your opinion. Only one comment. And maybe it is really my problem. Maybe all those people are right with all their arguments against CS. But I am just saying that it is very unpleasant and disheartening on a human level. Despite “politeness” and “civilized”.

5 Likes
31

It is a normal behaviour, if you want to have a feedback on the package - don’t write it in CS. 99% of users don’t use it, many tried or looked examples in CS and didn’t like it - when they will see coffeescript word or .coffee extension, they will immediately close the page even w/o reading what it is about.

Now we have ES6 with many features - just use it and you will have no complains about the language.

32

@mitar I really am most sincerely sorry that you have felt bad about this discussion.

I was enjoying and actually benefiting from the debate, hearing the opposite point of view from a respected community member. I did not for a second intend for you to receive anything apart from sharing our respective ideas across.

Checking back on those links again with that in mind, I can now relate to how frustrating that this discussion at its core may have become. Please do accept my apologies.

But I sincerely do hope you do not give up on the discussion because I think it is valuable. There is no end goal of getting one to accept anything. I think the higher purpose is to get to know all sides to the CS/JS and package authoring story so that the meteor ecosystem can grow and we can all benefit from it.

And to finally repeat my probably first words in this discussion:

Well, @mitar has been very humble in accepting the requests for javascript examples and documentation and he has done an absolutely tremendous job both with the package itself and its documentation. It just shines.

I do mean that!

33

@mitar whatever you do with passion in CoffeeScript, do so. I use CoffeeScript too, yet I simply don’t care what is the popular way to create a package or to code in. If someone stops looking at a package because it was made in CoffeeScript, well … let’s not offend people. If popularity would be the reason to do things, great things would never be achieved. By the way, I love Blaze Components.

Comments about CoffeeScript about how little it is used (wonder where those facts are based upon) are just as narrow-minded as people who still say that JavaScript shouldn’t be used beyond client-side, or why React is superior over Blaze, why SQL support is a showstopper for Meteor, bla bla bla yada yada yada. Some german guy said “Once were ye apes, and even yet man is more of an ape than any of the apes.”

Do what you do, do it in a way you can achieve it and do it with passion.

@mquandalle thanks for sharing the hackpad link - loving the proposal!

2 Likes
34

such a shallow mind wouldn’t be a great loss

@miningsam I think this is way out of line. You are not in a position to judge me or likeminded people in our intellectual depth, especially not beause we don’t completely agree with you. I am at lease “deep” enough to try and learn from opposing ideas.

Comments like yours are exactly what turn “civil” to “flamewar”.

Let’s not forget that we are real human beings behind these keyboards and we all deserve simple social decency.

3 Likes
36

Personally I use CoffeeScript and don’t plan to switch. I’m not a professional developer and at the age of 33 (though that will be outdated in 3 days from now) I no longer have such ambitions, it’s purely my hobby. And I want my hobby to be entertaining. Javascript is far from being entertaining for me. ES6 makes it more bearable, but still not enough.

I read code like a book. I appreciate it when an author gives me detailed descriptions, but they have to actually add something to the story. Otherwise, I prefer author to focus on what’s really important.

Reading Javascript for me is like reading a book by a writer who adds more words to his sentences simply for the sake of using them. Like “He took his sword from his scabbard and used his sword against his opponent who was on his left side”. CoffeeScript helps me to get rid of all the unnecessary blabbing from such a sentence.

What I want to say is that because of people like me, CoffeeScript is not going anywhere, it will stay in the business for at least few upcoming years.

2 Likes
37

I hope humanity can one day reach at a level where we see no need to cencor
out offending words not because they are offending but because all we have
to say is about the merits of what we think rather than the “…” of what
others do.

But thank you anyway for recognizing my discontent.

1 Like
38

So, nice, anyone wants coffee?

Maybe the discussion might get back to Blaze 2 as it indeed is an interesting proposal. Just because there isn’t strict moderation here it’s still a good idea to all stay a bit on topic right?

39

I certainly didn’t mean to derail the conversation into a JS/CS contest. Merely to point out that there is demand for a transpiled Javascript version of what Mitar has put together.

I for one think what you’ve done is great, @mitar. And it’s very much the kind of solution that the next version of Blaze needs.

I’d like to see Blaze Components get widely adopted, and for parts of it to get moved into core. At the very least, my clients and I are seriously considering adding it into the Clinical Meteor track’s core.

That being said, the fact of the matter is that the first principle of the Meteor social contract involves Pure Javascript. And, for better or worse, transpiled languages like CoffeeScript are contentious whether they conform to that social contract or not. Does Blaze Components follow the Meteor Style Guide? Hard to say. How do those of us working in JavaScript lint it? Our IDEs and scripts are all set up for .js files, not .coffee files. And so forth.

So I bring the issue of JavaScript up, not as a criticism, but as an encouragement on how to get more widespread adoption.

40

You mean internal style guide of Meteor core packages or the sadly non-existent style guide for Meteor community?

41

Personally, I was referring to the internal style guide. (It’s not perfect, but we’re getting close to having a version of it implemented in linters and auto-formatters across a couple different platforms and editors.)

I’ve had fully-tested functionality (that implemented features requested in core package //comments) rejected because it didn’t conforming to style guidelines. And by that, I mean the spacing around function parentheses were off… function() instead of function ( ).

So, given how MDG goes about accepting PR requests and code contributions, I’d love to see the entire package converted to Javascript, and then scrubbed to conform to the Meteor style guides. It would make for a much stronger case for wider adoption, and integrated into the existing blaze package someday.

2 Likes