JSP is rarely used in development nowadays. The reasons can be summarized as follows:
Origin:xiaqo.com
Why not use jsp? In the past, most JavaEE development front-ends used JSP technology, because before the emergence of JSP, programmers basically spliced a page directly through out.print on the Servlet side and returned it. This approach seriously violated the MVC layering principle. The front end would be very difficult to maintain. After the emergence of Jsp technology, this problem has been greatly improved. While extracting the view layer, it also fully ensures the dynamics of the page.
The reason why JSP is less used
1. The underlying principle of JSP is that Servlet runs directly out.print. When accessing JSP for the first time, JSP needs to be compiled into Servlet. class file, slowing down the running speed.
2. JSP can be directly embedded into java scripts to make the page dynamic, but this breaks the idea of layering, affects the overall program structure, and reduces the readability of the JSP page.
3. You can use jstl tags or el expressions instead of Java scripts to increase the readability of the page. However, there are some reflection implementations at the bottom of the el expression, which will reduce the rendering speed of the page.
4. Many excellent template technologies (velocity, freemarker, thymeleaf, etc.) have subsequently appeared. The efficiency of these template technologies is higher than jsp. For enterprises and developers, there are more choices.
5. Nowadays, many companies have begun to adopt a project structure that separates the front and back ends. The back end focuses on concurrency, storage, etc., and the front end is implemented through frameworks such as VUE. JSP can only run in web containers and cannot run on efficient http such as nginx. In terms of service, it was slowly abandoned by the times.
Why should we give up jsp in java web project? Foreplay: Most of the previous projects were Java programmers who were both father and mother, working on front-end (ajax/jquery/js/html/css, etc.) and back-end (java/mysql/Oracle, etc.) .
With the development of the times, many large, medium and small companies have gradually begun to distinguish the boundaries between the front and back ends more and more clearly. Front-end engineers are only responsible for front-end things, and back-end engineers are only responsible for back-end things.
As the saying goes, there are specializations in the arts. If a person knows everything, then he is not good at anything after all. Large and medium-sized companies need professionals, and small companies need generalists. But for personal career development, I suggest they be separated.
If you are just going to eat Java for the rest of your life, don't study CSS, JS, etc. Focus your energy on java, jvm principles, spring principles, mysql locks, transactions, multi-threading, large concurrency, distributed architecture, microservices, and related project management, etc., so that your core competitiveness will become more and more The higher.
As the saying goes, what you put into life will be what life will give you back.
(Full of positive energy: Once you become an elite in an industry, believe me, cars, houses, women, money, and opportunities will all come to you. Don’t worry, really. Just be a Java programmer. Okay, it’s really simple. The more knowledge you have, the more money you will make. Of course, you also need to have a certain amount of emotional intelligence... The stronger your ability, the more value you create than others. The company creates value, and the company gives you various benefits, a win-win situation!)
Once upon a time, our java web projects used several background frameworks, springmvc/struts + spring + spring jdbc/hibernate/mybatis, etc.
Most projects are divided into three layers in the Java backend, the control layer (controller/action), the business layer (service/manage), and the persistence layer (dao).
The control layer is responsible for receiving parameters, calling relevant business layers, encapsulating data, and routing to jsp pages. Then use various tags (jstl/el) or handwritten java (<%=%>) on the jsp page to display the background data.
Right?
Let’s look at this situation first. The requirements have been determined, the code has been written, and the tests have been completed. What next? Is it about to be released?
You need to use maven or eclipse and other tools to package your code into a war package, and then publish this war package to the web container (tomcat/jboss/weblogic/websphere/jetty/resin) in your production environment, right? ?
After publishing, you need to start your web container and start providing services. At this time, you can configure the domain name, dns, etc., and your website can be accessed (assuming you are a website). Let's take a look, are all your front-end and back-end codes in that war package? Including your js, css, pictures, and various third-party libraries, right?
Okay, let’s enter your website domain name (http://www.xxx.com) into the browser. What happens after that? (This question is also an interview question in many companies) Let me just say it, if you don’t have a good foundation, please search for children’s shoes yourself.
The browser routes to your service through IP. After the TCP three-way handshake, it starts accessing your web server through the TCP protocol. After your web server gets the request, it starts to provide services, receives the request, and then returns your response through response. browser.
So let's take a look. Let's first assume that your homepage has 100 pictures and a single-table query. At this time, the user's seemingly one http request is actually not one. When the user visits for the first time, he browses There will be no cache in the server. For your 100 pictures, the browser will request 100 http requests in succession (someone will tell me about the problem of long and short http links, which will not be discussed here). Your web server receives these requests. Both require memory to create sockets for tcp transmission.
Here’s the key point, in this case, your web server will be under great pressure, because all requests in the page are only made to your server. If it’s just one person, what if 10,000 people access it concurrently (let’s not talk about it for now) A web server cluster (here it is a single-instance web server), how many TCP links can your server handle? How much memory does your server have? How many IOs can you withstand? How much memory have you allocated to the web server? Will it be down?
This is why, the larger and medium-sized web applications are, the more they need to be decoupled.
Theoretically, you can put your database + application service + message queue + cache + user uploaded files + logs + etc. on one host, but this is like putting all your eggs in one basket, and there are hidden dangers. Very big.
A normal distributed architecture must be dismantled, including your application server cluster (front and back) + file server cluster + database server cluster + message queue cluster + cache cluster, etc.
Foreplay is too long.
Let's get down to business. First of all, we should try to avoid using jsp in future java web projects, decouple the front and backends, and play with distributed architecture, so that our application architecture will be stronger.
Pain points of using jsp
1. Dynamic resources and static resources are all coupled together, and true separation of dynamic and static cannot be achieved. The server is under great pressure because the server will receive various http requests, such as css http requests, js, pictures, dynamic codes, etc. Once there is a problem with the server, the front and backends will be played together, and the user experience will be extremely poor.
2. After the front-end engineer completes the HTML, a Java engineer needs to modify the HTML into a JSP page. The error rate is high (because a large amount of JS code often appears in the page). When modifying the problem, it requires collaborative development by both parties, which is inefficient.
3. jsp must be run in a web server that supports java (such as tomcat, etc.), and nginx cannot be used (nginx is said to have a single instance of http concurrency of up to 50,000, this advantage must be used), and the performance cannot be improved.
4. The first time you request jsp, it must be compiled into a servlet in the web server. The first run will be slower.
5. Every time you request jsp, you access the servlet and then use the output stream to output the html page, which is not as efficient as using html directly.
6. There are many tags and expressions in jsp. Front-end engineers will be stretched when modifying the page and encounter many pain points.
7. If there is a lot of content in jsp, the page response will be very slow because it is loaded synchronously.
Based on some of the above pain points, we should move the development weight of the entire project forward to achieve true decoupling of the front and back ends!
The old way was:
1. Client request
2. The servlet or controller on the server receives the request (the routing rules are formulated by the backend, and most of the weight of the entire project development is on the backend) 5.jsp displays some dynamic code 4. Return jsp
3. Call service and dao code to complete business logic
The new way is:
1. The browser sends a request
2. Directly reaches the html page (routing rules are formulated by the front end, and the weight of the entire project development is moved forward)
3. The html page is responsible for calling the server interface to generate data (through ajax, etc.)
4. Fill in the html to show dynamic effects.
(Interested children can visit large websites such as Alibaba, and then press F12 to monitor how HTTP works when you refresh the page. Most of them request background data separately and use json to transmit data instead of A large and comprehensive http request returns the entire page including dynamic + static)
The benefits of doing this are:
1. Real front-end and back-end decoupling can be achieved, and the front-end server uses nginx. The front-end server stores a series of static resources such as css, js, pictures, etc. (You can even put css, js, pictures and other resources into a specific file server, such as Alibaba Cloud's oss, and use CDN to accelerate). The front-end server is responsible for Control page references, jumps, and call back-end interfaces. The back-end server uses tomcat.
(You need to use some front-end engineering frameworks such as nodejs, react, router, react, redux, webpack)
2. When a bug is discovered, you can quickly locate the problem, and there will be no chance of kicking each other. Page logic, jump errors, browser compatibility issues, script errors, page styles and other issues are all handled by front-end engineers. Problems such as interface data errors, data not being submitted successfully, response timeouts, etc. are all solved by back-end engineers. The two parties do not interfere with each other, and the front-end and back-end are a family that loves each other.
3. In the case of large concurrency, I can horizontally expand the front-end and back-end servers at the same time. For example, a homepage of Taobao requires 2,000 front-end servers to be clustered to withstand the average daily PV of billions+.
(I went to Alibaba's technology summit and heard that they wrote all their web containers themselves. Even if a single instance can withstand 100,000 http concurrency, 2,000 units can handle 200 million http concurrency, and they can also expand infinitely based on predicted peaks. Very scary, just a homepage...)
4. Reduce the concurrency pressure on the back-end server, and transfer all http requests except the interface to the front-end nginx.
5. Even if the back-end service temporarily times out or is down, the front-end page will still be accessible normally, but the data will not be refreshed.
6. Maybe you also need to have WeChat-related light applications, so that your interfaces can be shared. If there are app-related services, then through some code refactoring, you can reuse a large number of interfaces to improve efficiency.
7. No matter how many things are displayed on the page, you are not afraid because it is loaded asynchronously.
Notice:
1. When holding a requirements meeting, all front-end and back-end engineers must participate, and interface documents need to be formulated. Back-end engineers must write test cases. Do not let front-end engineers act as your team's full-time testers. It is recommended to use the chrome plug-in postman. The test cases for the service layer are written in JUNIT.
2. The above interface is not the interface in java. To put it bluntly, calling the interface means calling the method in your controller.
3. Increases the workload of the front-end team, reduces the workload of the back-end team, and improves performance and scalability.
4. We need some front-end frameworks to solve functions such as page nesting, paging, and page jump control. (Those front-end frameworks mentioned above).
5. If your project is small, or a simple intranet project, then you can rest assured that it does not require any architecture, but if your project is an external network project, hahaha.
6. In the past, some people were using template frameworks such as velocity/freemarker to generate static pages, but now this practice has been eliminated.
7. The main purpose of this article is to say that jsp has been eliminated in large-scale external java web projects, but it does not mean that jsp can not be learned at all. For some students and friends, jsp/servlet and other related java web basics are still required Master it firmly, otherwise what do you think the springmvc framework is based on?