7 ms·

I think the problem with "bloat-free" is it's a fine ideal until you try to solve any kind of reasonably complex problem, and honestly it starts to creep in eve

I think the problem with "bloat-free" is it's a fine ideal until you try to solve any kind of reasonably complex problem, and honestly it starts to creep in even when you're solving something that isn't particularly complex. Here's a concrete example. Your classic node.js or express.js sample app is something fairly simple like a hello world, or an IM server. A more complex sample probably looks something like that venerable nodecellar app from a few years back. In all cases the spiel is, "Hey, look how easy it is to create a web server with node." Except that I'm looking at my node server source right now - for an honestly fairly simple app containing a handful of pages and a blog - and here's what I have: - Routing (obviously) - Cookie and body parsing - Session management - MongoDB integration - Passport.js for authentication with a couple of providers (FB and Twitter) - File system access - HTTPS and SPDY/HTTP2 support - Compression support - Logging with winston and morgan, including loggly integration - Referer spam filtering - Pug templates - Hexo blog integration - Path resolution support - Request validation and redirects - Static content support - Stripping headers such as X-Powered-By, and adding other headers such as the all-important X-Clacks-Overhead - Error handling There's probably a couple of other items I missed, but you get the idea. It seems like a lot but, as far as I'm concerned, this is express.js app MVP for anything you might want to put into production. I haven't even mentioned the gulpfile I use to build all this, which targets desktop, mobile, along with embedded versions for a particular mobile app due to launch in the near future, and has become something of a behemoth[1]. Nor have I mentioned that I have Cloudflare to sit in front of this, primarily to deal with the heavy lifting of some of the media files I serve up. On the face of it, this might feel like "bloat" but it's all necessary to run the application and, like I say, a lot of it is the bare minimum for an MVP web app in node. [1] Yes, I know I could/should switch to webpack, but gulp works, and switching to webpack "just because" doesn't justify itself with the value it might add.

royjacobs 8y ago
It's interesting that you mention gulp and webpack when those tools too are now considered too complex and set to be usurped by something like Brunch. It's a shame these tools keep being rewritten because there are definitely good ideas in all of them, but for some reason they can't seem to be unified.
- Arnavion 8y ago
  All these tools start off as simple alternatives to the existing bloated tools. Then as they gain more and more features to support real-world situations they end up becoming as bloated as the tools they set out to replace.
  - royjacobs 8y ago
    Right. I'd just hope that at some point that cycle ends and people try to fix existing tools instead of replacing everything wholesale with something new that will eventually fail again.
    - Moru 8y ago
      Sorry, there is always a new developer thinking "I can do this much better if I just start from scratch, getting rid of all the bloat".
  - mediumdeviation 8y ago
    Webpack and Gulp were never meant to be simpler alternatives. Gulp used streams instead of serially processing files like Grunt, which made it faster, but obviously streams working in parallel are more complex than just processing the files one by one. Webpack pulls dependencies into one file and deduplicates them. This is obviously even more complex since now you have dependency resolution logic as well as dealing with the various module systems JavaScript has invented.
- panopticon 8y ago
  > It's interesting that you mention gulp and webpack when those tools too are now considered too complex and set to be usurped by something like Brunch. While Webpack is a little dense, it appears to strike the right balance between complexity and customizability (and probably more important for longevity, library buy-in). It doesn't seem like anything on the horizon is going to unseat it anytime soon... certainly not Brunch.
  - 8y ago
mikekchar 8y ago
IMHO, the point of using a no-frills library/framework is because you want you write the rest of it yourself. The advantage of this is that it meets your requirements exactly and is therefore smaller/less complex. When doing a project that takes only a few weeks, I would probably choose a framework that has everything in the box. But if you are building something that is going to be developed over a period of years, the reduction in complexity achieved by building your own can be life saving. When I look at your list, most of the things fall into the categories of "Pretty easy to implement" or "Don't want at all". However, there is an advantage for not reinventing the wheel if there is no reason to do so. If there is a nice library that gives me what I want and doesn't impose itself too much on the design, I will use it. But the main advantage for not baking it into a big framework is that I can pick and choose what I want. As an older programmer, I come from an era where libraries and frameworks cost a lot of money. We built stuff by hand because there were not a lot of other choices. These days, though, virtually every library and framework is free software (not only free of charge, but you get source code too!) It's like living in Candy Land, and I'm not about to complain about it :-) However, I think that programmers today reach too quickly for the pre-built and do not understand the long term advantages of bespoke development. Like most things, there is a balance to be maintained.
- deleted 8y ago
  [deleted]
