101–110 of 153 posts
Might have been different if they had chosen to embrace SQL, instead of just putting it on the roadmap and letting it rot.
See, when people see that, they miss the point a bit. The beauty of Mongo is it syngerzies extremely well with a pure javascript approach.
Can someone chime in as to whether React won the frontend war? As in the super majority of new project will be developed in React. I'm not that well-versed in the Node ecosystem (I got my news from ... HN). But from little I've seen, I found it hard to believe that React would be able to react the place where jQuery was (is?). Heck, we even have a post staying on the front page today lamenting the inferiority of Reac…
Earlier quoted context omitted.
...we all know where that road leads. Code that works without surprises, experience that accumulates, projects that can be executed reliably? But of course that's not much fun when compared to tinkering around with to-do example apps on the new new thing.
Doesn't really scale to larger projects. Managing application and UI state becomes too cumbersome. With that said the new things are still very rough, I agree, but they will make our lives easier after it all settles down. It's already beginning to settle down with React becoming semi-standard.
Chasing a magic bullet can temporarily make it look like you're avoiding the problems of large projects, because when you're constantly switching frameworks you never actually reach the point of having built something large enough.
What I think Meteor has the most going for them is the ultimate UX experience for the developer. If they really hone in on making it enjoyable, and dare I say fun to work on product... then they've won in my book.
Meteor has given me that feeling thus far, and given the new trends in the community I am sure they are moving in the right direction. I've spoken with the guys there and they are carefully reviewing what the best routes are to take that creates the best experience.
Meteor is not just a vision, it's a real experience you can tap into right now that benefits a very powerful suite of tools to get up and running. We have an enterprise app built with it and it's going great. Yes, it'll bite you in the ass if you don't learn how things work (pub/sub/mergebox/reactivity) but just dive in a little and you'll see it's just a library composed of other libraries that are well documented and easy to learn. It's all really quite simple really. The beauty and evil word "magic", is how they all play well with each other.
React is probably a better choice than Blaze at this point, even for the pure fact that it allows Meteor to not worry about the view and focus on the overall UX experience of the developer above all else.
Earlier quoted context omitted.
Doesn't really scale to larger projects. Managing application and UI state becomes too cumbersome. With that said the new things are still very rough, I agree, but they will make our lives easier after it all settles down. It's already beginning to settle down with React becoming semi-standard.
Large projects are never simple and fun. Blaming it on tools is too often just scapegoating. Chasing a magic bullet can temporarily make it look like you're avoiding the problems of large projects, because when you're constantly switching frameworks you never actually reach the point of having built something large enough.
I disagree. When designed correctly, large projects are simple to work on individual features and only complex when observed in aggregate as as complete system.
> Chasing a magic bullet can temporarily make it look like you're avoiding the problems of large projects, because when you're constantly switching frameworks you never actually reach the point of having built something large enough.
I never alluded to scrapping or restarting projects to get on the latest framework so not sure where this comment came from. I've build large systems with "jQuery", large systems with React and Flux. The latter was simpler to work on, more fun, and suited the needs of the client.
I am amazed by how the article attempts to look forward to what the future will hold with JavaScript frameworks... and yet seems to be completely both dismiss or misunderstand (perhaps willfully) why previous frameworks have succeeded. jQuery did not succeed because it was a 'good enough' competitor to dojo or prototype or mootools or extjs... it succeeded because it went completely the opposite direction. it did not…
Meteor's best trick has always been data synchronization. That was the magic trick that sold your client. They proved real-time data synchronization could be simple and seamless, and everyone else had to run to catch up. But that trick is now 4 years old, and nothing else of substance really emerged. As Ember, Angular and React grew, you were never going to want to use their odd looking front end. Their data sync als…
Earlier quoted context omitted.
Large projects are never simple and fun. Blaming it on tools is too often just scapegoating. Chasing a magic bullet can temporarily make it look like you're avoiding the problems of large projects, because when you're constantly switching frameworks you never actually reach the point of having built something large enough.
> Large projects are never simple I disagree. When designed correctly, large projects are simple to work on individual features and only complex when observed in aggregate as as complete system. > Chasing a magic bullet can temporarily make it look like you're avoiding the problems of large projects, because when you're constantly switching frameworks you never actually reach the point of having built something large…
Deciding on a framework for a project takes understanding of both the application domain and the tools. When both are lacking, framework hopping happens.
I'd recommend experimenting with one or the other. If you know the domain, feel free to experiment with tools. If you don't know the domain, it's a double hazard to try to learn a new framework at the same time even though it might superficially look like a great fit.
I said more in the other thread, but I'll leave another note in this one. What I think Meteor has the most going for them is the ultimate UX experience for the developer. If they really hone in on making it enjoyable, and dare I say fun to work on product... then they've won in my book. Meteor has given me that feeling thus far, and given the new trends in the community I am sure they are moving in the right directio…
I'm sure all this magic comes with a penalty further down the line so I'll let you know whether it was worth it when I get there...