Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

cristian9509's avatar

Which JS framework to start learning first? Vue, Angular, React or Ember?

I am planning to build a small app which would really make use of extensive front-end. Looking at these four frameworks I get a bit overwhelmed and have no clue on which to choose to learn while I am building the app. I assume that if I pick one and learn it I would get the idea (or the main idea) behind all of them. Sort of like knowing Laravel you have better understanding on CodeIgniter or Symphony.

My challenge is to pick one that would get me the most benefits in terms of learning, and maybe a future job (and not what it can do for my app). I lack front-end knowledge and I want to learn more.

I understand Vue is much simpler than Angular or React but I also understand that Angular and React are much richer than Vue. I know too little of Ember to know its position against the other three mentioned.

So would Vue be top pick in terms of learning my first front-end framework and if opportunity arise to quickly move into learning Angular or React?

Thank you.

0 likes
32 replies
jlrdw's avatar

First of all no JavaScript is a front-end it's a browser framework for manipulating what's in the browser. The true definitions front end and backend are:
Backend is equal to the raw data sitting in the mysql database. The frontend is the database management system that is written in PHP to manipulate the database records, crud in other words. So the JavaScript is to manipulate browser data has nothing to do with a front end. Some modern people recently coined these JavaScript libraries as frontends but they are not.
Angular or react for your question, or just use the regular laravel and just use JavaScript to a minimum amount in your applications.

jimmck's avatar

Front end code is client based. PHP is executed on the server and delivers markup to the front end client typically a browser. Vue would make a good start. It has a low overhead in terms of getting started.

kocoten1992's avatar

@cristian9509 That guy hold a grudge again javascript, ignore him (kidding :D).

I say you go framework if you need 2 way data binding, make a change and everything else just update, that where these framework shine.

Vue is recommend, it should be enough to build large SPA application, learning curve is low (should be able to write some in 3 days), and it not like you will only marry to Vue, once done try other framework as well

cristian9509's avatar

@kocoten1992 can you please explain what is SPA? Everybody uses this term and I cannot get a real explanation for it.

kocoten1992's avatar

It's Single Page Application, using tech like ajax or socket to make change on page, even the url, but the user actually not really navigate anywhere, when you see thing like #! in url, that the sign :)

zachleigh's avatar

If you're just starting off with javascript, I would suggest not using a framework at all. Use browserify and write your own modules.

squigg's avatar

If you are hoping to get employed with it, and are desperate to learn a framework, probably best to go with one of the "big" ones like Angular or React that are more mature, feature rich and more commonly used in existing production apps. There are thousands of resources out there to help you learn, and lots of existing code you can look at for inspiration/help.

I strongly considered Vue, but it still seems too much of a one-man-band operation with comparatively few resources available for help if you get stuck, and a limited quantity of tested and robust reusable components. It has great promise, but in my opinion needs a few more versions released before I would use it.

2 likes
stereoscience's avatar

I started with react and loved it although there is a learning curve if you don't know much about JavaScript. I never really liked angular too much. Vue is super easy to learn but like @squigg said, it's just not as popular yet. I will say that learning vue makes it a little easier to learn react in my experience. It's your call but I'd say learn which ever you feel will be most beneficial. Most job postings I've seen lately want react or angular but the Laravel community is adopting vue quickly.

jlrdw's avatar

Above someone has confused JavaScript with Ajax though Ajax is done through JavaScript, JavaScript would be like simply changing a text field to read something else, like hi Randy instead of hi Sally. Whereas ajax is also server-side because you are doing a call to the server going through the PHP controller and ultimately model to get the data. So once again a frontend is the database management system written to do crud and there's nothing else or nothing more to this than that. Weather PHP and laravel alone is used or angular in conjuction with laravel is used, the actual front end is the PHP code making the crud work.
If you have a browser application only then you have no backend or frontend setup just a browser application that really does nothing.
Like in a client server application, I once used Visual FoxPro, so the application in Visual FoxPro would have been the front end and the actual database itself was the backend.
Code that manipulates the view in the browser is nothing more man code that manipulates the view in the browser, it's not a front end. Front end is the code that does the actual mechanics to do the crud.

