Frontend Devs Can Learn Java Fast by Mapping It to What They Already Know

Hello everyone, I'm Shuangyue. Author of wangEditor, former senior frontend engineer at Baidu and Didi, elite instructor at IMOOC, PMP, and author of Frontend Interview Pro.

I am currently focused on the development and upgrade of two projects. If you're interested, feel free to DM me to join the project team.

• Zhiyu takes you from 0 to developing an AI Agent, released live, just like openclaw.
• Huashui AI transitions you from frontend to full-stack, developing a complex, high-difficulty, full-process full-stack project from scratch, released live.

This article shares some of my experiences and feelings learning Java and Spring Boot from the perspective of a frontend developer.

Getting Started

After the [Zhiyu] project was released some time ago, I rested for two days and then started watching tutorials on Java and Spring Boot. I spent 2-3 days developing a demo and deployed it to my server using Docker.

I studied Java in university, and for the first two years after graduation, I wrote code in C#, which is very similar to Java. Later, I switched to frontend development, but I've always written Node.js server-side projects. I've never been a pure frontend developer; I'm a full-stack developer, which is why I could learn and practice Java and Spring Boot so quickly.

In the second half of this year, I plan to fully dive into Java full-stack development and release a complete tutorial series, learning Java full-stack development from a frontend perspective (not from zero), guiding students to become true web full-stack engineers.

At the same time, I also plan to refactor Huashui AI using Java + Vue3. This is my style: no PPTs, no demos, just real, live projects that you can actually use and experience.

The "True Full-Stack" Era

In the spring of 2023, someone first mentioned "the frontend is dead." Although it didn't die then, something did change: people started paying attention to the full-stack direction.

In the spring of 2024, shortly after I released Huashui AI, many students quickly joined in because everyone felt the era of full-stack was coming and that a pure frontend role had no future.

However, back then it was still mainly frontend, with Node.js extending server-side capabilities. Full-stack was an add-on skill for frontend developers, a bonus point.

But two years later, things are completely different. Whether due to the macro environment or the popularization of AI programming, the living space for frontend has almost disappeared.

Previously it was frontend + Node; now you need to do "true full-stack." In China, Java is the most mainstream web server-side technology stack.

Of course, frontend developers learning Java isn't about competing with Java specialists. Java is also very competitive, and those people have years of experience. How could you compete with them after just two months of study? You can't. Frontend developers learning Java is about transforming into full-stack developers who can handle both frontend and backend, one person doing two roles.

The Language

Java might be the easiest programming language to understand.

Java was born as an object-oriented language, and its design is relatively complete. JS, on the other hand, started as a simple script and only gradually gained standards and TypeScript syntax as the internet evolved.

So JS wasn't designed comprehensively from the start, leading to a constant patching-up process later.

For example, for handling asynchronous operations, Java has been multi-threaded from the beginning, allowing the creation of multiple threads, which is easy to understand. JS initially only had setTimeout. Later, with the internet's development, Ajax was designed. Then, because the syntax was complex, Promises were designed. Later still, because it was still complex, async/await was designed...

If you are a programming beginner, you might find Java easier than JS. So if you can learn JS, Java is definitely no problem. Moreover, JS referenced Java's syntax; about 90% of the syntax is written the same way.

Additionally, with AI programming now widespread, you don't need to focus on syntax details at all. You just need to understand the code structure and execution logic.

Server-Side Mindset

The biggest obstacle for a pure frontend developer transitioning to full-stack isn't the language, frameworks, or tools—it's the server-side mindset.

Frontend development deals with pages, the client-side, which loads and runs in the customer's browser. Each customer has their own exclusive copy of the program.

Web page data structure design only needs to consider one person's data, which generally isn't much. As for "loading 100,000 records at once" on the network... that's just an interview question; such scenarios rarely exist in real work.

You generally don't need to worry about web page loading speed yourself. Static resources are on a CDN and won't be too slow. If an API is slow, you just go find the backend developer. As for page rendering lag or memory leaks, you might not encounter them twice a year.

Web pages all run in the browser environment. Getting data and submitting data is all done through backend APIs. Where does the data you get come from? Where does the data you submit go? You don't know, and it's none of your business.

The server side is different. It has to handle all user traffic and data. What do you do when traffic is high? What do you do when data is large? What do you do if an error occurs? This way of thinking is completely different from the frontend.

Therefore, pure frontend developers have significant limitations in their technical vision and product workflow. The server-side mindset is about breaking through these limitations and viewing projects with a full-stack, full-process perspective.

The Spring Framework

The design and ecosystem of Java's Spring framework is probably the most suitable framework for web development in the world, and it's widely adopted in China.

In the past few days of learning Spring, I've found that developing web server-side applications with it is incredibly simple. You just need to follow its designed conventions. Everything you can think of, it has; everything you can't think of, it also has.

However, if you jump straight into learning Spring, it might be quite difficult, especially if you're also new to Java—then it's even harder.

I strongly recommend starting with the Nest.js Node.js framework. Note: it's Nest.js, not Next.js—don't mix them up.

Because Nest.js is designed to mimic the Java Spring framework; the two are very similar. And since you're very familiar with JS syntax, you'll definitely learn it quickly.

