Laravel and Spring Boot are compared in terms of development efficiency. See: Laravel and Spring Boot are compared in terms of development efficiency. This article intends to compare labor costs.

The labor cost mentioned in this paper is the technology expenditure cost in a narrow sense. Of course, the labor cost is not only the labor cost of developers, but also includes the labor (team) cost of team collaboration management, architecture design, operation and maintenance.

This paper analyzes from the following dimensions:

  • The programmer
  • Technical management

The programmer

I believe that this is the dimension that we are more concerned about, it is well understood that it is necessary to polish a set of products according to the demand, whether it is the back end, front end, APP or small program, medium stage, soldiers are to charge forward, that is to rely on programmers to achieve it, so this is just needed.

I believe that many apes will think that they are full stack engineers, back-end OK, front-end OK, APP can also be masturbator, micro channel small program is no problem, there are still many people, but most of them stay in the use of the framework or class library, called “Github engineer”, will have their own more fine one end.

For example, with the front-end Single Page Application, most modern apes can understand JavaScript language. If they are familiar with Vue technology, they can create a decent SPA with Vue Route, Element UI and Vuex. If you’re familiar with React syntax and one-way data flow thinking, Dvajs + Ant Design can also create a gorgeous mid-platform system.

For Android development, familiar with Java syntax, understand the four components of Android, do not need to have a deep understanding of the Android Framework kernel, NDK, as long as the support of great tool libraries, such as Retrofit, EventBus, GreenDao, You can also churn out a native Android APP that looks good. And there is Flutter!

The highly encapsulated nature of modern frameworks increases productivity and makes it easy for developers to lose the need to explore underlying principles, not only for the developers themselves, but also for software companies to compromise technical requirements in order to cut costs in talent selection.

It seems to be an industry rule for big factories to examine underlying principles and algorithms, and to look at project experience in start-up.

But without further ado, let’s get back to finding apes.

Spring Boot ape

  • Java ape, excellent Java ape is difficult to find, with project ideas quickly out of the project of Java program ape is difficult to find
  • J2EE ape, excellent J2EE ape is difficult to find, familiar with J2EE system, proficient in the Spring family barrel ape is even more difficult to find
  • Apes who are proficient in J2EE and can adapt to Spring Boot development thinking are rare

J2EE is very large and complex, the number of knowledge points is no less than a dictionary, Spring Boot configuration mode from the traditional XML definition to Java class injection, now many J2EE monkey is still a tangle like XML configuration file, a look at thousands of lines, looks awesome. In fact, it’s just getting the project up and running. Because of this characteristic of traditional J2EE, Java gives people an impression of slow development and high cost.

Java Web architecture is like the catering industry

J2EE hotel, I saw the customer bare arm into the hotel, and the staff said: I want the red shirt, buttons to hexagonal, shoes to black shoes, eating chopsticks to length of 16cm, wood made, eating chairs to four feet, cushion thickness 1cm, 6 table… In an hour everything is ready for dinner.

There are not many people in the Spring Boot hotel, the usher shouted in the top of his lungs: “Come and have a look, young and old gentlemen, come and have a look.” A customer walked over, the usher immediately welcomed him into the hall to an empty table, the waiter took out the menu, asked: “What do you want to eat?” . The customer was surprised: “I haven’t customized my clothes, chopsticks, chair?” . Waiter: “we are ready, every customer is the same, 16cm chopsticks, four feet chair, 1cm cushion, no need to customize it, you can order meals directly.” The customer paused for a moment and said, “I want a 1.5cm cushion, and the rest is ok.” The waiter said, “Ok.” The customer ordered a donkey meat fire, 15 minutes after satiated and left the store, mumbling: “never go to J2EE hotel, or here convenient.”

So we’re not looking for a Java ape or a J2EE ape, we’re looking for a Spring Boot ape.

price

  • 6K can recruit a Java ape, but you can’t expect him to be in charge of your project on his own, and it takes effort and resources to train him
  • 10K can recruit a Spring Boot ape, J2EE familiar with not know, you guess
  • 15K can recruit a reliable J2EE ape
  • 20K will be lucky to recruit a reliable ape who knows J2EE and can independently develop the backend with the Spring Boot framework