jimmck's avatar

AJAX does not reside on the server. It is a piece of code that facilitates asynchronous communication over a socket. In the case of a browser which is what it was written for that means sending a request to a server listening typically on port 80. Normally browsers block when making a call to the server. This drove many traditional developers crazy. They were used to creating full blown applications on desktop. Again Windows was a typical platform. Windows applications were cooperatively multitasked via a message loop. You got a message, serviced it and went back to listen. It was NodeJS circa 1995. So back in the browser your HTTP request went off and you could do things while the server did its thing. That thing could be anything, a database call, read/write a file, whatever, wrote in C or PHP or Java or shell. When it was done it wrote back and deep inside the bowls of the client operating system a select call written in C would fire and let the browser know it had data. And bam you had a browser page acting like an application and all was happy in the land. Browser became so popular in the client world because a user could to a single source and find ways of getting things done. A desktop with icons spread far and wide could be reduced to one. Corporate IT looked upon this and it was good and said to its developers Browserify...

MikeHopley's avatar

the actual front end is the PHP code making the crud work.

No, that's back-end code.

Front-end code is executed on the client (the browser). Back-end code is executed on the server.

Back-end code includes PHP and MySql. Front-end code is mainly HTML, CSS, javascript. In the case of HTML and CSS it might be more correct to say they are "parsed" or "rendered", rather than "executed".

