Hi Guys,
I have an existing web app written using jQuery that I want to rework gradually, so that the app still operational while using the reworked modules. What do you recommend? Thanks.
ericpaulbasbas
Posted on
Should I use frameworks or libraries such as Angular, React, or VueJS or not?
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (11)
I can write only about AngualrJS up to 1.6 and React used both sticking to React. Learning curve much shorted and code more readable, also gives you some knowledge to start developing mobile applications with React Native. Personally enjoy to work with React never enjoyed from AngualrJS.
In my private projects use JavaScript + HTML5 + Mustache (for templates) + other staff that not limits me. Can't find evidences that frameworks improve development speed or helps to decrease BUGs number.
I'm actually leaning towards React, but before dwelling into it, just want to justify the use. I don't want to use React just because it is hot/cool/trending now but the benefits I'll have of using it. BTW, thanks for that quick response.
When developing single page applications managing page states, routing and templates is real headache. React gives you all mentioned above and helps to write clear good fragmented code. From other side each framework limits you in it's logic. So clear answer not exists. What can I say that I used AngularJS for year and half, last half year using React and little bit used backbone, React is clear winner between the frameworks.
I would use VueJS because it's versatile. You can use VueJS to control your whole front end project or use it in one section (like a div element). So If you are reworking a Jquery module with Vuejs, your other modules will still work.
Also, VueJS is simple but powerful. If you are already using Jquery to control your application, VueJS is not much of a stretch to learn.
I encourage you to look at the offical VueJS guide.
My recommendations in order would be:
Can't really recommend angular.
How I rewrote our login page in Elm was to attach Elm to a
divbelow all the existing stuff then compare it's behavior to the old stuff. This way you can play with both at the same time and make sure I all the functionality is there. It even allowed me to merge in changes from master and compare them to my rewrite. Admittedly this may not be as good as attaching it to one widget on the page and growing outwards but it's an idea.edit:
divs don't stand for divorce 😂, dang autocompleteI have done front ends in pure JS, jQuery, Kendo UI, Angular 1.x. Nowadays, I am pretty down on UI frameworks with heavy abstractions. It feels like you have to learn a very large amount of incidental knowledge that does not transfer to a different framework or platform. Why can't I just use standard computer science things to translate objects into UI primitives?
I've begun to realize that's exactly what my team is doing now that we are using Elm (a language / platform that compiles to JS). Elm can feel like a large learning curve, but it turns out not to be incidental framework-specific knowledge. It's learning how to properly use functions, types, and separate decisions from side effects. That knowledge transfers, even to OO. You can integrate Elm into jQuery applications (through a feature called Ports), but they cannot both be manipulating the same DOM elements. Elm uses a DOM renderer similar in principle to React's, so it will detect differences in the DOM and overwrite changes from jQuery. I would recommend carving off a piece of the app that is fairly self-contained to avoid using ports that much, because ports are one of the pieces of incidental knowledge.
Introducing Elm to a Javascript App
So anyway, I would suggest Elm. But fair warning: it will challenge you to think about problems very differently from jQuery. Totally worth it though.
This question is difficult to answer without some context about what your application is.
In general, my rule is to start with the smallest toolset, that doesn't hurt to use. So my first recommendation is to ask yourself: What's your motivation to change? Is your codebase difficult to work with? Is the app hard to test? Is it slow?
If it's a Todo App, that doesn't do much of anything and doesn't exist in a broader ecosystem of applications. Then employing a "heavy" JS framework would make very little sense. You'd stand to gain very little outside of learning a new skill, which can be valuable in its own right.
But don't be fooled into believing that great web apps need to be written with big frameworks. There are plenty of great examples of apps and teams that work wonderfully with just plain ol' Javascript.
As a way forward, and as a general recommendation: I'd pick a single component in your existing app, even just a button or a text input. Create a branch, then replace that single component with a new one built in Angular. Then do the same with React. And again with Vue. Bear in mind that this may mean wrapping your entire existing application in some kind of monster component, but we're experimenting, so it's a-ok.
This will immediately give you a taste of what the setup and workflow is like with each of these frameworks without a huge time investment on your part. You'll discover very swiftly that frameworks introduce positives (readability, re-usability, testability) and negatives (boilerplate, big ol' build/type systems, more npm dependencies that you can imagine).
From there, you can decide whether the pros outweigh the cons given your use-case.
My personal preference is React, tested with Jest. I make a point to avoid introducing things like Redux and Thunk et. al. until it's absolutely necessary (which it frequently never is).
Spot-on. I did this on a team I was on, and it was an excellent (and fairly quick) exercise.
One thing you should also do is make sure that stateful components--perhaps something a little more complex than an input or button--can interact well with the rest of your application in a given framework. In my experience, any framework will get you off the ground with a simple app in a couple of days, but some frameworks (notably Angular) do not play nice with anything outside of their own walled garden.
Thanks Leighton for that response, I might do what you suggest and test a very small component of my app using those frameworks/libraries.
A lot of advice you will get will fall into the category "I use BullshitJS so I recommend BullshitJS". Bottom line is that you can accomplish your goal no matter which framework you choose, so it all comes down to personal preferences. Determine which aspects are the most important for your project (state management, routing, component composition?) and try to get a sense of how the different frameworks tackle them. Pick the framework that feels right for you. In many ways all frameworks are similar. It's your productivity that matters.
It depends. It is a little bit hard to choose one as the best.
When I want to use such a framework for an existing web app, I prefer Vue JS to others. Even if you are using jQuery, you will be able to work with Vue JS in a limited area of a web page as well. It is pretty easy to integrate it with existing web apps. That's why I like it.
Instead, if you want to develop a single-page application, I recommend other frameworks. You might need a comprehensive toolset when you try to control the app. Of course, Vue JS can do that, but others may also provide elegant solutions. It is just a matter of personal preference, I think.