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.”
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
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
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.
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.
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”.
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.
@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.
@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!
@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.
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.
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.
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?
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.
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.
So @mitar, in hope of returning to the original topic, could you elaborate on the design of Blaze Components? Which decisions did you make while building it, and what was your reasoning? What needs to happen for components (the concept in general, not necessarily your package) to be adopted into Blaze itself?
I am still on the Blaze train, so I’d really love to see our minds meld and create something awesome based on the groundwork that’s already been done.
But you and others did. If someone wants to write .coffee, let him. Don’t use it if you don’t like it. Same vice versa, someone wants to write .js, let him. Someone using Emacs and not your Editor, let him, don’t try to impose your mindset onto other people at all cost, it only creates things like derailed threads… at best.
Thanks for your work Mitar, whether it’s .coffee or .js, written using Emacs on Windows while having a coffee or Webstorm on OSX while having a cup of tea, your work is welcome sir!
ANYONE WORKING FOR THE BENEFIT OF THE COMMUNITY AND DOING IT FOR FREE - like package authors - DESERVE OUR SUPPORT AND GRATITUDE.
Whether they do it in Coffee or Assembler.
I propose we end this and start two new topics for Blaze 2 and Components - if there is such a need.
