There are so many famous front-end frameworks you can select for new project. It would completely affect productivity of your team.
How would you select front end framework for your new project?
- Angular
- React
- Ember
- Vue
- Extjs
- Hyperapp
Common Feature
Common feature of these framework
- Two-Way Binding
- Dynamic Rendering / Templating
- Reusable Component
- Http Client
- State Routing and Management
- Error Handling
Please correct me if you found wrong
Selection
For me, I would try to select one which most developers in my team just think it may be good. I do not think wasting too much time can help your project. I think "Maybe do something wrong" is better than nothing.
The most importance is no one know which selection is correct.
This Post is republished in Medium
Top comments (46)
Bonus:
Thanks. I may try try Hyperapp later.
Sadly, the learning curve of most framework quite long.
Actually, I have used trird most framework what I have written for POI.
I think angular may be the most comprehensive framework for the above stated feature.
I do not say angular is better than other framework. Other framework can be achieved by the famous libraries such as redux for react.
Such a good list of the differences!
I just find that Elm architecture is a completely different way to write Javascript. It can be seen as a language which can be compile to JavaScript.
Yeah -- Elm is a functional programming language that transpiles to JS, it follows an application structure that Hyperapp mimics, just using JS instead of the Elm language
Didn't expect AngularJS to be on the list. I think it has a smaller learning curve than Angular 2 (or 6 now?) since you don't need TypeScript.
I somewhat agree, but the error messages in AngularJS were horrific when I learned it which made it so hard to learn -- maybe its improved though?
Not really, they are still pretty bad. Especially when it fails to evaluate an expression inside the template and doesn't say anything if that failed.
For example:
{{ search.id }}would silently show absolutely nothing even ifsearchis undefined.If it's an SPA
Could these framework only be used as SPA? Actually, I do not the advantage of SPA.
I think a could try try vanillajs as so many people have mentioned.
May I know if vanillajs support two-way binding.
No they can be used for other things but that's the usual cited use-case.
What exactly do you mean by 2 way binding, what do you need? Is it necessary for every project?
two-way binding is just a concept which your variable value is bind the dom element such as input.
For example, there are a input filed and javascript variable, v. When you change the variable,v to 10, you see the field become 10. If you input 10 to the field, you will get 10 from variable v.
Reference: docs.angularjs.org/tutorial/step_06
Vanilla Js is just a joke. -,-
It is just a regular js.
No, that's the point.
？
I think it is really hard to make an informed decision without a lot of experience. Even when you lean on advice from trusted voices, unless you have someone to guide you through the experience, you might navigate it in a way that turns unpleasant. A lot of internet guides are made for demo purposes, and will lead you astray for long term maintenance.
In the end these are all valid paths to create an app, but each has its own nuances and traps. Might as well pick one that seems interesting (if learning) or is well known (if building a product).
For me, the right way is MVU-style and no framework. Libraries for integration (DOM rendering, HTTP, etc). Frameworks bring a lot of abstractions that you have to learn. These usually save time at first, but tie your hands in other ways down the road. Including knowledge dependencies. How many job listings say things like "[some framework] experience required"? Because if you are not intimately familiar with how that framework's abstractions work, you probably will take a long time to get up to speed on the code base. But like above, this no-framework advice has nuances too. (Although I find mistakes easier to fix than in framework-based.)
Yes. For learning, you should know the key concept of the framework such as two-way binding or MVU (Model-View-Update, I think). (I guess MVU and two-way binding are the same. Please correct me if I am wrong.)
Just for a project. I think I need to select a framework. In addition, I need to build my application framework on top of it as I want the application flow the same behavior or style.
I admit even a very experienced developer would find it very difficult.
I guess developers should select one they just think safe for their project. Do not waste too much time on selection. I think "do something wrong" may be better than nothing (I think).
MVU does not use two-way binding. It uses one-way messaging. The View sends messages back to your app when the user changes things. Your app updates the current state of the application (the Model). Then the Model is used to rerender the View. Whereas two-way binding keeps state on the view and the app model, and tries to directly synchronize between two when either of them change. It seems like a time saver, but ends up with a lot of edge cases and Byzantine problems.
I also do not think applications need their own framework. But using a framework leads us to think this way. Some of the apps I built that became hardest to maintain are ones where I built a framework for it.
I think it is okay to use frameworks, though. For me they were a necessary experience to learn from. For others, they might be a strict time saver because they need exactly what the framework provides and no more. But this never seems to be how things go for my projects.
I think an application framework is necessary. It can make your application share the same flow and behavior. Your team can follow the framework in order to reduce time and thus increase productivity. What I am saying is for enterprise application.
But for application which is for public, I think a framework may not be required as they need a lot of specific or funny behavior.
My use case is enterprise applications. That's pretty much all I do.
With no framework, you still make helper functions to simplify execution of common use cases. So, it is still quite easy for the team to reuse code. But the helpers are opt-in, so if the business has a custom requirement that doesn't work with an existing helper, you also have the choice to do something completely custom. Then if you need to do it more than once, you turn it into another reusable helper.
Framework or no,
lazinessefficiency finds a way. :)My experience with this kind of stuff in enteprise is that you can use a framework anyway, but mostly as pluggable widgets. Instead of helpers, I’ve also used conponents (React or Vue), for common tasks (ex: search forms, autocomplete, etc...). It worked very well, or at least IMHO, I prefer this approach over jQuery plugins/helpers.
I would prefer frameworks over jQuery too. :) As I mentioned, there are nuances to doing frameworkless well. I definitely did not mean to imply a free-for-all. There should be guiding principles to the design, of which MVU is a good one. For interacting with the DOM for example, nothing wrong with using the React renderer library, rather than trying to manipulate the DOM directly.
Depends on your mentor and projects.
What I learned over from experience is the manager or the client decides everything.
But given the above choices, choose one with the best support it'll receive in the future.
jQuery is a library like react. But it still used by thousands of developers.
Backbone is an MVC framework like Angular, but the core developers stopped supporting it.
The moral is don't go with viral or trending .
Use something that has a future.
I think there is a huge caveat here! This in my experience is not the case.
As I've said before, you are the professional here who has expertise, not the client.
If I am the programmer I'd go with Angular. Nice framework. Great support, easy to find experts and unlike react like libraries Angular is a framework ie most of the choices are already made
How can you know which one have the future?
The one with the support
The one with funding. Someone has to pay. Do choose one that will have most funding support.
everything that I try to learn in tech I judge by only this criteria: API surface area and simplicity. a good design strikes a balance between size and completeness; composed of a small but composable set of comstructs. with that said, i like MithrilJS and Elm for frontend but I have the luxury/naivety of not using them in actual work.
Elm... I think it just a new language...
I think TypeScript is better...
What do you use?
Check out this tweet: Drifting between #angular #reactjs and #vuejs
Well, that is a difficult question that has multiple answers.
First of all, the React is just the view; you need more packages in order to have a complete framework (redux, router, etc.).
If you want to learn a framework and commit yourself to it, then any of the big three (vue, angular6, react) is a good choice.
If your project is simple ( a web page), then a vanilla javascript is the preferred - for me - way to go. If you want to add a complicate service to your web page just add a preact/react component or a web component.
I agree with Ali’s assessment. I started with Vue and dabbled a bit with angular to get a feel for syntax and what “the point” is. Once I understood that, I started playing with react. Ultimately I decided to go with the one that felt the most comfortable to me. Obviously if you’re on a team I’d use whatever they use.
For the record: I went with React.
Yes. Selecting one you feel most comfortable is enough. Do not think too much. HAHA.
Cycle.js, because it's completely different:
(Those are the reason why I chose it and later became core team member)
too many people ask "which one" instead of "do i even need one?"
learn html, css and js- REALLY learn them.
you should reach for a framework if you're building something large that needs complex state menagement. if not, you'll be fine with the basics.
Yes. But the application should be very large (I think) for most time.