If Blaze improved significantly, would you go back to it?


#22

I’ve had the idea of doing progressive loading via method calls. Basically, you would pull templates in from the server after the initial load via method calls.

Edit: maybe I mixed up progresive loading and incremental loading here. I do like what Ember is doing with Fast Boot very much. I think its a must have feature.


#23

If we define possible as “it can be done with a whole bunch of hacks” then yes, Blaze has lazy loading and SSR =)


#24

Blaze could probably become a templating language with complex data-binding system looking forward to apollo integration and redux philosophy. Blaze was great at ease of prototyping and I think with new data sync paradigm, introduced with apollo, we could extend that further. Many of us however bound to things blaze currently lacking - libraries, processing reactive animations/styling(at least with little to no overhead).

Many of us(developers) are getting tired with bounds react places us in.
At the first glance ‘the holy react knight’s code’, involving best practices makes it look mature and professional, but involves too much overhead when you develop a project with a small team. You just don’t need all this 6-row components. You don’t need all this prop-types checks. Don’t need all these Presentational components and Container components. And actually you may ignore any of those ‘best-practices’. But why?

Things like typescript, redux and apollo itself show us, that people don’t want to think of anything they don’t work with. I feel, UI that is closely bound with data(and aware of its state) and doesn’t give you a ton of decisions you wouldn’t want to make, would be the next UI framework.


#25

Hacks is a strong word :stuck_out_tongue: I like to think of it as an alternative approach.

What if one can make a package of a bunch of views that work together, and then lazy load them into the application?


#26

That’s one “alternative approach” =)


#27

And how many Vue.js?


#28

I don’t enjoy coding React components - there’s far too much impedance between what I want to create and getting it out into code. Blaze is the opposite but starts to break down and become unmanageable the larger or more complex your apps get. Not sure if it’s possible to get the best of both worlds somehow.


#29

Why do people think blaze is easier to write than react? Give me an example I will write it better and shorter in React


#30

Just curious, are you implying that easier=shorter (or terse), and then implying that shorter (or terse)=better? And therefore React can be written more terse, therefore its better?


#31

both better in quality and shorter in length


#32

This is so subjective, may I ask how you define quality?


#33

easy to follow logic, no magic variable bs


#34

This is certainly in the eye of the beholder. But again, are you saying easy to reason about, or easy because its terse (shorter)?

Will you please define magic in this context?


#35

geezes, why are you asking so many question, all I trying to convey is that people who say blaze is easier to prototype and quicker to write than React are wrong


#36

But all I’m trying to understand is why you think their assertions are wrong. I’m having a hard time due to your terse (short) comments. Hence the questions.

You keep moving the goal post here, so again. Is React better because you can write something that renders to the browser in fewer lines of code?

When I asked you this the first time, your replied its easer because of quality or easier to follow logic and something about magic variables – you seem to be having a hard time explaining what you mean here.

I think if you follow through, maybe you’ll actually help someone understand just why you think React is better than Blaze.

When you shut down questions, it makes it seems as though you have no idea what you’re talking about.


#37

I feel similarly, that I’m usually more productive in React than when I used Blaze before. I think for me the biggest issues are that helpers are too far from the UI code, the data context is invisible and hard to inspect, and that #each and #if are pretty limited compared to the options one has in JavaScript.

However, there are also some frustrating aspects of React: You don’t get to use normal HTML properties, so you have to pass className instead of class, there’s no simple way to do #if without external libraries, and there’s still no way to have a component with more than one root element.


#38

More productive to me means you can achieve the same results in less time.

If this is what it means to you, then how are you squeezing that time out by using React?

For example, is it simply one writes less code in React over Blaze? What aspect of writing in React makes you more productive?


#39

I think my code has less bugs and is easier to follow with React. So I don’t know if it takes me more or less code to write something in the short term, but I find it easy to build really small components, put them in modules, and refactor as needed, because it’s clearer where my data came from and where it’s going.


#40

I’ve heard this before, and I was always confused by it.

For example, how is this confusing where the data is coming from:

person-template helper file:

// person-helper.js
fullName: function () {
  var record = persons.findOne({userId: Meteor.userId()});
  return record && record.fullName;
}

Or this helper:

// person-helper.js
persons: function () {
  var cursor = persons.find({userId: Meteor.userId()});
  return cursor;
}

Or where it’s going:

// person-template.html
<template name="person">
  <#each {{persons}}>
    <p>First Name: {{first}}</p>
    <p>Last Name: {{last}}</p>
  </each>

  <!-- or this -->
  <p>Full Name: {{fullName}}</p>
</template>

#41

What about this helper:

fullName() {
  return this.firstName + this.lastName;
}

In this template:

<template name="fullNameBadge">
  <span class="full-name-badge">{{fullName}}</span>
</template>

So that I’m not just complaining, here would be my preferred way to do this:

fullName(firstName, lastName) {
  return firstName + lastName;
}
<template name="fullNameBadge" args="firstName lastName">
  <span class="full-name-badge">{{fullName(firstName, lastName)}}</span>
</template>

Or, even better:

<template name="fullNameBadge" args="firstName lastName">
  <span class="full-name-badge">{{firstName + lastName}}</span>
</template>

(I know in this case I can just do {{firstName}} {{lastName}} but imagine I used a different example like multiplying numbers)