DEV Community

How to select a front-end framework?

Ben on August 30, 2018

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...
Collapse
 
aspittel profile image
Ali Spittel
  • Vue
    • Easy to learn
    • Very fast
    • All tools associated with it are packaged well
    • Takes parts from Angular and React and optimizes them
    • less widely adopted than some others
    • Flexible -- you can use it in multiple ways
  • AngularJS
    • Built by Google
    • Well supported
    • Huge number of features
    • Improves application scalability
    • Difficult to debug
    • Large learning curve
  • Angular 2+
    • Built by Google
    • Well supported
    • Encourages reusability
    • Improves application scalability
    • Large learning curve
  • React
    • Built by Facebook
    • Bundles frontend code into components
    • Organizes code and data to make code more reusable
    • Large learning curve
  • Ember
    • Gives a large amount of functionality out of the box
    • Opinionated (you have to use its formatting)
    • Steep learning curve

Bonus:

  • Hyperapp - super fun and uses the Elm architecture but in JavaScript. I'm a big fan of this one even though its more niche.
Collapse
 
imben1109 profile image
Ben • Edited

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.

Collapse
 
imben1109 profile image
Ben

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.

Collapse
 
aspittel profile image
Ali Spittel

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

Collapse
 
donita profile image
Donita

Such a good list of the differences!

Collapse
 
codevault profile image
Sergiu Mureşan

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.

Collapse
 
aspittel profile image
Ali Spittel

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?

Thread Thread
 
codevault profile image
Sergiu Mureşan

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 if search is undefined.

Collapse
 
quii profile image
Chris James • Edited

If it's an SPA

  • Question if it really needs to be an SPA. It probably doesn't.
  • If so, probably react i guess as that's what I know (btw, this should be your default choice unless you're trying to learn something new for yourself)
  • If not, HTML and CSS are very good for developing websites. Sprinkle a little vanilla JS when needed.
Collapse
 
imben1109 profile image
Ben

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.

Collapse
 
quii profile image
Chris James

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?

Thread Thread
 
imben1109 profile image
Ben

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

Thread Thread
 
imben1109 profile image
Ben

Vanilla Js is just a joke. -,-

It is just a regular js.

Thread Thread
 
quii profile image
Chris James

No, that's the point.

Thread Thread
 
imben1109 profile image
Ben

Collapse
 
kspeakman profile image
Kasey Speakman

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.)

Collapse
 
imben1109 profile image
Ben

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).

Collapse
 
kspeakman profile image
Kasey Speakman

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.

Thread Thread
 
imben1109 profile image
Ben • Edited

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.

Thread Thread
 
kspeakman profile image
Kasey Speakman • Edited

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, laziness efficiency finds a way. :)

Thread Thread
 
pavonz profile image
Andrea Pavoni • Edited

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.

Thread Thread
 
kspeakman profile image
Kasey Speakman • Edited

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.

Collapse
 
aswathm78 profile image
Aswath KNM • Edited

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.

Collapse
 
quii profile image
Chris James

What I learned over from experience is the manager or the client decides everything.

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.

Collapse
 
aswathm78 profile image
Aswath KNM

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

Collapse
 
imben1109 profile image
Ben

How can you know which one have the future?

Collapse
 
aswathm78 profile image
Aswath KNM

The one with the support

Thread Thread
 
aswathm78 profile image
Aswath KNM

The one with funding. Someone has to pay. Do choose one that will have most funding support.

Collapse
 
arhyth profile image
Sem Lesan

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.

Collapse
 
imben1109 profile image
Ben

What do you use?

Collapse
 
imben1109 profile image
Ben

Elm... I think it just a new language...

I think TypeScript is better...

Collapse
 
mittalyashu profile image
Yashu Mittal
  • Angular: I have heard from most of the developers is that Angular is bit hard to learn.
  • React: It easy to get started.
  • Embed: Never used, so not sure.
  • Vue: It's more popular than react and very easy to get started.
  • Extjs: Never used, so not sure.

Check out this tweet: Drifting between #angular #reactjs and #vuejs

Collapse
 
kzagoris profile image
Konstantinos Zagoris

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.

Collapse
 
iam_timsmith profile image
Tim Smith

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.

Collapse
 
imben1109 profile image
Ben

Yes. Selecting one you feel most comfortable is enough. Do not think too much. HAHA.

Collapse
 
jvanbruegge profile image
Jan van Brügge

Cycle.js, because it's completely different:

  • no magic data binding
  • one common abstraction (to rule them all)
  • functional
  • more an architecture and not a framework
  • extendable without feeling second class

(Those are the reason why I chose it and later became core team member)

Collapse
 
themightyt_v3 profile image
theMightiestT

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.

Collapse
 
imben1109 profile image
Ben

Yes. But the application should be very large (I think) for most time.

Collapse
 
michaelgv profile image
Mike

If it’s a brand new application:

For Me, I don’t select a front end framework: I build the application as is and slowly migrate to frameworks where necessary as we scale; don’t overengineer your website.

If it’s an existing application:

Figure out your pain points, build them in the framework you feel best for the job. Don’t be afraid to have micro-frontends with numerous frameworks mixed in - just ensure you only include dependencies once

Collapse
 
imben1109 profile image
Ben

I agree to some extent. I just think wasting too much on selecting a famous framework for your application is not necessary. But most importance is that you should know what they can give you.

In my opinion, a framework is necessary to select in the very beginning of a project. Because it helps you so much by reducing the time you would use and guide you how to do modern web programming.

Btw, What is micro-frontends with numerous frameworks mixed in ?

Collapse
 
tux0r profile image
tux0r

I think you should reconsider every time if you even need any framework for your project. Chances are that you'll waste too much time and space with it, especially for smaller sites.

Collapse
 
imben1109 profile image
Ben • Edited

When the project go big, terrible things would happen if wrong.

Wrong may be even better nothing. Haha

Collapse
 
joaquinmorales profile image
JoaquinMorales

If I'm not wrong, react is one way binding

Collapse
 
imben1109 profile image
Ben

I cannot get it. What did it mean?

Collapse
 
vonheikemen profile image
Heiker

Try to build something with them. See how productive you can be with each and then decide.

Collapse
 
imben1109 profile image
Ben

Yes. After that, you may find similar. HAHA.