It seems to cost a lot.

Laravel

  • PHP has a lot of monkeys. Wait, let’s filter it out. What? Will Discuz, DeDeCms, empire Cms? Is it possible to develop a project in native PHP? Won’t? Then forget it
  • What is PSR? I don’t know. Uh…
  • Add a global function to this function and you can do it. Such a simple business logic is only more than 100 lines, I have strong logical thinking ability, directly write in the controller method, see how fast I develop. Team member: Uh…
  • “I know ThinkPHP. You said Laravel is as complicated as Java, why don’t you go to Java Ape? There aren’t many Laravel talents in China

price

  • 3k can recruit “CMS PHP ape”
  • 6K can recruit PHP geeks, but you can’t expect him to be solely responsible for your project development, and it takes effort and resources to train him
  • 15K is also able to recruit a reliable Laravel ape, of course, there is a lot of luck, well, the right time and the right person, can not be without both.

Technical management

What? What is technology management? The CTO? What’s a CTO for a small project?

In fact, when starting a project, the software output can not only be an end, at least need the back end and front end, or APP end, small program end.

The role of technical management is to coordinate the interaction and interface specifications of the various ends, as well as the project development milestones and task schedules (note that architecture is not included, which is not considered in the strong need for rapid implementation in the early stage). You can’t have a dedicated back end setting the milestones on the APP side, and you can’t have a dedicated APP client setting the milestones on the back end. It is inevitable that there will be a pivotal person with comprehensive technology, which I think is the basis for the rapid progress of the project. He can also be responsible for testing and code review. Although this is somewhat similar to a product manager, for a startup with a more comprehensive product plan, both can be combined. Due to cost considerations, we need to hire such people at low cost to take charge of the overall technical aspects of the project.

The back end belongs to the end with the highest degree of convergence in the product system, and needs to interact with each end. The lowest cost way is to attach the cost of technology management to the back end, saying: “Find a full stack back end that meets the development requirements described above to undertake the technology management work”.

Personal summary (according to the general level, god level is not included in the discussion) :

  • For full-time backends: Laravel has slightly lower labor costs than Spring Boot
  • For technical management: scripting (PHP, Python, JavaScript) ape tends to be more easy to develop to the full stack, J2EE this enterprise-class framework, the concept of division of labor is very strong, compared with scripting language full stack engineers appear less. And can be competent for J2EE+Spring Boot development, but also full stack ape, start-up or do not consider, too expensive.
  • From PHP ape to find in line with the start-up technology management requirements, the probability is higher than from Java ape to find some, reference objects, bargaining power is naturally higher.
  • Without considering the merits of the system architecture, Laravel has an advantage over Spring Boot in terms of labor costs

One last word about startup software architecture: I’ve seen a lot of startups, and it’s a serious mistake to place too much emphasis on software architecture. As the netizens said, Laravel has performance problems, in order to do big traffic after the service does not hang, clamoring to micro services.

Is the product online yet? Products are not online yet, what high concurrency, what high performance, what micro services.

Startup projects tend to be low-traffic, not computation-intensive services, and the performance bottleneck is not in the PHP framework itself. There’s no point in getting caught up in who is faster C/C++ or JVM, or how many orders of magnitude slower PHP is than C. When you have this performance demand, if the company does not have that capital to pay for talent, that business model is really no one!

There are micro services, a street stall clamoring to follow alibaba’s business model, in fact, there is no problem, you choose the road, you know. Microservices are distributed by nature, and distribution itself is a very large system, not a startup to play with. For example, the multinational operation strategy is suitable for a company with the size of Ali, because the business complexity has reached a certain degree, and the evaluation is beneficial to the company’s short, medium and long-term development. Street stalls using this model, will only be trapped by complexity, of course, when your snack out of the country, to the world, under the thousands of people, the strategic model naturally. When software complexity and project volume reach a certain level, there is a need for service separation and distribution, and microservices will naturally emerge. The initial focus may be on scalability, not microservices.

Talk about high concurrency and architecture under the premise of small flow is playing rogue! You may not want architecture, but extensibility!