(And of course javascript can be executed on the server, like Node.js, but that's a different story.)

This distinction between front-end and back-end does get a little awkward when you think about back-end code like view templates, which ultimately generate the front-end code (HTML) that is sent to the browser.

thomaskim's avatar

I've seen various definitions. Some people consider PHP to be "front-end, server-side" while the browser would be "front-end, client-side". Sometimes, I've seen "middle-end". Nowadays, I think more people side with "backend", but to me, it doesn't really matter.

Anyway, I would go with Vue hands down. After that, my next choice would be React. Vue is the easiest to pick up from the group, but like any language / framework / etc., you just need to sit down and practice.

topvillas's avatar

Don't learn Angular. If it wasn't a Google project, it would have fallen on it's unintuitive, awkward arse a long time ago. A truely terrible framework that doesn't deserve the traction it's achieved. React looks better if you can get over the weird JSX thing. Take a look at Aurelia if you're planning an SPA, it's a framework that just gets out of your way with a beautiful binding syntax. What Angular 2 could have been, if they hadn't made a mess of that.

2 likes
ifpingram's avatar

@MikeHopley's definition is correct:

Front-end code is executed on the client (the browser). Back-end code is executed on the server.

2 likes
jlrdw's avatar

I cannot help it if modern folks have changed terminology. Traditionally backend is raw data sitting in a database doing absolutely nothing, front end is all the code to manipulate the data, in other words crud. And a living room is a room not a space in my world, not my fault modern people change terminology. Next they will be calling pyramids squares.

MikeHopley's avatar

Traditionally backend is raw data sitting in a database doing absolutely nothing, front end is all the code to manipulate the data, in other words crud.

I don't think that's true. Do you have any source for this?

1 like
jekinney's avatar

If you know some and understand the basics of JavaScript already. I would go with vue.

Where angular and ember are great they use there own syntax and suger that you need to learn and understand. With the power of Laravel imo they are to much and learning curve is huge.

Two things make vue amazing with Laravel. One: it's lite weight file size, lighter then jquery. Second: you can use plan JavaScript and jquery along with plugins like sweet alert, data tables moment etc. with out hassle. Add in Vue resourse and your all set.

dawiyo's avatar

I would say Angular is like the WordPress of JavaScript frameworks. Tons of resources and tutorials for it but not without its flaws and naysayers. I prefer it but different strokes, different folks.

davestewart's avatar

I'm surprised no-one has yet asked, "what is your app?"

You mention "extensive front end" so I assume you have needs which mean that even building something using perhaps Bootstrap, forms, and a Laravel/Lumen back end, won't be enough? Then again, you also mention that you "lack front end knowledge" so I'm wondering if you even know why you might need "extensive" front end.

If this is just a learning exercise, then rather than building an app from scratch, I'd simply suggest doing some tutorials and getting to know a little of each framework. You're correct that there are common themes, but each of the frameworks you mention cover different (overlapping) areas.

Otherwise, if you do need to build whatever app you need in a short time period, it strikes me that you should leverage as much of your back end knowledge as possible to support you through the process.

If you'd like to explain a little more of your aims, and your existing skills, it will probably be easier to suggest an appropriate framework.

EDIT: Great Quora question which I think helps to answer your question very well: https://www.quora.com/Which-should-I-learn-Mithril-Vue-or-Angular

2 likes
jlrdw's avatar

@MikeHopley see http://www.oracle.com/technetwork/articles/javase/webappdev-142313.html where they refer to JSP as frontend.

Web Application Development with JSP and XML Part I: Fast Track JSP
        
     
        
 

Articles Index

By Qusay H. Mahmoud
(June 2001)

If you have had the opportunity to build web applications using technologies such as Common Gateway Interface (CGI) and servlets, you are accustomed to the idea of writing a program to generate the whole page (the static and the dynamic part) using that same program. If you are looking for a solution in which you can separate the two parts, look no further. JavaServer Pages (JSP) are here.

JSP pages allow you to separate front-end presentation from business logic (middle and back-end tiers). It is a great Rapid Application Development (RAD) approach to Web applications. This series of articles provides a hands-on tutorial explaining how to develop modern Web applications for today's and tomorrow's market. This series begins with this article, which explains the concepts and benefits of JSP technology, and then shows you how to utilize this exciting technology, and how to create reusable components for handling forms.
The Dynamic Web

The Web has evolved from a network-based hypermedia distributed information system offering static information to a marketplace for selling and buying goods and services. The increasingly sophisticated applications to enable this marketplace require a technology for presenting dynamic information.

First generation solutions included CGI, which is a mechanism for running external programs through a web server. The problem with CGI scripts is scalability; a new process is created for every request.

Second generation solutions included web server vendors providing plug-ins and APIs for their servers. The problem is that their solutions were specific to their server products. For example, Microsoft provided Active Server Pages (ASP) that made it easier to create dynamic content. However, their solution only worked with Microsoft IIS or Personal Web Server. Therefore, if you wanted to use ASP you had to commit yourself to Microsoft products and you would not be enjoying the freedom of selecting your favorite web server and operating system!

Another second generation technology that is quite popular in enterprise computing is servlets. Servlets make it easier to write server-side applications using Java technology. The problem with either CGI or servlets, however, is that you have to follow the write, compile, and deploy life cycle.

JSP pages are a third generation solution that can be combined easily with some second generation solutions, creating dynamic content, and making it easier and faster to build web-based applications that work with a variety of other technologies: web servers, web browsers, application servers and other development tools.
JavaServer Pages (JSP)

The JSP technology is an open, freely available specification developed by Sun Microsystems as an alternative to Microsoft's Active Server Pages (ASP) technology, and a key component of the Java 2 Enterprise Edition (J2EE) specification. Many of the commercially available application servers (such as BEA WebLogic, IBM WebSphere, Live JRun, Orion, and so on) already support JSP technology.
JSP versus ASP

JSP and ASP deliver similar functionality. They both use tags to allow embedded code in an HTML page, session tracking, and database connection. Some of the trivial differences are:

    ASP pages are written in VBScript and JSP pages are written in the Java programming language. Therefore, JSP pages are platform-independent and ASP pages are not.
    JSP pages use JavaBeans technology as the component architecture and ASP pages use ActiveX components.

Beyond these trivial differences, there are a number of important differences that may help you in choosing a technology for your organization:

    Speed and Scalability : Although ASP pages are cached, they are always interpreted. By contrast, JSP pages are compiled into Java servlets and loaded into memory the first time they are called, and executed for all subsequent calls. This gives JSP pages aspeed and scalability advantage over ASP pages.
    Extensible Tags : JSP pages have an advanced feature known as extensible tags. This mechanism enables developers to create custom tags. In other words, extensible tags allow you to extend the JSP pages tag syntax. You cannot do this with ASP pages.
    Freedom of Choice : Unless you install Chili!Soft ASP, ASP pages work only with Microsoft IIS and Personal Web Server. Using ASP pages requires a commitment to Microsoft products, while JSP pages do not tie you to any specific web server or operating system. JSP pages are becoming a widely supported standard.



For a more detailed comparison between JSP pages and ASP pages, see Comparing JSP and ASP.
Software Environment

To run JSP pages, you need a web server with a web container that conforms to JSP and servlet specifications. The web container executes on the web server and manages the execution of all JSP pages and servlets running on that web server. Tomcat 3.2.1 is a complete reference implementation for the Java Servlet 2.2 and JSP 1.1 specifications. Download and install binary versions of Tomcat.

To configure Tomcat:

    Set the environment variable JAVA_HOME to point to the root directory of your Java 2 Standard Edition (J2SE) installation.
    Set the TOMCAT_HOME environment variable to point to the root directory of your Tomcat installation.
    To start Tomcat, use TOMCAT_HOME/bin/startup.bat for windows or startup.sh for UNIX.
    By default, it will start listening on port 8080.
    Save your .jsp files in TOMCAT_HOME/webapps/examples/jsp and your JavaBeans classes in TOMCAT_HOME/webapps/examples/web-inf/classes.

    Note: If you work under Windows, you may get an Out of space environment error when you try to start Tomcat. There are two ways to fix this: either change the initial memory setting of the DOS window to a value greater than 3200 OR edit the config.sys file and add the following line: SHELL=c:\PATHTO\command.com /E:4096 /P.

How JSP Pages Work

A JSP page is basically a web page with traditional HTML and bits of Java code. The file extension of a JSP page is ".jsp" rather than ".html" or ".htm", and that tells the server that this page requires special handling that will be accomplished by a server extension or a plug-in. Here is a simple example:

Sample 1: date.jsp

     
<HTML>
<HEAD>
<TITLE>JSP Example</TITLE>
</HEAD>
<BODY BGCOLOR="ffffcc">
<CENTER>
<H2>Date and Time</H2>
<%  
java.util.Date today = new java.util.Date();
out.println("Today's date is: "+today);
%>
</CENTER>     
</BODY>     
</HTML>     




This example contains traditional HTML and some Java code. The tag <% identifies the beginning of a scriptlet, and the %> tag identifies the end of a scriptlet. When date.jsp is requested from a web browser, you see something similar to Figure 1.

 
Figure 1: Requesting date.jsp


Behind the Scenes

When this page (date.jsp) is called, it will be compiled (by the JSP engine) into a java servlet. At this point the servlet is handled by the servlet engine just like any other servlet. The servlet engine then loads the servlet class (using a class loader) and executes it to create dynamic HTML to be sent to the browser, as shown in Figure 2. For this example, the servlet creates a Date object and writes it as a string to the out object, which is an output stream to the browser.

 
Figure 2: Request/Response Flow when Calling a JSP


The next time the page is requested, the JSP engine executes the already-loaded servlet unless the JSP page has changed, in which case it is automatically recompiled into a servlet and executed.
Scripting Elements

In the date.jsp example the full Date class name is used including the package name, which may become tedious. If you want to create an instance of Date simply by using: Date today = new Date(); without having to specify the full class path use the page directive as follows:

Sample 2 :date2.jsp

     
<%@page import="java.util.*" %>
<HTML>  
<HEAD> 
<TITLE>JSP Example</TITLE>  
</HEAD> 
<BODY BGCOLOR="ffffcc">
<CENTER> 
<H2>Date and Time</H2>  
<% 
java.util.Date today = new java.util.Date();
out.println("Today's date is: "+today);
%>
</CENTER>
</BODY> 
</HTML>


Yet, another way of doing the same thing using the <%= tag is by writing:

Sample 3:date3.jsp

     
<%@page import="java.util.*" %>     
<HTML>     
<HEAD>     
<TITLE>JSP Example</TITLE>     
</HEAD>     
<BODY BGCOLOR="#ffffcc">     
<CENTER>     
<H2>Date and Time</H2>     
Today's date is: <%= new Date() %>     
</CENTER>     
</BODY>     
</HTML>     


As you can see, the same thing can be accomplished using different tags and techniques. There are several JSP scripting elements. Here are some conventional rules that will help you use JSP scripting elements effectively:

    Use <% ... %> to handle declarations, expressions, or any other type of valid snippet of code. Sample 1 above is an example.
    Use the page directive as in <%@page ... %> to define the scripting language. Also, it can be used to specify import statements. Here is an example:
    <%@page language="java" import="java.util.*" %>.
    Use <%! .... %> to declare variables or methods. For example:
    <%! int x = 10; double y = 2.0; %>.
    Use <%= ... %> to define an expression and cast the result as a String. For example:
    <%= a+b %> or <%= new java.util.Date() %>.
    Use the include directive as in <%@ include ... %> to insert the contents of another file in the main JSP file. For example:
    <%@include file="copyright.html" %>.

Handling Forms

One of the most common parts of ecommerce applications is an HTML form where the user enters some information such as name and address. Using JSP, the form's data (the information the user enters in the form) gets stored in the request object that is sent from the browser to the JSP container. The request is processed and the result is sent through the response object back to the browser. These two objects are implicitly available to you.

To demonstrate how to handle HTML forms using JSP, here is an example form with two fields: one for name and the other for email. As you can see, the HTML form is defined in a JSP source file. The request.getParameter method is being used to retrieve data from the form into variables created using JSP tags.

The process.jsp page prints either a form or the information provided by the user depending on the values of the form's fields. If the form's values are null the form is displayed, otherwise, the information provided by the user is displayed. Note that the form is created and being handled by code in the same JSP file.

Sample 4: process.jsp

     
<HTML>     
<HEAD>     
<TITLE>Form Example</TITLE>     
</HEAD>     
<BODY BGCOLOR="#ffffcc">     
<% if (request.getParameter("name")==
null && request.getParameter("email")
 == null) { %>     
<CENTER>     
<H2>User Info Request Form</H2>     
<FORM METHOD="GET" ACTION="/developer/technicalArticles/xml/WebAppDev/process.jsp">     
<P>     
Your name: <input type="text" name=
"name" size=26>     
<P>     
Your email: <input type="text" name=
"email" size=26>     
<P>     
<input type="submit" value="Process">     
</FORM>     
</CENTER>     
<% } else { %>     
<%! String name, email; %>     
<%     
name = request.getParameter("name");     
email = request.getParameter("email");     
%>     
<P>     
<B>You have provided the following 
info</B>:     
<P>     
<B>Name</B>: <%= name %><P>     
<B>Email</B>: <%= email %>     
<% } %>     
</BODY>     
</HTML>     


If process.jsp is requested from a web server, you see something similar to Figure 3.
Figure 3: process.jsp loaded


Enter your name and email and click on Process to submit the form for processing, and you see something similar to Figure 4.
Figure 4: Form is processed
Reusable Components

The above example form is simple in the sense that there is not much code involved. When more code is involved, then it is important not to mix business logic with front end presentation in the same file. Separating business logic from presentation permits changes to either side without affecting the other. However, production JSP code should be limited to front end presentation. So, how do you implement the business logic part?

That is where JavaBeans come in to play. This technology is a portable, platform-independent component model that lets developers write components and reuse them everywhere. In the context of JSP, JavaBeans contain business logic that returns data to a script on a JSP page, which in turn formats the data returned from the JavaBean component for display by the browser. A JSP page uses a JavaBean component by setting and getting the properties that it provides.
What are the Benefits

There are several benefits to using JavaBeans to augment JSP pages:

    Reusable components: different applications will be able to reuse the components.
    Separation of business logic and presentation logic: you can change the way data is displayed without affecting business logic.
    Protecting your intellectual property by keeping source code secure.

Example: Using JavaBeans with JSP

Now, let's see how to modify the process.jsp example above to use JavaBeans. In the above form these are two fields: name and email. In JavaBeans, these are called properties. So, first you write a JavaBean component with setX and getX methods, where X is the property name. For example, if you have get and set methods: setName and getName then you have a property known as name. Sample 5 shows a FormBean component.

Good components must be able to interoperate with other components from different vendors. Therefore, to achieve component reuse, there are two important rules (which are imposed by the JavaBeans architecture) to follow:

    Your bean class must provide a constructor with no arguments so it can be created using Beans.instantiate.
    Your bean class must support persistence by implementing the interface Serializable or Externalizable.

Sample 5: FormBean.java

     
package userinfo;     
import java.io.*;     
public class FormBean implements Serializable {     
  private String name;     
  private String email;     
  public FormBean() {     
   name = null;     
   email = null;     
  }     
  public void setName(String name) {     
   this.name = name;     
  }     
  public String getName() {     
   return name;     
  }     
  public void setEmail(String email) {     
   this.email = email;     
  }     
  public String getEmail() {     
   return email;     
  }     
}     


In order to use the FormBean component in the JSP file, you need to instantiate the bean component. This is done using the <jsp:useBean> tag. The next line <jsp:setProperty> is executed when the bean is instantiated, and used to initialize the bean's properties. In this case, both properties ( name and email) are set using a single statement. Alternatively, it is possible to set the properties one at a time, but first you need to retrieve the form's date. Here is an example of how you would set the name property:

     
<%! String yourname, youremail; %>     
<% yourname = 
request.getParameter("name"); %>     
<jsp:setProperty name=
"formbean" property="name" 
value="<%=yourname%>"/>     


Once the properties have been initialized with data retrieved from the form, property values are retrieved for presentation using <jsp:getProperty> in the else part, as shown in Sample 6.

Sample 6: process2.jsp

     
<jsp:useBean id="formbean" class=
"userinfo.FormBean"/>
<jsp:setProperty name="formbean" property=
"*"/>    
<HTML> 
<HEAD>
<TITLE>Form Example</TITLE>
</HEAD>
<BODY BGCOLOR="#ffffcc">
<% if (request.getParameter("name")==null
 && request.getParameter("email") == null) { %>
<CENTER>
<H2>User Info Request Form </H2>
<form method="GET" action="/developer/technicalArticles/xml/WebAppDev/process2.jsp">
<P>
Your name: <input type="text" name=
"name" size=27>
<p>     
Your email: <input type="text" name=
"email" size=27>    
<P>     
<input type="submit" value="Process">
</FORM>
</CENTER>
<% } else { %>
<P>
<B>You have provided the following info</B>: 
<P>     
<B>Name</B>: <jsp:getProperty name=
"formbean"
property="name"/>     
<P>     
<B>Email</B>: <jsp:getProperty
name="formbean" property="email"/> 
<% } %>     
</BODY>     
</HTML>     


Conclusion

Developers interested in developing quality production web applications should familiarize themselves with technologies that are applicable not only for today's market but tomorrow's as well, namely JSP and XML. The next article will discuss the capabilities that the JSP technology provides that are ideally suited for working with XML; and show you how to effectively use JSP with XML. JSP and XML make an excellent combination for web applications that share information, because JSP pages have XML support built right into them in the form of JSP custom tag libraries. Stay tuned for more information on this in the next article in this series.
For more information

JSP
Tomcat
Comparing JSP and ASP

This part is good explaination:
Reusable Components

The above example form is simple in the sense that there is not much code involved. When more code is involved, then it is important not to mix business logic with front end presentation in the same file. Separating business logic from presentation permits changes to either side without affecting the other. However, production JSP code should be limited to front end presentation. So, how do you implement the business logic part?

That is where JavaBeans come in to play. This technology is a portable, platform-independent component model that lets developers write components and reuse them everywhere. In the context of JSP, JavaBeans contain business logic that returns data to a script on a JSP page, which in turn formats the data returned from the JavaBean component for display by the browser. A JSP page uses a JavaBean component by setting and getting the properties that it provides.

Basically jsp compares to asp.net, asp, and php. So when you echo something like

echo $row->customername;

THAT IS FRONT END CODE. THAT IS ALSO PHP. Javascript is a view manipulation technology, it is impossible for javascript to be a front end, the front has to talk to the back, via the server. I guess it could be called a in front of you technology due to browser.

davestewart's avatar

@jlrdw no need to post all that code; the link will suffice. Your notion of front vs back end is indeed outdated / wrong if that's what you're going on.

2 likes
jlrdw's avatar

@davestewart you could write a complete web database management system with php for a mysql database with no javascript at all, thus javascript has nothing to do with frontend one million years ago, now, or one million years from now. The actual front is the php mixed with the html, that will last as long as the SUN burns, it is a constant, never changing thing. If modern people who can't weld, and only want cubicle jobs want to say otherwise, well so be it.
I started out in dbase 3 in the late 80's, I can weld, and I wrote javabean, jsp, and servlet code for a large trucking co. It delt with dispatch, accounts payable / receivable, payroll, etc. Some State governments don't even use javascript on sensitive databases, JAVASCRIPT cannot be a frontend, it's impossible.

davestewart's avatar

@jlrdw In all honesty, you've hijacked this guy's thread from the get go; probably best for everyone if you just accept that your take on front end is different from what's now generally accepted, and let people who want to help answer the OP's question get on with it.

jlrdw's avatar

davestewart I had forgotten but MikeHopley asked for a reference. I will forget it again.

MikeHopley's avatar

Ugh, sorry I even asked. :-&

Back on topic:

My challenge is to pick one that would get me the most benefits in terms of learning, and maybe a future job (and not what it can do for my app). I lack front-end knowledge and I want to learn more.

There may be a big difference between (1) the framework you will like the most / want to use and (2) the framework that will be best for getting you a job.

From what I hear, Angular is currently the safe bet for your CV. But you might prefer using Vue for your project, and it would probably be much easier to learn.

On balance, I would suggest starting with Vue, because it's easier to pick up. You can always transition to the "big boys" world of Angular later, if you want.

Another thought: you say you "lack front-end knowledge". Can you elaborate on this? There are many skills involved here. How is your CSS? How is your basic javascript? What sort of front-end work have you done so far? For that matter, how confident are you in HTML?

It may be that jumping straight to a reactive javascript framework is not the right next step for you.

1 like
davestewart's avatar

I'd mainly agree with mike, but differ where I think that everyone, especially newbies should get to know a JS framework as soon as possible; the reason being it will force you into a way of working, and help you start writing structured code, where there is no inherent structure.

  • jQuery is arguably the (grand?)daddy of all JS frameworks, so you can't go wrong knowing a bit of that; it's a good all-rounder, with an intuitive, logical API that covers many common tasks (DOM manipulation, styling, event binding, etc).
  • Underscore is not so much a framework, but you'll hear about it - it's essentially a whole host of wicked-useful functions meaning that you rarely need to role your own, fallible, versions of functions that already exist
  • I hadn't heard of Vue before, but (from my limited googling) it sounds like the right framework for you in this case; handling mainly data-binding (which saves you writing A LOT of boilerplate code - a good thing) and some basic DOM manipulation, then you can use your existing PHP skills to build the views, persistence layer, authentication, etc. Not only that but there's what looks like a really good Laracasts series on it, which is a big time saver.

Saying that, if you want to go the SPA (single page architecture) route it also makes sense to learn at least one MVC type JS framework, but you know that as you're looking at some! Backbone certainly used to be the easiest standard one to learn in that sphere, but some of the newer frameworks with databinding do make it look a little clunky (saying that, databinding isn't everything!).

