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

[manuel]

That graph was done by a React groupie with a fantasy. The code you write with React is as much “JavaScript” as CoffeeScript or any other language that compiles to the JS that browsers actually understand.

You still have to transpile what you write and the output has some vague resemblance to what you actually wrote. Babel’s output is so removed from your code it might as well have started with Scala.

The fantasy is that one day browsers will catch up and you’ll be able to turn off the transpilers. That would only work if JavaScript became fixed like it did for so many years in the aughts. Yes, I know it wasn’t exactly fixed but due to IE6 it was fixed in practice. JavaScript will continue to evolve so React code will fall under “Transpiled Languages” for the foreseeable future.

btw, no I wouldn’t go back. I will not rewrite my current apps but new ones will use React (with ViewModel of course). I haven’t decided on the stack yet, probably Horizon.

[manuel]

what would Blaze need to become to join the next generation of UI frameworks?

Lazy/progressive loading and SSR.

[sashko]

Lazy/progressive loading

That’s a limitation of Meteor’s build system, not Blaze.

SSR

I thiiiiink Blaze has the right stuff to support SSR - at least, AFAIK there’s a way to convert HTMLJS to an HTML string.

It would be really cool to have principled SSR for Blaze, Apollo is also well-optimized for SSR so it could be a good match.

[aadams]

That’s a limitation of Meteor’s build system, not Blaze.

(this may not be the right spot for this) Will you please explain the relationship between the build system and lazy/progressive loading?

[sashko]

Will you please explain the relationship between build system and lazy/progressive loading?

Modern build systems include something called a “module bundler”. Meteor’s bundles all of your code into one big blob, which is great for apps that can deal with loading all of the code up front. Some build systems, like Webpack, let you configure the tool to build several smaller blobs, which can be good for apps that need a very fast initial load time.

So there isn’t anything in Blaze that requires all of the templates to be loaded up front - that’s just how Meteor compiles your code.

[msavin]

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.

What do we the community do with Blaze?

@msavin: Incremental loading isn’t all that important to me, but your theory is correct. Blaze Templates can be passed in as helpers (that’s how my Blaze Modules package functions), so loading them via methods is pretty straightforward. How incremental do you want to be… are just the templates lazy loaded, or are the JS files that reference those templates also going to be lazy loaded? If so, there needs to be a convention for storing them so the loader knows the 2 should be tied together. Her…

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.

[manuel]

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

[gothicmage]

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.

[msavin]

Hacks is a strong word 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?

[manuel]

That’s one “alternative approach” =)

[emhmark7]

And how many Vue.js?

[peter.roehlen]

Let’s get back to the original idea - what would Blaze need to become to join the next generation of UI frameworks?

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.

[sikanx]

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

[aadams]

@sikanx

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

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?

[sikanx]

both better in quality and shorter in length

[aadams]

@sikanx

better in quality

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

[sikanx]

easy to follow logic, no magic variable bs

[aadams]

@sikanx

easy to follow logic

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

@sikanx

no magic variable

Will you please define magic in this context?

[sikanx]

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

[aadams]

@sikanx

all I trying to convey is that people who say blaze is easier to prototype and quicker to write than React is wrong

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.

@sikanx

geezes, why are you asking so many question

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