- pknopf 8y ago
  The gist, every dependency you bring in your app should be thought about, really hard. If your using 10% of the lib, just implement it yourself. If the lib is critical, like openssl, bring it in. Other people have solved the hard problems for you. But yeah, it's a balance.
  - fnordsensei 8y ago
    Unless you're using something that has competent dead code elimination, like Google Closure Compiler. Then you can go ahead and include 30mb of libs, knowing that only a fraction will actually be shipped in the production version.
p2t2p 8y ago
This why I love Java so much. Take a look at what Spring Boot does for me: - Routing is done in two lines of code: @Controller @RequestMapping("/myroute") - Cookie and body parsing - no need to write any code to do that, I just have method parameters and all of the data flies in. Whant a validation? Only one keyword on a method parameter - @Valid. Custom validators are supported as well. - Session management. It just here for me and does the right thing by default. I can replace storages with custom implementations but by default no code is required from me. - MongoDB integration - Spring Data MongoDB and you only need to define interfaces using naming convention. The code to access the actual database is generated for you. - Spring Security supports multiple authentication mechanisms and gives you neat DSL to configure it. - File system access kind obvious thing. - HTTPS and HTTP2 support provided by Spring MVC as well. - Compressions support - it just "server.compression.enabled=true" in your config - Logging - slf4j + logback come with Spring Boot and there plenty custom appenders available to put you logs into logstash/splunk whatever - Referrer spam filter - not sure about that one but CSRF protection comes OOB and enabled by default. - Multiple tightly integrated template engines to chose from. Zero configuration code as well. - Static content comes OOB and enabled by default, just put your stuff into resources/static. I mean yeah, modern webapp is a complicated thing! So whenever I see somebody trying to do anything "not bloated" it means that I end up writing low level code that has been written multiple times again and again. The other day I was trying to code a simple thing in Clojure because I love Lisp. Well, it's just embarrassing. I got to simple page showing stuff from Postgres and the boilerplate/business code ratio was at about 70%. Manually configure connection pool, manually start it, manually prepare your component systems, manually mention all of the dependencies for components, manually configure template engine, manually enable static resources support in ring, manually configure and enable session support in ring. Then we come to authentication and don't even try to sell me Friend. EVERYTHING is manual. The only good thing was "environ" which did the right thing but again with "bloated" Spring Boot it comes OOB and I don't need to configure it! If you don't use something "bloated" it only means that you're writing code yourself, again and again.
- i_made_a_booboo 8y ago
  I'm switching to Rails after doing years of Spring Boot apps. The bloat of Java is 3x to 5x.
i_made_a_booboo 8y ago
Nevermind the additional complexity of integrating with payment gateways and handling complex authorization requirements and team invitations etc. Even a 'simple' web app is a convoluted mess of shit if you are to run a real world production grade system. I'm so sick of all these 'hello world' toy examples.

royjacobs 8y ago

It's interesting that you mention gulp and webpack when those tools too are now considered too complex and set to be usurped by something like Brunch. It's a shame these tools keep being rewritten because there are definitely good ideas in all of them, but for some reason they can't seem to be unified.

Arnavion 8y ago
All these tools start off as simple alternatives to the existing bloated tools. Then as they gain more and more features to support real-world situations they end up becoming as bloated as the tools they set out to replace.
- royjacobs 8y ago
  Right. I'd just hope that at some point that cycle ends and people try to fix existing tools instead of replacing everything wholesale with something new that will eventually fail again.
  - Moru 8y ago
    Sorry, there is always a new developer thinking "I can do this much better if I just start from scratch, getting rid of all the bloat".
- mediumdeviation 8y ago
  Webpack and Gulp were never meant to be simpler alternatives. Gulp used streams instead of serially processing files like Grunt, which made it faster, but obviously streams working in parallel are more complex than just processing the files one by one. Webpack pulls dependencies into one file and deduplicates them. This is obviously even more complex since now you have dependency resolution logic as well as dealing with the various module systems JavaScript has invented.
