Here is a proposal for blaze 2: https://meteor.hackpad.com/Proposal-for-Blaze-2-bRAxvfDzCVv
I’m not a significant contributor on the discussion, but I just think this new Discourse forum is the best place to debate this kind of issue 
4 Likes
That’s a great idea! I think discourse might be better to discuss these things than Hackpad.
2 Likes
Very nice and look pretty.
+1
What I find missing in this discussion is the notion of using viewmodels instead of the current way of manually hooking up templates and events.
1 Like
Totally agree! Blaze should have a viewmodel with preferrably a 3-way (view-client-server) data-binding, just like angular for meteor!
Why reinvent the wheel? - Well I, for one, like Blaze and is familiar with its ins and outs - and I don’t want to learn Angular from scratch when I already know much about Blaze.
3-way data binding is great, but please be careful about assumptions about naming conventions. Not everybody agrees with the ‘viewmodel’ naming convention. Current proposals are agnostic to MVC interpretations, which is a major feature for folks doing animation, rendering, or cross-device applications.
1 Like
Shameless plug: check out already available Blaze Components as a working alternative (and proposal) for Blaze 2.
3 Likes
@serkandurusoy, @awatson1978 : so, I’m a little curious.
I can’t scan CS with anything like the speed I can scan JS/ES, and I’ve never written any CS, but for me, as long as the documentation and examples are in JS/ES I’m a happy bunny - and @mitar has done a great job with the docs for Blaze Components 
.
Does it really matter that the package is in CS if it’s well documented in JS?
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.
The thing is, I still don’t feel comfortable pulling in a package whose source I don’t feel fully confident tweaking should anything go wrong and I’m in dire need of a fix/change on a production system.
3 Likes
I can understand that. It’s a fair reason, especially at 3:00 in the morning!
1 Like
Agreed. Can’t speak for others, but I’ve gotten to the point where I regularly scrub, normalize, and extend APIs. The Javascript provides a lot more fine-grained control with regard to incorporating into other packages, adding methods, figure out object state, linting, etc. We’re building a CardUI layer, so having that control and having it all in Javascript is important.
1 Like
I don’t really get it. If you’re going as far as to tweak packages, what exactly makes it difficult to convert them to JS for your own use, if you prefer JS? Not only such a function is provided by most of IDE, it’s also possible to do it online. I mean, Blaze Components is just a few CS files with nice comments explaining particular functions.
2 Likes
@serkandurusoy: But if the thing is stable and there is no need for you to fix/change things on a production system?
@awatson1978: But please, if there are missing features or things you would need, open feature requests. Then I might see that there are too many things missing and that it is not possible to satisfy them all by myself, so that there is more need for others to be to hack them. And then we could talk how to make it easier for others to do so. But for now we have been using those in production for few months and it just works, no need to change anything in core.
Also, the whole thing is made in OOP programming style. So it is really easy to extend things in your code in JavaScript. I have not seen the case that the library itself would have to be changed. Even not monkey patched. And again, you can monkey patch from JavaScript even if the library is written in CoffeeScript. And you can extend all classes with JavaScript (or ES6). It just works. So all your changes can still be in JavaScript.
I really do not understand those arguments. The point is that for me it is much faster and easier if things are in CoffeeScript. There are less bugs and I can maintain the package faster for you. Isn’t this the most important aspect? And you can still keep JavaScript for everything you need?
If you are saying, oh, I have problems reading the code and understanding the code, then, sorry, but you can spend 6 hours learning CoffeeScript and this is it. It does not take much more. And then you will be able to understand this code and any other code by other people. I think it is worthwhile investment.
Do you really use your own fork of Blaze package? Despite making Blaze Components, I have not had to do that. Why do you think you will have to maintain your own fork of Blaze Components.
So, TLDR: Just a few hours of learning will make you be able to read the code, and Blaze Components are designed so that you can extend and modify them from JavaScript without having to touch core library (in contrast with Meteor, where you often have to monkey patch stuff).
5 Likes
@robfallows: I really do not think you want to be patching 3rd party library in 3:00 AM in the morning anyway.
But please people, you are just assuming that the stuff is low quality and you will have to spend a lot of time fixing it and debugging it. Maybe exactly because it is in CoffeeScript things are more stable and work better. 
2 Likes
@awatson1978: Also, even I myself do not use vanilla Blaze Components in my projects. They are designed to be simple and barebone. I have my own base class which extends them, where I add many more custom special needs stuff for a particular project. This I think is a completely normal practice. So you should not be extending vanilla base class of Blaze Components, but you make a dummy extended class first, and then you extend that one, and then in the future when you need something, you can easily add methods there. And if you see something really useful, you can then send some of those methods upstream to be included in Blaze Components, or make them as a mixin, and/or publish your mixin or base class as a package for others to use as well.
Maybe I should publish some examples of such base classes or mixins. But the main point is that for me this is a normal programming approach I use in production. And then at 3:00 AM I have only to add a fix into this my base class, no need to be changing the core library. It was really designed for this to be possible.
Well… I’ve generally not had good success with CoffeeScript packages; and up until now I’ve not had to introduce the coffeescript preprocessor to any of my apps.
This isn’t really the direction I want to go with our apps, because the coffeescript package winds up in the .versions file, then team members start seeing it as part of the project, they start committing coffeescript files, and logging tickets, and it causes lots of downstream headaches with team management.
But I need the component functionality, and you’re one of the experienced folks around. So I’m going to give Blaze Components a try in the latest project, starting next week, beginning with some modal dialogs. Not super happy about it (feels like it’s violating Principle 1: Pure Javascript), but crossing my fingers that this works out okay.
2 Likes
@awatson1978 Again. Fork Blaze Components, convert these few CS files to JS with any available converter and you don’t even need to introduce CS preprocessor to your Meteor stack. This way your coworkers won’t see it available and there won’t be problem.
On the other hand, from your comment, it looks like your team mates would actually prefer to use CS.
@mitar Some available example custom classes or mixins would be more than welcome.
I’ve generally not had good success with CoffeeScript packages
OK, but was this because of their content/quality or because of the language?
This isn’t really the direction I want to go with our apps, because the
coffeescript package winds up in the .versions file, then team members
start seeing it as part of the project, they start committing
coffeescript files
Sorry to bring this to you, but this is something which is a project management issue. Not the question what some deep package internally uses, which dependencies and which languages. You meet with a team and you together decide on set of technologies you use, JavaScript, Meteor, and so on. If some Meteor package uses CoffeeScript this should not change the decision which you make as a team.
But I need the component functionality, and you’re one of the
experienced folks around. So I’m going to give Blaze Components a try
in the latest project, starting next week, beginning with some modal
dialogs. Not super happy about it (feels like it’s violating Principle
1: Pure Javascript), but crossing my fingers that this works out okay.
Yes, try it out. And please do give feedback. And I really think you will not have to even touch CoffeeScript. The main thing is to have in mind that package was made to be a core base package from which then you can build some patterns/base classes you like to use. In some way I hoped for the community to build some practices on top and make them into packages. But maybe Meteor community prefers premade recipes. That is why they probably like opinionated framework Meteor. So Blaze Components is somewhere in the middle, it tries to reformulate some concepts, but then does not provide much by itself.
BTW, does ES6 count as pure JavaScript? Because it makes inheritance pretty neat. Calling super in old JavaScript is a bit ugly (but you might not need to do that anyway).
Some available example custom classes or mixins would be more than welcome.
It really depends on the project. I should maybe make some TodoMVC example or something, but I do not have time. I prefer working on new libraries (see new reactive-publish).
There are quite some mixins available in issues (we use issues for discussion as well).