4 ms·

Because in the real world of web development applications are hardly ever written directly on top of the server. They are written on a framework, that sits on t

by eudox 11y ago

Because in the real world of web development applications are hardly ever written directly on top of the server. They are written on a framework, that sits on top of an HTTP server abstraction (like Clack), that has pluggable servers. That way, if a new server comes out (e.g. Woo[0]), you don't have to learn all of its internals and rewrite the entire application using it -- you literally just change a keyword argument in a single function call, and now your application is running on a different, much faster server. If someone writes a plugin for Clack (e.g. clack-errors[1]), all applications built on any Clack framework using whatever server can use it. A Hunchentoot plugin works for Hunchentoot applications. Using Clack is sustainable web development. Sure, for a five minute demo, Hunchentoot is fine. But why teach bad practices? [0]: https://github.com/fukamachi/woo https://github.com/fukamachi/woo [1]: https://github.com/eudoxia0/clack-errors https://github.com/eudoxia0/clack-errors

TeMPOraL 11y ago
Why would you even change your server if a new one came out? If your old server works and is maintained, there's no reason for a switch. Also, 'jlg23 has a good point - learning full-stack frameworks as a beginner only serves to confuse things. For the same reason I never advocate that people new to programming jump straight into RoR or Node.js or whatever framework is hot this week - a person needs to understand the problem a tool solves before using the tool; otherwise you're training a code monkey, not a programmer.
- eudox 11y ago
  >Why would you even change your server if a new one came out? Woo is many times faster than Hunchentoot. And projects can die. >a person needs to understand the problem a tool solves before using the tool; otherwise you're training a code monkey, not a programmer. There's a reason we use high-level languages: They hide irrelevant details. You shouldn't have to learn how TCP works or know every detail of HTTP to know what can be done with it.
  - deleted 11y ago
    [deleted]
  - lispm 11y ago
    > Woo is many times faster than Hunchentoot. "Hello World" on the local machine... https://github.com/fukamachi/woo/blob/master/benchmark.md https://github.com/fukamachi/woo/blob/master/benchmark.md is that what you mean by 'faster'? Personally I'd prefer a more representative benchmark, which actually uses the network... Really measuring the qualities of a Web server is a bit more work.
    - eudox 11y ago
      >is that what you mean by 'faster'? Yes.
    - e12e 11y ago
      So, for multi-threaded, it's within a factor of 2. That's not bad. I wonder how much of that is likely to be eaten up in a real-world application. Interesting that woo is so much more performant for the single-threaded case though. But it hardly matters as both support multi-threaded, and both are much faster with multiple threads...
copsarebastards 11y ago
> Because in the real world of web development applications are hardly ever written directly on top of the server. They are written on a framework, that sits on top of an HTTP server abstraction (like Clack), that has pluggable servers. This is only true if you're writing Web 2.0 media websites that are only nominally not static websites. If you are solving an actual hard problem instead of just driving ad traffic, a framework is going to get in your way.

by eudox 11y ago

TeMPOraL 11y ago

Why would you even change your server if a new one came out? If your old server works and is maintained, there's no reason for a switch. Also, 'jlg23 has a good point - learning full-stack frameworks as a beginner only serves to confuse things. For the same reason I never advocate that people new to programming jump straight into RoR or Node.js or whatever framework is hot this week - a person needs to understand the problem a tool solves before using the tool; otherwise you're training a code monkey, not a programmer.

eudox 11y ago
>Why would you even change your server if a new one came out? Woo is many times faster than Hunchentoot. And projects can die. >a person needs to understand the problem a tool solves before using the tool; otherwise you're training a code monkey, not a programmer. There's a reason we use high-level languages: They hide irrelevant details. You shouldn't have to learn how TCP works or know every detail of HTTP to know what can be done with it.
- deleted 11y ago
  [deleted]
- lispm 11y ago
  > Woo is many times faster than Hunchentoot. "Hello World" on the local machine... https://github.com/fukamachi/woo/blob/master/benchmark.md https://github.com/fukamachi/woo/blob/master/benchmark.md is that what you mean by 'faster'? Personally I'd prefer a more representative benchmark, which actually uses the network... Really measuring the qualities of a Web server is a bit more work.
  - eudox 11y ago
    >is that what you mean by 'faster'? Yes.
  - e12e 11y ago
    So, for multi-threaded, it's within a factor of 2. That's not bad. I wonder how much of that is likely to be eaten up in a real-world application. Interesting that woo is so much more performant for the single-threaded case though. But it hardly matters as both support multi-threaded, and both are much faster with multiple threads...

copsarebastards 11y ago

> Because in the real world of web development applications are hardly ever written directly on top of the server. They are written on a framework, that sits on top of an HTTP server abstraction (like Clack), that has pluggable servers. This is only true if you're writing Web 2.0 media websites that are only nominally not static websites. If you are solving an actual hard problem instead of just driving ad traffic, a framework is going to get in your way.