5 ms·

That's a nice try, but the rest of the app would be[1]: import static spark.Spark.get; public class HelloWorld { public static void main(Strin

That's a nice try, but the rest of the app would be[1]: import static spark.Spark.get; public class HelloWorld { public static void main(String[] args) { get("/hello", (req, res) -> "Hello World"); } } [1] http://sparkjava.com/ http://sparkjava.com/

nurettin 7y ago
It is indeed a nice try, and the rest of the app would be: @SpringBootApplication @RestController class DemoApplication{ @GetMapping("/hello") fun hello() = "Hello, World!" } fun main(args: Array<String>) { runApplication<DemoApplication>(*args) } And this taught me that the best sinatra clone in java isn't really worth it in terms of lines of code saved (we save what? 3 lines of code? 6 with the imports?) when compared to a full-blown web framework like spring boot. Would you care to do another one where we return a json response? I'd bet you will need a json mapper class for complex objects whereas I will return a dataclass instance and it will just work.
- unscaled 7y ago
  In Kotlin, so you don't have to define multiple files, obviously skipping the imports. Let's do the same with Jooby, for instance: fun main(args: Array<String>) = run(*args) { get { "Hello Kotlin" } } It's always easy to make a framework lightweight. But there is no argument that Spring requires a lot of tedious boilerplate in Java (some of which can be avoided with Kotlin), and annotations which are hard to understand. Lightweight frameworks don't really tell you "We do everything that Spring does in less lines", since at one point you'll ask them to make avocado toasts or something else that spring-bakery has a plugin for. The real power of lightweight frameworks is their simplicity. This is not for everyone (that's why we've got Spring and Rails), but if everybody was fine with the tradeoffs that Spring makes, you'll see the same kind of frameworks ruling the Node.js and Go landscape.
  - nurettin 7y ago
    I understand, and I used to be in the sinatra camp a decade ago. What I really disliked with spring/tapestry and rails was the (at the time) huge stack trace and memory usage. The annotations I used were "this is a spring boot application" on top of a class and another which says "this is a rest controller" to start your hello world application and we only saved a few lines and introduced additional hidden complexity with sparkjava because we still don't have a way to handle json whereas it comes free with spring boot. You've got another one that says "this is an injectable service" and another which says "this is a db entity" and with the "this is a configuration" you've got 99% of spring boot applications covered. Not sure what is so hard about the annotations. Maybe it has to do with "knowing more than just java/kotlin syntax" that puts people off?
    - Nursie 7y ago
      I don't want to have to learn a brand new syntax to get things done. Your Spring example immediately turns me off because it uses a bunch of annotations that could do pretty much anything (and I'd have to learn). Further, it uses kotlin which is not java - it's a valid choice but it's a more terse language in general (so not necessarily valid to compare against java examples). Spark is straightforward and easy to read, it does one thing and it does it well, and it doesn't demand that I spend a lot of time thinking about anything other than what I'm trying to achieve. I have a lot of time for that. For the record, with kotlin and skipping imports (of which there would only be one anyway) - fun main(args: Array<String>) { get("/hello") { req, res -> "Hello World" } } I do indeed find this simpler than your proposal upthread.
      - nurettin 7y ago
        Just now I embedded an amqp client into my app. To do that, I had to create a configuration class that instantiates necessary queues, exchanges and binds them to eachother using builder syntax and beans. The spring boot app lazily handles rmq client initialization and I didn't have to think of object lifetimes. That kinda sorta simplified my job. However, your point still stands, I had to learn new syntax (I learned to type @Bean) to do all this.

nurettin 7y ago

It is indeed a nice try, and the rest of the app would be: @SpringBootApplication @RestController class DemoApplication{ @GetMapping("/hello") fun hello() = "Hello, World!" } fun main(args: Array<String>) { runApplication<DemoApplication>(*args) } And this taught me that the best sinatra clone in java isn't really worth it in terms of lines of code saved (we save what? 3 lines of code? 6 with the imports?) when compared to a full-blown web framework like spring boot. Would you care to do another one where we return a json response? I'd bet you will need a json mapper class for complex objects whereas I will return a dataclass instance and it will just work.

unscaled 7y ago
In Kotlin, so you don't have to define multiple files, obviously skipping the imports. Let's do the same with Jooby, for instance: fun main(args: Array<String>) = run(*args) { get { "Hello Kotlin" } } It's always easy to make a framework lightweight. But there is no argument that Spring requires a lot of tedious boilerplate in Java (some of which can be avoided with Kotlin), and annotations which are hard to understand. Lightweight frameworks don't really tell you "We do everything that Spring does in less lines", since at one point you'll ask them to make avocado toasts or something else that spring-bakery has a plugin for. The real power of lightweight frameworks is their simplicity. This is not for everyone (that's why we've got Spring and Rails), but if everybody was fine with the tradeoffs that Spring makes, you'll see the same kind of frameworks ruling the Node.js and Go landscape.
- nurettin 7y ago
  I understand, and I used to be in the sinatra camp a decade ago. What I really disliked with spring/tapestry and rails was the (at the time) huge stack trace and memory usage. The annotations I used were "this is a spring boot application" on top of a class and another which says "this is a rest controller" to start your hello world application and we only saved a few lines and introduced additional hidden complexity with sparkjava because we still don't have a way to handle json whereas it comes free with spring boot. You've got another one that says "this is an injectable service" and another which says "this is a db entity" and with the "this is a configuration" you've got 99% of spring boot applications covered. Not sure what is so hard about the annotations. Maybe it has to do with "knowing more than just java/kotlin syntax" that puts people off?
  - Nursie 7y ago
    I don't want to have to learn a brand new syntax to get things done. Your Spring example immediately turns me off because it uses a bunch of annotations that could do pretty much anything (and I'd have to learn). Further, it uses kotlin which is not java - it's a valid choice but it's a more terse language in general (so not necessarily valid to compare against java examples). Spark is straightforward and easy to read, it does one thing and it does it well, and it doesn't demand that I spend a lot of time thinking about anything other than what I'm trying to achieve. I have a lot of time for that. For the record, with kotlin and skipping imports (of which there would only be one anyway) - fun main(args: Array<String>) { get("/hello") { req, res -> "Hello World" } } I do indeed find this simpler than your proposal upthread.
    - nurettin 7y ago
      Just now I embedded an amqp client into my app. To do that, I had to create a configuration class that instantiates necessary queues, exchanges and binds them to eachother using builder syntax and beans. The spring boot app lazily handles rmq client initialization and I didn't have to think of object lifetimes. That kinda sorta simplified my job. However, your point still stands, I had to learn new syntax (I learned to type @Bean) to do all this.