Angular may certainly fry your noodle if you don't know much JS, and there's a LOT of magic in them thar hills, which I never think is a good thing when first learning something, as I think it's important to really understand how the base language works behind the sugar - as JS is in essence, a fairly simple little language, with various limitations, and more than a few quirks. That aside, when combined with the browser, and the DOM in particular, you have a very powerful marriage. Bubbling, binding, traversal, XHR, etc - this is where the frameworks really excel in hiding the complexity from you.

FWIW, jQuery's raison d'etre was to abstract away the different object models, patchyHTML 4.0 and CCS2 implementations, and various other browser limitations / complexities, in a one-size fits all framework, which was a revelation at the time.

If you're interested in knowing a little more how jQuery fits together, check out this interactive exploration of the source code I made a good few years ago now: http://davestewart.io/resources/javascript/deconstructed/jquery/

I'll leave you with this; the one mistake you shouldn't make when learning a JS framework, especially when you're new to JS, is falling into the trap of thinking the framework you're learning is "the one true framework", "the way JS is done", "this is JavaScript" or any of that nonsense. Every time a new framework is invented, it will do a certain amount of things well, and that's all. The beauty of a lot of these (at least the smaller) frameworks is that they will play well together. The larger ones tend to want to do everything themselves which is no nad thing, but again, it's just "one way" of doing things.

