4 ms·

I'm in an enterprise and have successfully lobbied people to use anything other than Spring. Such organizations and teams while rare do exist so don't give up h

by bedobi 5y ago

I'm in an enterprise and have successfully lobbied people to use anything other than Spring. Such organizations and teams while rare do exist so don't give up hope! (or just move to a more progressive org)

heurisko 5y ago
> I'm in an enterprise and have successfully lobbied people to use anything other than Spring. I was in a team that used Spring Boot for a greenfield project. The documentation was great, there was tons of help of Stackoverflow (as it's Spring) and the consideration given to testing was first class. Deployment was also easy, as we just created a fat JAR. No application server necessary. It was a great place to work.
- bedobi 5y ago
  I have also been in multiple organizations where Spring was used, including "modern" Spring Boot and greenfield projects, and people who knew every nook and cranny of Spring. I don't agree with any of the things you bring up. Spring documentation is and has always been poor and the sheer volume of outdated documentation (let alone ways to do the same thing) makes it needlessly difficult to find an answer to any given question. Differences between the real app and real http requests to the app, and using the Spring test application context and Spring HTTP tests, result in tests misleadingly passing when things are actually broken. (or vice versa) This is different to eg DropWizard where you actually boot the app (no different to how it does in a real env ie no "test application context") and make real http requests to it. (not some watered down fake Spring HTTP test requests) Ability to deploy a standalone jar without the need for an application server is hardly unique to Spring. Add in the horribly, horribly ingrained, unidiomatic ways people use Spring (eg sprinkling field autowiring all over the place instead of instead of using constructor injection) etc etc and every codebase is quickly completely ruined vs if it had been implemented in literally any other framework. But! Fortunately for you, the Java community has made their choice, and it's not going to change - Spring is the default and correct option, and anyone who uses any other framework is just stubborn and wrong.
  - heurisko 5y ago
    > Spring documentation is and has always been poor and the sheer volume of outdated documentation Spring documentation is excellent. I had to learn Spring as a PHP developer, so I put the documentation onto a Kindle and read it. It's also versioned, so you don't need to read out of date versions: https://docs.spring.io/spring-framework/docs/ https://docs.spring.io/spring-framework/docs/ > This is different to eg DropWizard where you actually boot the app (no different to how it does in a real env ie no "test application context") and make real http requests to it. (not some watered down fake Spring HTTP test requests) Spring Boot allows you to write full application tests that will boot it up on a random port with the @SpringBootTest annotation, as is covered by the excellent documentation https://spring.io/guides/gs/testing-web/ https://spring.io/guides/gs/testing-web/ > Add in the horribly, horribly ingrained, unidiomatic ways people use Spring (eg sprinkling field autowiring all over the place instead of instead of using constructor injection) You can use whichever. > anyone who uses any other framework is just stubborn and wrong. Not at all. Spring Boot is just a great solution, that's all. It's got strong support from a company, lots of documentation and first class support for testing. It also allows you to easily swap out different underlying technology, eg. you can switch from Jetty or Tomcat, Liquibase to Flyway. It's a disservice to persuade businesses to use smaller projects that don't have a comparable level of support, or flexibility.
    - stepbeek 5y ago
      > It's a disservice to persuade businesses to use smaller projects that don't have a comparable level of support, or flexibility. This is why we use Spring. We have confidence that it'll be supported long-term and will continue to have backing from a whole host of companies. It's slightly different in a large enterprise environment where a service might be fairly straighforward - take in input, spit out output to some data store. But for the kind of work we do - end-to-end webapps - we'd be doing ourt clients a great disservice to sell them on a microframework with our homespun implementations of security, transactions etc. bolted on top.
      - heurisko 5y ago
        > we'd be doing ourt clients a great disservice to sell them on a microframework with our homespun implementations of security, transactions etc. One of the benefits of Spring Boot was that Pivotal test and ensure all the components work together, so you can upgrade safely. It made keeping things up-to-date much easier. There's no business value in trying to knit it all together yourself, if you can pass the work onto somebody else who is paid to do it.

