jetty and tomcat are both called application servers. But jetty provides two ways to start. One is embedded, which is to start a jetty by writing code yourself. Another deployment method, which is the same as tomcat, deploys a war package into jetty. Because of embedded deployment, the flexibility is better. Your code deployment does not need to rely on operation and maintenance to deploy a tomcat in each environment. To put it simply, there is one more method, giving developers more choices. Of course, jetty came out later than tomcat, so in terms of performance and architecture implementation, it is relatively better than tomcat.
As for the solution mentioned in your question, it just uses some new technologies (nodejs) to completely separate the front and back ends, which may be more efficient in development.
I don’t know whether the long connection you are talking about is WebSocket, Comet or HTTP Keep-Alive. Both Jetty and Tomcat support all three. In terms of performance: WebSocket and HTTP Keep-Alive are industry standards, and there will not be much performance difference between the two; Comet, the APIs of Jetty and Tomcat are different, because there is no unified standard in the industry, but the performance is personal I don't think there will be much difference, because both support NIO.
As for the choice between the two, it may be more a matter of personal habits (for example, I personally like Jetty), or company regulations or something.
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Used during development because it starts up quickly
A bit off topic
jetty and tomcat are both called application servers. But jetty provides two ways to start.
One is embedded, which is to start a jetty by writing code yourself.
Another deployment method, which is the same as tomcat, deploys a war package into jetty.
Because of embedded deployment, the flexibility is better. Your code deployment does not need to rely on operation and maintenance to deploy a tomcat in each environment.
To put it simply, there is one more method, giving developers more choices.
Of course, jetty came out later than tomcat, so in terms of performance and architecture implementation, it is relatively better than tomcat.
As for the solution mentioned in your question, it just uses some new technologies (nodejs) to completely separate the front and back ends, which may be more efficient in development.
I don’t know whether the long connection you are talking about is WebSocket, Comet or HTTP Keep-Alive. Both Jetty and Tomcat support all three. In terms of performance:
WebSocket and HTTP Keep-Alive are industry standards, and there will not be much performance difference between the two;
Comet, the APIs of Jetty and Tomcat are different, because there is no unified standard in the industry, but the performance is personal I don't think there will be much difference, because both support NIO.
As for the choice between the two, it may be more a matter of personal habits (for example, I personally like Jetty), or company regulations or something.