Yeah, I'd say so, at least in it's default configuration. I usually see start times of ~20 seconds and it's pretty resource intensive. The default configuration for most of the spring projects feel very batteries included, which is nice (and kinda the point of Spring Boot), but also very heavy. I haven't gotten the chance to play with jigsaw yet in Java 9/10/11, but without it Java just isn't that great for small apps.
But as a self-professed Java hater; Spring, Spring Boot, and the surrounding ecosystem is really nice to work in.
In my first project at Pivotal Labs, I worked on what I believe was the first production system based on Spring Boot. Afterwards I and my peers were asked to give feedback.
I didn't really get the fuss and a lot of our vibe was "why isn't this more like Rails?"
Later I worked on a Spring 3 project. It was a very well-written monolith, all the best practices up to that generation, layers and services and repositories, the whole shebang. Yet various things about it were flatly painful. That's the experience that made me understand why Spring Boot is actually a Really Big Deal.
These days if I am going to write a general consumer-facing app, I'm perfectly happy with Spring Boot, especially if Kotlin is in frame. A lot of Pivotal Labs projects now use Boot+Kotlin as their default starting point and many folks see the virtues.
It's not Rails, it never will be. But on the other hand: It's not Rails, it never will be.
I started on spring 2. I was working concurrently on django, spring 2, and flask. Spring was just painful, we were using xml definitions for alot of stuff. I changed it over to class configuration but still.
I was running a meetup tonight, and going over spring boot on kotlin. It felt so heavy to me. I've had this thought too why not like X.
Spring has a really great ecosystem around it. I sort of look at it like the AWS of web frameworks. It has practically the kitchen sink in it.
I've switched over to Kotlin. While I gravitated more to I think the sinatra style. I went from Spark -> Jooby -> now Ktor/Vert.x. Vert.x is like a breath of fresh air. I have never felt more liberated writing a backend. Combining that with Kotlin multiplatform and ktor for the js clients. Is so dead simple.
The edit-compile-run cycle is relatively slow compared to REPL-capable languages or small codebases in compiled languages. As a developer that's really noticeable and it's the impression we take with us.
But a warm JVM is a thing of beauty.
Hopefully Graal and Substrate will make this a non-issue in the coming years.
I have worked with Java for over a decade for large companies and I can sympathise. Restarting everything to reproduce the case just to see you forgot something very tiny is painful.
That's why my new framework of choice is Clojure (Leiningen, Luminus) on the server and ClojureScript with Reagent and Fighwheel on client side.
The app starts moderately quickly but once it starts I have REPLs to both server and client side and I have reasonably reliable reloading of everything when I edit it. Once it starts I can add services on backend side and then immediately write client side ui to consume them, all without even reloading the page. As soon as I save any file on either client or server side it is automatically reloaded without me having to do anything.
As a developer that worked mostly for companies that really like to build stuff in-house, it was my understanding that startups build on top of frameworks to be scrappy / create the most value per hour of work, and large businesses create their own frameworks / tooling, mainly because they have very specific needs.
Is my understanding wrong? Or, maybe this is mostly a PR thing?
PS: They do mention that they used to make in-house tooling, but then why transition? How is depending on a codebase that you have less control over an option when you have Netflix resources?
> PS: They do mention that they used to make in-house tooling, but then why transition?
Circumstances change. It made sense at the time to roll their own. They feel it doesn't make sense any more. That Netflix is capable of doing the work is not the same as whether it makes economic sense for them to do so. This is just Economics 101 -- gains from trade and the theory of the firm.
My personal favorite is https://vertx.io because it is a little more transparent in how it works and the Rx abstractions are something I was familiar with when I started using it. Not to mention springboot did not offer reactive programming until fairly recently whereas vertx has been reactive from day 1, rxjava or not.
I will take another look at springboot just to see what the fuss is about. I am a bit surprised that netflix did not come up with their own light weight backend framework based on netty.
If I'm a developer whose primary expertise is in Node with a smattering of Laravel and Rails, what should I be expecting if I decide to write an api with Spring Boot and Java? I've been curious for a while (Java performs very well on most benchmarks, and it looks great on a resume), and I've identified Spring Boot and Vertx as the two main web frameworks in Javaland.
14 comments
[ 1.4 ms ] story [ 45.5 ms ] threadBut as a self-professed Java hater; Spring, Spring Boot, and the surrounding ecosystem is really nice to work in.
I didn't really get the fuss and a lot of our vibe was "why isn't this more like Rails?"
Later I worked on a Spring 3 project. It was a very well-written monolith, all the best practices up to that generation, layers and services and repositories, the whole shebang. Yet various things about it were flatly painful. That's the experience that made me understand why Spring Boot is actually a Really Big Deal.
These days if I am going to write a general consumer-facing app, I'm perfectly happy with Spring Boot, especially if Kotlin is in frame. A lot of Pivotal Labs projects now use Boot+Kotlin as their default starting point and many folks see the virtues.
It's not Rails, it never will be. But on the other hand: It's not Rails, it never will be.
I was running a meetup tonight, and going over spring boot on kotlin. It felt so heavy to me. I've had this thought too why not like X.
Spring has a really great ecosystem around it. I sort of look at it like the AWS of web frameworks. It has practically the kitchen sink in it.
I've switched over to Kotlin. While I gravitated more to I think the sinatra style. I went from Spark -> Jooby -> now Ktor/Vert.x. Vert.x is like a breath of fresh air. I have never felt more liberated writing a backend. Combining that with Kotlin multiplatform and ktor for the js clients. Is so dead simple.
But a warm JVM is a thing of beauty.
Hopefully Graal and Substrate will make this a non-issue in the coming years.
But It works better under gradle, and that is a whole nother battle.
That's why my new framework of choice is Clojure (Leiningen, Luminus) on the server and ClojureScript with Reagent and Fighwheel on client side.
The app starts moderately quickly but once it starts I have REPLs to both server and client side and I have reasonably reliable reloading of everything when I edit it. Once it starts I can add services on backend side and then immediately write client side ui to consume them, all without even reloading the page. As soon as I save any file on either client or server side it is automatically reloaded without me having to do anything.
I can even use same code on client/server side.
Have I mentioned it is the same language?
Is my understanding wrong? Or, maybe this is mostly a PR thing?
PS: They do mention that they used to make in-house tooling, but then why transition? How is depending on a codebase that you have less control over an option when you have Netflix resources?
Circumstances change. It made sense at the time to roll their own. They feel it doesn't make sense any more. That Netflix is capable of doing the work is not the same as whether it makes economic sense for them to do so. This is just Economics 101 -- gains from trade and the theory of the firm.
I will take another look at springboot just to see what the fuss is about. I am a bit surprised that netflix did not come up with their own light weight backend framework based on netty.