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.
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.
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.
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?
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
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.
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.
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.