When we talked about virtual dom internally, I thought it would be really cool if Blaze devs could easily take advantage of the big community of React components out there, and that would become easy if it were based on the same renderer. That way you could just NPM install some React component, include it in your Blaze project, and be good to go.
It would also make a good value proposition - “Blaze uses React”
And Blaze lives on - LONG LIVE BLAZE!!!
So, @miro - can’t we already say that…[quote=“miro, post:22, topic:28664”]
“Blaze uses React”
Oh sure - but it’s not fully integrated into the virtual DOM pipeline so you don’t get the React performance boost.
Oh man, that would be great - really.
A few months back, I determined that Blaze might not be making it - and for various reasons I spoke with my client for the main project I’m working on now and we decided for me to take a month or so off and learn react and then come back and refactor the whole project. I’m almost done with that (Actually, I think I’ll be back where I was by the end of today). And I have to say, I feel much more better for it. Learning any new JS technology typically makes you a better JS programmer, and I for sure feel like that’s the case with React.
HOWEVER… if I felt like Blaze was going to have a future like it might have now that we’ve made these moves back then - maybe I would have just stuck with it.
I think this will have a great impact for those who’ve learned “Meteor” and are happy with Blaze. Especially those who can’t just take a month off and pick up React. Granted, maybe I went overboard with my React training, I’d say you could probably get by with taking a week off
All and all, I feel like this is a really good thing you all have done here making blaze it’s own thing.
+1 for bringing Virtual Dom to blaze - Even though I am a React developer at heart now - I was once enjoyed Blazing it up a long time ago. And from my Blazing days, I feel like there is something Blaze still has to offer the scene.
There is something about the flexibility of Blaze/Meteor/Session on one side of things and React/Redux/Meteor on the other. For example (now, this might be wrong for several reasons - but I’m bringing it up anyways) I like how I can just import
Session on the server where I have a method to insert some data into the database… And if I find that the user is not logged in - I set a Session variable which in turn triggers a “login” modal screen to request my user to login (I throw an error also right after that Session.set). I agree, that I should be checking for this on the client side - and I actually am. I just like the fact that with Session - I CAN do this from the server. And my component watching that Session variable still gets “re-rendered” because of the createContainer context - so, in effect - it’s kind of like redux, I know it’s not the same for a lot of reasons - but this way just seams simpler to me for now. And that’s what I mean - I like how with Blaze/Meteor you can just “do” what you want to do sometimes, yes I like the structure of React, it’s made me a better developer. But sometimes, freedom feels good, and get’s the job done.
What we are looking at right now is implementing Incremental DOM https://github.com/meteor/blaze/issues/45, which in theory, could be done rather quickly and produce great results. I have seen benchmarks where Virtual DOM didn’t provide that much improvement for large pages on weaker devices (due namely to the doubling of memory, you hold the page, as it seems, twice in memory)
THE PROPHECY HAS BEEN RESTORED
I feel you man - I’m a pretty big Blaze fan myself, and I’m glad someone is taking it to the future.
When did we get Session on the server? Or am I misreading you? Somehow you’re linking Session with server. Are you saying you can pass flexible global state (Session) from the client to the server – and you enjoy that? And if true are you then suggesting you have limitations on what you can pass to the server with the React framework?
Are you suggesting, in theory, with Blaze implementing ‘Incremental DOM’ it will be faster (less processing) than React?
Yes, I am suggesting that
Once we implement it, we’ll know for sure.
Oh my gosh, I realize on the second read, that was HORRIBLY written… You understood me, but I almost didn’t understand MYSELF after reading that a second time. For clarity.
Way back when my client and I decided to switch to React for this project, if we had felt like Blaze had a stable future… Maybe not as stable as React, but at least felt like we had some kind of support or future (like we do now that it’s becoming a community project and could live on) - then, maybe we would have stuck with Blaze.
I think this breathes life back into something that I think is valuable to hang on to.
I feel embarrassed now… And I recognize that perhaps this is only actually working in practice because I’m importing the method, and I guess this check is actually happening on the client side… Funny, I never got an error about this in the console - It seams to be working just fine - heh.
So, yes - I am saying that I put a Session.set() in my method - Here’s the gist to see what I’m doing. I guess you’re right, this is possibly bad design.
Well… Long Live Bad Design!!! Wait, I mean… Blaze!!! (So yeah, Blaze never encouraged me to do this, I came up with this stupid idea all on my own)
I have to say, I’ve been very impressed with the level of activity on the Blaze repo since it was “officially” opened to contributions just recently.
Let’s keep the momentum going. Everyone, if you have the time and are passionate about Blaze, find a way to contribute!
I still haven’t been able to get an invite to the slack channel. Would love to get that figured out so I can participate in the day to day conversation.
So great, looking forward to blaze in my non-meteor projects!
Yeah, it just says invite_limit_reached