4 ms·
I think that the reverence of current frameworks is a response to the faults of the previous framework that was revered. We started with JQuery. It was fast an
by jamra 11y ago
I think that the reverence of current frameworks is a response to the faults of the previous framework that was revered.
We started with JQuery. It was fast and had a simple API. People started to learn JQuery more than they learned Javascript. You even had Stack Overflow answers that nudged people away from Javascript stating the robustness of JQuery's libraries (specifically how it worked the same on every browser).
Then, we realized that we did not want to set up our events as one offs. The result was very spaghetti code. Backbone came out of this. It was light and allowed us to modularize our code. However, it didn't really give enough structure so we switched to Angular. Angular was the holy grail. It did everything for us. Events automatically propagated state changes to our objects and automatically redrew our view afterwards. We didn't have to think anymore. It did the thinking for us.
Little by little, we started to realize that when you outsource your thinking to your framework, you end up getting stuck in crevices that your framework hasn't anticipated. In Angular, it's difficult to share state between controllers. It's outstandingly slow in that it redraws far too often. The thing that I personally was most sore about was the fact that Angular, similarly to JQuery became the new Javascript. Instead of learning how Javascript works, you needed to learn how to use Angular. This means that you couldn't just port in good Javascript code directly. You needed an Angular directive. Try using a simple charting library such as HighCharts. The examples don't work as is. You need to use the Angular version. It gets messy and all that modularization starts to work against you. It works against you because you don't have control over your javascript.
Here comes React. It takes a step back from the hand holding of Angular and just handles the rendering. You can design your Javascript classes and functions as you see fit. If you need to port in Highcharts, go for it. You can use the JQuery plugin if it suits you. All React really does is handle the rendering and re-rendering of your dynamic content on screen. It will also allow you to propagate events that will change the state of your objects, but does not do so in the same way Angular did. It gives you more granular control.
I suggest you try it out. The JSX syntax might throw you off at first, but don't give up. It's necessary for how React obtains its amazing speed. If you're just getting started, don't worry about the difference between Shadow and Virtual DOM.
- thoman23 11y agoIt absolutely is not difficult to share state across Angular controllers. Services work great for this. I also dispute that you are too far removed from "vanilla" Javascript when using Angular. I recently integrated some externally written d3 javascript code and it works as expected without forcing a conversion to "the Angular way". Finally, I certainly dispute that Angular is too slow. Our Investmynd app has a fairly data and interaction heavy front end, and its performance is quite snappy if I do say so myself. :) Now what I do think is true is that Angular is a fairly complicated beast, which when combined with the poor standard documentation, makes it a non-trivial endeavor to learn and use properly.
- jamra 11y agoI'm happy that it works for you. I'm just sharing my opinion of the framework so please continue to use whatever makes you happy. As far as using services to communicate, I personally believe that its simpler to emit events. My absolute favorite way is how Mithril makes properties accessible anywhere. That way, you can just pass references around. It's not so important how you communicate, but the complexity of doing so. I believe that in your last sentence, you might have described the point better than I. It's a complicated beast. For that reason, you have to work within its domain. You can't invent your own way of doing things. You can't apply your trade in the way you want to. I suggest you play around with a React app and pay attention to the best practices of organizing your own javascript code more than what React itself does. It's refreshing.
- thoman23 11y agoI do plan to continue to use what works for me. I also plan to experiment with React. I'm just pushing back a bit on the suggestion that Angular is not a viable framework in its own right. Regarding services vs. events, I guess that's down to personal preference. I find a singleton service holding shared state much easier to reason about and maintain than I do events (for certain things, like shared client side session state...I certainly do use events when appropriate). Regarding "doing things your own way", I guess that's a personal preference as well. Personally I like to nail down a few common implementation patterns that get the job done and then repeatedly use those and save my focus for the business problem at hand. I'm fine with the framework strongly suggesting or even requiring those implementation patterns as long as they work and aren't overly cumbersome.