Spend 1-2 weeks mastering Nest.js, and then when you go to learn Spring, it will feel very familiar. Even if you're just starting with Java, it will be easy to pick up. Sharpening the axe does not delay the woodcutting.

Conversely, if you seek speed and jump straight into learning Java and Spring, you might give up halfway due to the high learning curve.

We're already exhausted from overtime at work every day. When learning on the side, you must find a low-cost path for it to be feasible. Don't get momentarily emotional and pumped up, thinking you can definitely do it, only to have a three-minute passion that quickly fizzles out.

Whether it's Nest.js or Spring, as a server-side framework, it's for developing server-side APIs. As a frontend developer, what you deal with most every day is APIs. What a request outputs, what format, whether a token is needed... this is what you're most familiar with.

So learning Java frameworks from a frontend perspective isn't starting from zero; you already have some foundational knowledge. Through the right learning path, you can pick it up very quickly.

Package Manager

Frontend development uses npm for management, with package.json to record dependencies, or pnpm, yarn, etc., used every day.

Java development uses Maven for management, with pom.xml to record dependencies. The functionality is the same.

Frontend uses npm commands:

npm run dev
npm run build
npm run test

Java uses Maven commands, which serve the same purpose as npm commands:

mvn spring-boot:run
mvn clean package

Learning Java from a frontend perspective allows for many comparisons. Once you have a reference point for comparison, you learn very quickly.

Environment Variables

Frontend uses .env for environment variables to store constants, configurations, keys, etc., but the Spring framework uses the application.properties file for storage.

However, this file is recommended to be committed to GitHub because some configurations are part of the code and need to be shared with the team. Therefore, some secrets cannot be placed in this file and must be stored elsewhere.

In a local development environment, use application-local.properties to store secrets and do not commit it to GitHub.

But when running, you need to add a local identifier so that Spring Boot loads this local file:

mvn spring-boot:run -Dspring-boot.run.profiles=local  

If deploying to a production environment with Docker containerization, use a .env file to store secrets. Docker reads this file and creates them as environment variables, which Spring Boot will use.

Note: Spring Boot does not load .env files in a local development environment, which is different from frontend development.

Actually, if you have a lot of work experience and design experience, and you think about it carefully, Spring Boot's design approach is the most reasonable. .env is inherently an environment variable and should be separated from project configuration, layered apart, not mixed together. Frontend development's direct use of .env is a bit too makeshift.

Database

Frontend development doesn't use databases. A bit of data on a webpage can be stored using localStorage, and the browser's built-in IndexedDB is almost never used.

Backend development requires a database because storing website data and user data is a fundamental capability.

Frontend developers are relatively unfamiliar with databases; they haven't used them or written SQL statements.

For an initial study of databases, such as the most common MySQL relational database, just think of it as several Excel spreadsheets. For example, a user data table is a spreadsheet containing columns like username, password, email, etc., to which many rows can be added.

In the vast majority of development processes, we don't need to hand-write SQL. Using Spring Boot's built-in ORM tools or MyBatis-Plus allows you to perform CRUD operations on data using code APIs, just like you operate data with localStorage. Basic operations can be picked up very quickly.

After mastering the basic functions and practicing them in a project, then advance to: join queries, database optimization, table splitting, and so on.

Caching

Is there caching in frontend development? Lots of it.

For example, <keep-alive> in Vue caches components, useMemo and useCallback in React cache data, and HTTP caching with cache-control for static resources—these are even classic interview questions you've definitely memorized.

The purpose of caching is to avoid repeated creation, use previous results, increase efficiency, and improve user experience.

Server-side caching follows the same principle.

For example, a blog website's homepage needs to fetch a list of popular articles. This doesn't need to be fetched from the database every time, especially when traffic is high; fetching from the database each time would be relatively slow. The best method is to cache the current result and set an expiration time of 5 minutes. Within those 5 minutes, all users will get the result from the cache, making it much faster.

The server side generally uses a Redis server for caching. Redis stores data in memory by default, making reads and writes very fast.

Although the tools used are different, the design approach, the problems solved, and the effects achieved are all the same. You don't need to learn from scratch.

Message Queue

Everyone knows the principle of the browser's Event Loop, right? A classic frontend interview question. The Event Loop is implemented using a message queue. When there are asynchronous tasks, they queue up for execution, managed through a queue.

Furthermore, if you were to develop a multi-file upload system, selecting multiple large files and queuing them for upload to the server, you would also need to use a queue to implement it.

The server side has even more scenarios requiring message queues. For example, after an API request, needing to send a message, send an email, or submit data to another service—these tasks that don't affect the core business flow should all be implemented through a message queue.

Without a message queue, the main task would have to wait for this task to execute, wasting a lot of time. If multiple users are requesting simultaneously, it could get stuck, causing a greater impact.

Server-side message queues can use RabbitMQ, which also has a visualization panel to clearly see the consumption status of tasks.

Not Finished Yet

That's all for today. There's actually a lot more advanced content, which I'll continue to share later. You can follow me first~

• Jenkins automated deployment
• Docker containerized deployment
• Logging, statistics, and alerts
• k8s
• Microservices