by bedobi 5y ago

heurisko 5y ago

> I'm in an enterprise and have successfully lobbied people to use anything other than Spring. I was in a team that used Spring Boot for a greenfield project. The documentation was great, there was tons of help of Stackoverflow (as it's Spring) and the consideration given to testing was first class. Deployment was also easy, as we just created a fat JAR. No application server necessary. It was a great place to work.

bedobi 5y ago
I have also been in multiple organizations where Spring was used, including "modern" Spring Boot and greenfield projects, and people who knew every nook and cranny of Spring. I don't agree with any of the things you bring up. Spring documentation is and has always been poor and the sheer volume of outdated documentation (let alone ways to do the same thing) makes it needlessly difficult to find an answer to any given question. Differences between the real app and real http requests to the app, and using the Spring test application context and Spring HTTP tests, result in tests misleadingly passing when things are actually broken. (or vice versa) This is different to eg DropWizard where you actually boot the app (no different to how it does in a real env ie no "test application context") and make real http requests to it. (not some watered down fake Spring HTTP test requests) Ability to deploy a standalone jar without the need for an application server is hardly unique to Spring. Add in the horribly, horribly ingrained, unidiomatic ways people use Spring (eg sprinkling field autowiring all over the place instead of instead of using constructor injection) etc etc and every codebase is quickly completely ruined vs if it had been implemented in literally any other framework. But! Fortunately for you, the Java community has made their choice, and it's not going to change - Spring is the default and correct option, and anyone who uses any other framework is just stubborn and wrong.
- heurisko 5y ago
  > Spring documentation is and has always been poor and the sheer volume of outdated documentation Spring documentation is excellent. I had to learn Spring as a PHP developer, so I put the documentation onto a Kindle and read it. It's also versioned, so you don't need to read out of date versions: https://docs.spring.io/spring-framework/docs/ https://docs.spring.io/spring-framework/docs/ > This is different to eg DropWizard where you actually boot the app (no different to how it does in a real env ie no "test application context") and make real http requests to it. (not some watered down fake Spring HTTP test requests) Spring Boot allows you to write full application tests that will boot it up on a random port with the @SpringBootTest annotation, as is covered by the excellent documentation https://spring.io/guides/gs/testing-web/ https://spring.io/guides/gs/testing-web/ > Add in the horribly, horribly ingrained, unidiomatic ways people use Spring (eg sprinkling field autowiring all over the place instead of instead of using constructor injection) You can use whichever. > anyone who uses any other framework is just stubborn and wrong. Not at all. Spring Boot is just a great solution, that's all. It's got strong support from a company, lots of documentation and first class support for testing. It also allows you to easily swap out different underlying technology, eg. you can switch from Jetty or Tomcat, Liquibase to Flyway. It's a disservice to persuade businesses to use smaller projects that don't have a comparable level of support, or flexibility.
  - stepbeek 5y ago
    > It's a disservice to persuade businesses to use smaller projects that don't have a comparable level of support, or flexibility. This is why we use Spring. We have confidence that it'll be supported long-term and will continue to have backing from a whole host of companies. It's slightly different in a large enterprise environment where a service might be fairly straighforward - take in input, spit out output to some data store. But for the kind of work we do - end-to-end webapps - we'd be doing ourt clients a great disservice to sell them on a microframework with our homespun implementations of security, transactions etc. bolted on top.
    - heurisko 5y ago
      > we'd be doing ourt clients a great disservice to sell them on a microframework with our homespun implementations of security, transactions etc. One of the benefits of Spring Boot was that Pivotal test and ensure all the components work together, so you can upgrade safely. It made keeping things up-to-date much easier. There's no business value in trying to knit it all together yourself, if you can pass the work onto somebody else who is paid to do it.