Hacker News Reader

Comment by unscaled | Hacker News Reader

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/

View on HN

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.

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.

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?

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.

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.

> Just now I embedded an amqp client into my app.

I have no need for one of those, I'm good building some fairly simple microservices against spark without 'lazy client initialization' or any framework features.

That's kinda the point, it's a simpler toolset for a single purpose. You may have requirements that are made simpler for you by knowing the arcane ins and outs of a feature-rich framework.

Not everyone does, and bringing in said framework to achieve something simple in the name of "Maybe, in future, I may need this" is a prime route to an overcomplex, heavyweight mess. IMHO.

Maybe you've avoided Spring-related hell, but all the java devs I know who survived that era tend to groan whenever it's mentioned.

Nothing precludes you from using Guice or Koin for dependency injection with any framework. Yes, any DI framework would require you to understand some new syntax, but Spring again comes as more magical and mysterious, and the abstractions are always leaky. For instance, when using its magical scopes, it will create proxy instances without you using its magical request scope, bytecode-gen magic (cglib) or plain reflection (which is bound to be just amazing for performance).

This behavior which looks helpful at first glance, is very confusing. If your not proficient with Spring or spend hours reading the documentation you'll never understand that: 1. Your object lifetime is tied to the request. 2. The instance you see at the debugger is actually a subclass that redirects all call to the actual scoped object instance depending on a thread local variable (I guess?) 3. The proxy instance is either slow (JDK Proxy) or could cause you grief when you upgrade to the next version of Java (CGLIB). It's not clear which is which without some investigating.

I rather prefer to go with a lightweight framework + a sane DI framework and do something more explicit, e.g. create a RequestProvider<T> interface:

    interface RequestProvider<T> { 
      get(request: Request): T
    }

    class MyController() {
      val fooProvider: RequestProvider<Foo> by inject(name = "foo")

      fun myHandler(request: Request) {
          val requestScopedFoo = fooProvider.get(request)
      }
    }

This approach is more explicit, but I prefer it.

I don't get all this about Spring being an "insane" way to do DI. It works well enough, and Pivotal is very thorough with their documentation. I would much rather RTFM than dig randomly through the code and hope I find what I'm looking for.

How exactly does Guice differ in request- or session-scoped injections that makes it that much better?

Reply on news.ycombinator.com