Sorry if that's too in-depth for you, but I thought it might be helpful to yourself and maybe others who look at front end code from afar and feel the need to poke it with a stick in case it jumps up and bites them.

1 like
MikeHopley's avatar

I'd mainly agree with mike, but differ where I think that everyone, especially newbies should get to know a JS framework as soon as possible; the reason being it will force you into a way of working, and help you start writing structured code, where there is no inherent structure.

That is a good point.

One observation about jQuery: unlike (say) Vue, jQuery doesn't really force you into any good habits. My old jQuery code has almost no structure.

In terms of structuring my javascript, I found Jeffrey's video on Stripe.js helpful.

jQuery is also useful to learn because it's used by many libraries. For example, I use Stripe's jQuery.payment.

cristian9509's avatar

@davestewart & @MikeHopley Thanks for your answers. I had to wait for things to cool down since most of the "info" I got was related to something else :D. Anyway, I did a small project in mostly Vue.js and found it a little lacking documentation. But after many hours of trying to understand this and that I made that small project work.

After that challenge I realized that I might be better of by going to Angular (better for my CV) and since Angular has more documentation (tutorials, etc) I would say that it will be easier to learn. So for the other project that I want to build, I guess Angular is the better choice. My other project which I said it will use extensively javascript, well, that is my decision. I want to learn more of Javascript and learn a new framework and therefore I decided do more frontend. It is my personal project and I can put more focus on backend or frontend. I decided to do more frontend.

Now, I've compared a bit Angular and Vue and found lots of similarities (even in syntax). Would I be wrong in saying that if I learn pretty well Angular I'll be easier to learn Vue afterwards?

Next

Please or to participate in this conversation.