panopticon 8y ago
> It's interesting that you mention gulp and webpack when those tools too are now considered too complex and set to be usurped by something like Brunch. While Webpack is a little dense, it appears to strike the right balance between complexity and customizability (and probably more important for longevity, library buy-in). It doesn't seem like anything on the horizon is going to unseat it anytime soon... certainly not Brunch.
- 8y ago

mikekchar 8y ago

IMHO, the point of using a no-frills library/framework is because you want you write the rest of it yourself. The advantage of this is that it meets your requirements exactly and is therefore smaller/less complex. When doing a project that takes only a few weeks, I would probably choose a framework that has everything in the box. But if you are building something that is going to be developed over a period of years, the reduction in complexity achieved by building your own can be life saving. When I look at your list, most of the things fall into the categories of "Pretty easy to implement" or "Don't want at all". However, there is an advantage for not reinventing the wheel if there is no reason to do so. If there is a nice library that gives me what I want and doesn't impose itself too much on the design, I will use it. But the main advantage for not baking it into a big framework is that I can pick and choose what I want. As an older programmer, I come from an era where libraries and frameworks cost a lot of money. We built stuff by hand because there were not a lot of other choices. These days, though, virtually every library and framework is free software (not only free of charge, but you get source code too!) It's like living in Candy Land, and I'm not about to complain about it :-) However, I think that programmers today reach too quickly for the pre-built and do not understand the long term advantages of bespoke development. Like most things, there is a balance to be maintained.

deleted 8y ago
[deleted]
pknopf 8y ago
The gist, every dependency you bring in your app should be thought about, really hard. If your using 10% of the lib, just implement it yourself. If the lib is critical, like openssl, bring it in. Other people have solved the hard problems for you. But yeah, it's a balance.
- fnordsensei 8y ago
  Unless you're using something that has competent dead code elimination, like Google Closure Compiler. Then you can go ahead and include 30mb of libs, knowing that only a fraction will actually be shipped in the production version.

p2t2p 8y ago

This why I love Java so much. Take a look at what Spring Boot does for me: - Routing is done in two lines of code: @Controller @RequestMapping("/myroute") - Cookie and body parsing - no need to write any code to do that, I just have method parameters and all of the data flies in. Whant a validation? Only one keyword on a method parameter - @Valid. Custom validators are supported as well. - Session management. It just here for me and does the right thing by default. I can replace storages with custom implementations but by default no code is required from me. - MongoDB integration - Spring Data MongoDB and you only need to define interfaces using naming convention. The code to access the actual database is generated for you. - Spring Security supports multiple authentication mechanisms and gives you neat DSL to configure it. - File system access kind obvious thing. - HTTPS and HTTP2 support provided by Spring MVC as well. - Compressions support - it just "server.compression.enabled=true" in your config - Logging - slf4j + logback come with Spring Boot and there plenty custom appenders available to put you logs into logstash/splunk whatever - Referrer spam filter - not sure about that one but CSRF protection comes OOB and enabled by default. - Multiple tightly integrated template engines to chose from. Zero configuration code as well. - Static content comes OOB and enabled by default, just put your stuff into resources/static. I mean yeah, modern webapp is a complicated thing! So whenever I see somebody trying to do anything "not bloated" it means that I end up writing low level code that has been written multiple times again and again. The other day I was trying to code a simple thing in Clojure because I love Lisp. Well, it's just embarrassing. I got to simple page showing stuff from Postgres and the boilerplate/business code ratio was at about 70%. Manually configure connection pool, manually start it, manually prepare your component systems, manually mention all of the dependencies for components, manually configure template engine, manually enable static resources support in ring, manually configure and enable session support in ring. Then we come to authentication and don't even try to sell me Friend. EVERYTHING is manual. The only good thing was "environ" which did the right thing but again with "bloated" Spring Boot it comes OOB and I don't need to configure it! If you don't use something "bloated" it only means that you're writing code yourself, again and again.

i_made_a_booboo 8y ago
I'm switching to Rails after doing years of Spring Boot apps. The bloat of Java is 3x to 5x.

i_made_a_booboo 8y ago

Nevermind the additional complexity of integrating with payment gateways and handling complex authorization requirements and team invitations etc. Even a 'simple' web app is a convoluted mess of shit if you are to run a real world production grade system. I'm so sick of all these 'hello world' toy examples.