kind of weird to see this posted -- it's not a release announcement. Just some change notes from trunk (you can see on the page it's still versioned 2.5)
It does look like they've added a few nice little features (i wonder if per listen options means we'd be able to listen on a unix socket?)
Another question would be "Should Apache support HTTP/3?". Personally I'm happy with the status quo and would need some convincing that it's worth turning on a new protocol.
It's been an interesting ride the past few years as a software engineering manager: many junior engineers have never developed or deployed anything that requires Apache httpd.
Some have never even heard of it, or seen it in the wild.
Well… I was a bit surprised to find a Teams group about VMS application support in my company… perhaps I shouldn’t.
After all, we also have a lot of IBM mainframes being used too and, most likely, other exotic stuff in areas I don’t even know about that exist way above my security clearance.
EVERY page (or site) seems to need a full blown NodeJS server install and tons of React/Vue etc.
Younger folks are blown away at how quickly I can develop a fully functional site with just Flask, good ole' HTML, basic CSS and VanillaJS using only a couple flat files as a backend database.
I could make a similar argument about complex Python or Golang scripts that are basically the equivalent of multiple bash commands piped into a one liner.
The toolchains to build and deploy a completely static site today are about 10x more complex than a fully dynamic python/ruby/php site a decade or two ago.
There is no need to. It is insanity. Maybe using truckloads of complex tooling makes one feel smarter never mind that the final outcome is something akin to "Hello World".
Some, especially younger folks, sadly just don't know better.
Maybe we just experience now the same people back than experienced seeing the new generation using for example C++ instead of some "straight simple lines of assembly". On the other hand's side there is for sure complexity which you actually want to pay for. Whether such call is or isn't justified can't be known upfront often times.
Given that, my personal opinion on the state of web-development is that it's partly outright insanity for sure. Especially front-end things. Boy, it's just a GUI in the end!
Nobody should care about the code as it should be generated by proper design tools anyway. Coding such things by hand shouldn't feed a whole industry branch instead. Creating GUIs is a job for graphics and interaction designers. They should have gotten the proper tools to get their work done (mostly) on their own. If the alleged "GUI stack" used is so over-complex that it can't be handled effectively by design tooling it's a valid question whether that technology is actually the right tool for the job. But it seems almost nobody is asking this question any more. That's the insane part.
>"Maybe we just experience now the same people back than experienced seeing the new generation using for example C++ instead of some "straight simple lines of assembly""
I do not think there is any similarity. Personally I've started with straight machine codes, never mind assembly. Still I gladly use any higher level tools as long as they benefit my ROI.
As for GUI - back in the 90s Borland had already shown how to produce stellar, easy to use performant tools for designing GUI apps.
JS public has had ages to come up with something resembling the same thing. Instead they've unleashed whole bunch of atrocities making themselves into their own victims with all signs of Stockholm's syndrome.
> Personally I've started with straight machine codes, never mind assembly.
Me too - the first computer I used was an IBM Schools Computer. This was a thing a bit like an Apple I or something, but it had no assembler, no editor, no OS. To load a program, you typed it directly into memory in hex. I think (this was a long time ago) it contained an 8080. It had a TV output, and an integrated keyboard with flat membrane "keys". There was no storage - you had to copy stuff off the screen using a pencil and paper.
I expect it cost a small fortune.
[Edit] Apparently it wasn't an 8080, and it didn't take input/produce output in hex - it used decimal.
Yep - we did a largish (300K user) site 18 years ago in PHP and static HTML. Was pretty high scale at the time with a lot of complexity and state (mysql with read replicas at the time). We didn't have concurrency totally solved but it wasn't critical and the thing ran great. If you looked at the html so so simple. HTML / CSS. I don't even think we did javascript at the time?
The toolchains now to just do the most basic form with a submit button - it's wild.
> The toolchains now to just do the most basic form with a submit button
Oh how I long for a submit button and a form. I’ve worked on code where there’s just a bunch of divs and input fields: no form no action, no fieldsets, no labels, no submit button. I do not have words for the emotions it causes.
And don't forget what you paid back then for hosting.
Compare to all those Kubernetes clusters on the cloud for all those microservices that are totally needed today to operate such a large site for one third of a million users correctly.
And maybe it would make even sense to talk about build and deployment times back than.
Back in the day... I used to maintain and manually scale a platform that ran a regionally large social site. It was written in PHP, by two geeks in a dorm, served by Apache and had a single MySQL database and host, in a respectable datacenter. At it's greatest moment, it had a pair of keepalived-hosts in front of around 7 Apache hosts and still that single database host.
That was expensive, but not in maintenance. The amount of moving parts in that, compared to all the doohickeys of modern times, seems like 1:100.
As someone who understands very little of modern web-doohickeys, I'm very afraid of the direction we are going in and it seems like my job-security is quite high, because schools don't produce infrastructure people any more... Just happy-go-lucky developers who know how to run things on top of a credit card, on someone else's computer.
If only standard HTML would support templating we could get rid of 80% of the tooling, maybe 100%. In fact, if I had to choose between two super simple tech stacks for static sites:
There is indeed a <template> tag in HTML but it only works inside the current loaded page, i.e. to render rows inside a table. You cannot use it to include a header or a banner. In addition, the the tag relies on JS to be rendered.
My analogy for you is a house that was built 6 inches to the right of where it should be. It's almost perfectly good. You can live in it. But there are these niggling things wrong. They will always be wrong. Over time, enough people say "hey if we just do this work, get this done, we can move the house". So finally some people actually do it - they move the house, brick by brick, 6 inches to the left. And hence end up with Webpack and npm and 1gb of node_modules etc etc. And the house is now 6 inches to the left. To many it looks identical to how it did before. But for those to whom it really matters - people who's quality of life depends a lot on exactly where the house is - it is a massive difference.
So many small things are just now better - aligned with what we really needed to start with. Whether it's the automatic reactive updating dev server, the fact I can embed CSS directly with my component and have it scoped there, or that I can use properly DRY CSS, or that I can unit test my code separate to the DOM, that I can build my pages in a truly "functional" way such that they are free from complex state bugs ... all these things are small ... but big.
And to take this analogy further, adding HTMX to a traditional web framework or switching to Phoenix LiveView is like jacking up the whole house and moving it to a better spot in an afternoon, which is what my coworker’s family did to their first home the week they bought it after moving to the US. If you don’t know it can’t be done…
> which is what my coworker’s family did to their first home the week they bought it after moving to the US
Tangential to this thread but... why? I'm asking from a country where that is not a done thing, and where heave and shrinkage under foundations cause enough problems without even thinking of moving them.
They were Polish immigrants. I know part of the work involved the foundation but not much more. Obviously no time to expand a basement or crawlspace, if there was one. It sounds insane to me, too, but I'm the kind of person who waffles over which foundation engineering firm to call just to get an estimate.
Probably the single biggest thing in my own experience - and that the SPA naysayers or php/flask/ruby commenters miss, the ability to work on front end while the browser updates automatically, without a full page reload, and while maintaining state (for example, complex form fills), including layout/style changes (which are automatically scoped and vendor prefixed for you) is the single greatest time saver and ergonomic feature that at least for me, makes React + webpack + all the things they’re complaining about worth it over any caveats and/or benefits of “X instead.”
Full page reloads seem like a red herring to me here. There doesn't seem to be a difference in feasibility of achieving these things between having and not having them.
I work with Node and Python regularly and I'm unclear on how a Node stack would be more complex than a Python stack. Isn't "just Flask," which is Python plus packages, equivalent to Node plus packages, both in terms of development and deployment?
Yes, to me at least. The parent comment maybe just knows flask very well and is more comfortable with it and less comfortable with JS. An equivalently proficient JS engineer would be able to do just as much in just as little time (and likely more anyway).
Personally I think JS is a much better language. Python is still recovering from the 2 to 3 migration. Meanwhile JS will always be backwards compatible and with TS is a great language to work in. Python still doesn't have a good type system.
Python annotations actually provide a very decent typing layer. You have to use an additional tool to do the checks, there are much fewer third party typings, and the type system is definitely not as sophisticated as TS.
But Python code is also not as dynamic as JavaScript, so you can get most of the way with what's already in the standard library. (again, disregarding the missing pervasive typings for the ecosystem)
Templating engines are far less powerful and extensible than client side frameworks.
FWIW, there are many JS templating engines as well that work with NodeJS too. There are pretty obvious downsides to templating engines that libraries like React and Vue improve upon.
Using flat files as a backend database is great, but not scalable. Does everything need to scale, not always, but it's a lot nicer to have that option and to build it that way from the beginning. It's also ridiculously easy to do so today.
You'd probably be blown away how quickly someone can get a full stack website set up complete with user authentication/accounts management (including reset flows, magic links etc), database integration, front end system, CMS, component design system, and any other goodies.
All this is easily doable in relatively short amounts of time, and makes working with other teams - designers, product owners, marketing teams - so much easier.
Not to mention being able to do everything in a single language. That's a huge win. Engineers can hop around easily and have access to the same dependency management system, language features, etc.
> You'd probably be blown away how quickly someone can get a full stack website set up complete with user authentication/accounts management (including reset flows, magic links etc), database integration, front end system, CMS, component design system, and any other goodies.
> Not to mention being able to do everything in a single language.
I’m interested in learning more about this, especially user authentication and and account management. Also, the single language appealing is appealing.
I’m from the PHP world of things and need to get experience with what the modern stuff you’re describing. Are there platforms or projects that provide the foundation of what you’re describing?
> I’m from the PHP world of things and need to get experience with what the modern stuff you’re describing. Are there platforms or projects that provide the foundation of what you’re describing?
Clojure and ClojureScript is probably the best real-world and actually practical example of this in the wild. .cljc files can be loaded by any Clojure runtime, while .clj files are for Clojure and .cljs are for ClojureScript. Many of the libraries in the ecosystem all use .cljc, so you can use the same libraries both in the backend and in the frontend.
I've always felt the "one language" sell was fake news. The amount of difference between JS in the browser and Node.js is much larger than the similarity. The DOM and Node.js APIs are big and vastly different in scope and what they accomplish. Add to this all the weird incompatibilities like Node not having fetch, or the multiple accepted module patterns etc it's such a mess. Then you get people telling you JSX is "just JS" also, which is also not true. You have to make all kinds of goofy adjustments to even make it function as HTML.
I do agree that you can pump out sites quickly with a modern JS stack, but I definitely think there is room for improvement and it should be idolized as "good" or the way it _should_ be.
It’s very possible and easy to get everything working the same way on the client and server but I agree the whole import vs require support is frustrating.
I set my stuff up to always use import syntax over require now which is what typescript works best with.
Of course the APIs in node vs DOM are very different. They do very different things but the benefit comes from having the same language support, syntax, type system, and methods. Types can be shared across the client and server so changes on one side are immediately detected on the other. It is annoying there’s no native fetch in Node but there’s a east npm package to support isomorphic fetch (node-fetch)
JSX is “just js” in that they are compiled down to simple function calls (React.createElement), there’s just a nicer syntax but there are systems (hyperscript I think) that just export functions like h1(), div() etc that do the same thing.
For authentication I believe passportJS is still the go to library for integrating with oauth providers like twitter, LinkedIn, Facebook etc (or setting up your own username and pwd system). I’m sure there are several other libraries as well.
In terms of learning that and anything else, the best thing to do is have a project you can work on that supports these and other features. Pick a database (either sql or nosql), a login mechanism (maybe via GitHub to start if you’re building something aimed at developers), and build a simple todo app to start or something else you’re interested in.
The documentation for open source JS libraries tend to be excellent. There are many blog posts and articles as well.
Just go slowly. There’s a lot to learn on both sides (front end and back end) so don’t try to learn everything at once.
If you want to focus on the front end find client side libraries that maybe don’t need a server (googles firebase comes to mind).
If you want to do back end work, don’t focus on the front end tooling as much and just get enough running to hit your server and see data.
I've not touched any standalone web-server like Apache, nginx over past two years for my web applications because Go's built-in HTTP server is production ready. It's one of my favorite reasons to develop in Go and makes portable deployment a breeze.
Lesser number of software to run on the server has resulted in predictable performance and larger savings on cloud costs.
Adding to what others have said, I mentioned 'production-ready' specifically because built-in http servers in programming languages are usually for testing and are not supposed to be used in production due to poor performance e.g. Python's http server and hence you'd require a standalone http server with python or Node.js applications.
In Go you can use default http server, multiplexer and router to serve your http requests directly to your application logic. It also has support built-in for Lets Encrypt SSL certificate via autocert covering all fundamental reasons you'd want a standalone web server for your web application.
It's true. If .htaccess is enabled (AllowOverride not set to None), Apache httpd will search for them and parse them on every request. For most use cases, this is honestly fine; it only becomes an issue for very high traffic sites.
FS events are OS dependent, don't always work (e.g. on network volumes), and often have a limited number of "watches" available which could easily be exhausted by deep, complex directory structures.
fs events do not scale on linux, at least not with the inotify facility as watching directories is not recursive and watching large trees, e.g. for creations, modifications or removals .htaccess, will essentially require you to have an additional watch descriptor per directory, and there are limits on number of queued events as well as number of watch descriptors per user. The alternate fanotify has it's own set of drawbacks, such as the need for CAP_ADMIN. Not to mention the mess you may get in when you're trying to monitor certain file systems, especially certain network-attached ones.
Other operating systems have drawbacks as well.
It's probably a safer and maybe even more efficient bet to just do the stats and opens and hope that the kernel/OS file system caches will save the day. Or you can go the nginx route and not support .htaccess like facilities (e.g. turn if off in apache).
In theory yes. In practice, how often are people who are using htaccess going to be running into these corner cases? I would bet anyone using it is likely running a very small site anyway where the convenience is worth it.
You can also detect when you have too many watches needed or a network filesystem to fall back to the existing path. It’s a philosophical difference ultimately.
I can't point to code, but from experience, changes usually register quickly.
Changes being adding a new file, changes to an existing one and so on.
.
While I hadn't thought of it, I haven't noticed issues around it. Using a platform like Drupal, Wordpress, Django, etc most paths don't exist on disk and just fall to the index file or get proxied to another server.
So this might be an issue for static files uploaded or static sites. Talking about Drupal and Wordpress, that would usually be,
They are not making a fair argument. The bottom line is, Nginx offers no way for an unprivileged user to safely modify behavior of the webserver. Yeah, .htaccess is not performant, but high performance isn't always necessary.
Not sure why you posted that? It agrees with what I said that Nginx doesn't support it. There is a use case for htaccess (shared hosting) and Nginx doesn't have a solution for it.
I've stuck with Apache given it is what I know, having used it for over 15 years. Despite its flaws, it does the job pretty well. I'm also more confident that Apache's code is more battle tested. On top of that I disable all the modules I don't need so my attack surface is pretty small. I run a static site so I basically run Apache with only a few of its core modules. I've tried others (especially Caddy) and while I appreciate some of the enhancements, they don't really add any significant improvements for my use cases.
I second this. NGinx has very powerful controls around content caching but very flimsy controls and monitoring around proxy operations. HAProxy has minimal controls around caching but incredible controls and flexibility with proxy operations. HAProxy is my go-to for the outer ring of my systems. I use NGinx when I need a lot of control around content caching and in that case NGinx is my middle ring. Think CDN model Both compliment each other quite well in various use cases.
I've interacted with the development teams of Apache, NGinx and HAProxy. The lead developer of HAProxy has by far been the easiest to work and interact with.
I’ve been using Apache exactly for that for years and it’s quite easy to setup. Maybe it’s me just being used to it, but I find Apache easier to configure than nginx.
That really helped me once when I needed to try something using Chez Scheme which doesn't provide network connectivity out of the box. No problem with CGI, though.
Apache has shipped with an event-based backend for many years now, so in terms of architecture it's on par with Nginx (while still supporting the classic pre-forking).
Personally I've found apache is more fully featured for niche use cases. For example you can do client cert authentication, then further look up a username from the certificate in ldap for authorisation - all from your apache configuration. For Nginx many of these niche use cases seem to be gated behind Nginx Plus.
One feature of Apache which Nginx annoyingly lacks is HTTP CONNECT support (there is a third-party module from Alibaba which implements it, but it only supports HTTP 1.x).
I've used Apache for over 20 years and I'm going to give you a feature it's missing: request coalescing.
My servers mostly proxy requests to a backend (PHP-FPM, but this is applicable to all other server-side languages). If m requests come in for /foo and all requests have the same cookies, Apache will pass all m requests through to the backend.
With Apache I have to put other software in front of the web server (Varnish usually) that does this for me. So switching to a server where I can reduce installs to support by 50% is appealing.
You linked to the French version of this page instead of the English version. Since this page itself isn't translated yet, you don't notice on it, but if you click any of the links on it, you'll end up on pages that actually are French.
Looking at the release docs it’s a smallish release. But I’m very happy something is still going on there. HTTPD has been my go to web server for years and I had used it so many times in production as a proxy/gateway. Always reliable.
I know that everyone uses nginx now and that in the end it has more scalable - event based architecture. But for my scale httpd was never a bottleneck.
It’s just like an “old friend” you can always rely on.
I’ve always had a soft spot for Apache httpd, Something about it’s configuration syntax i can grok a little easier than Nginx. I look forward to testing 2.6 out!
84 comments
[ 3.2 ms ] story [ 147 ms ] threadIt does look like they've added a few nice little features (i wonder if per listen options means we'd be able to listen on a unix socket?)
The Apache httpd project uses even/odd versioning, much like the Linux kernel. 2.5 is the development branch for 2.6.
* https://httpd.apache.org/docs/trunk/en/new_features_2_6.html
Or just:
* https://httpd.apache.org/docs/trunk/new_features_2_6.html
Some have never even heard of it, or seen it in the wild.
After all, we also have a lot of IBM mainframes being used too and, most likely, other exotic stuff in areas I don’t even know about that exist way above my security clearance.
EVERY page (or site) seems to need a full blown NodeJS server install and tons of React/Vue etc.
Younger folks are blown away at how quickly I can develop a fully functional site with just Flask, good ole' HTML, basic CSS and VanillaJS using only a couple flat files as a backend database.
I could make a similar argument about complex Python or Golang scripts that are basically the equivalent of multiple bash commands piped into a one liner.
I genuinely don’t understand it.
There is no need to. It is insanity. Maybe using truckloads of complex tooling makes one feel smarter never mind that the final outcome is something akin to "Hello World".
Maybe we just experience now the same people back than experienced seeing the new generation using for example C++ instead of some "straight simple lines of assembly". On the other hand's side there is for sure complexity which you actually want to pay for. Whether such call is or isn't justified can't be known upfront often times.
Given that, my personal opinion on the state of web-development is that it's partly outright insanity for sure. Especially front-end things. Boy, it's just a GUI in the end!
Nobody should care about the code as it should be generated by proper design tools anyway. Coding such things by hand shouldn't feed a whole industry branch instead. Creating GUIs is a job for graphics and interaction designers. They should have gotten the proper tools to get their work done (mostly) on their own. If the alleged "GUI stack" used is so over-complex that it can't be handled effectively by design tooling it's a valid question whether that technology is actually the right tool for the job. But it seems almost nobody is asking this question any more. That's the insane part.
I do not think there is any similarity. Personally I've started with straight machine codes, never mind assembly. Still I gladly use any higher level tools as long as they benefit my ROI.
As for GUI - back in the 90s Borland had already shown how to produce stellar, easy to use performant tools for designing GUI apps.
JS public has had ages to come up with something resembling the same thing. Instead they've unleashed whole bunch of atrocities making themselves into their own victims with all signs of Stockholm's syndrome.
Me too - the first computer I used was an IBM Schools Computer. This was a thing a bit like an Apple I or something, but it had no assembler, no editor, no OS. To load a program, you typed it directly into memory in hex. I think (this was a long time ago) it contained an 8080. It had a TV output, and an integrated keyboard with flat membrane "keys". There was no storage - you had to copy stuff off the screen using a pencil and paper.
I expect it cost a small fortune.
[Edit] Apparently it wasn't an 8080, and it didn't take input/produce output in hex - it used decimal.
https://books.google.co.uk/books?id=2kMIqdfyT8kC&pg=PA242&lp...
I can't find much info about that thing.
The toolchains now to just do the most basic form with a submit button - it's wild.
Oh how I long for a submit button and a form. I’ve worked on code where there’s just a bunch of divs and input fields: no form no action, no fieldsets, no labels, no submit button. I do not have words for the emotions it causes.
Compare to all those Kubernetes clusters on the cloud for all those microservices that are totally needed today to operate such a large site for one third of a million users correctly.
And maybe it would make even sense to talk about build and deployment times back than.
That was expensive, but not in maintenance. The amount of moving parts in that, compared to all the doohickeys of modern times, seems like 1:100.
As someone who understands very little of modern web-doohickeys, I'm very afraid of the direction we are going in and it seems like my job-security is quite high, because schools don't produce infrastructure people any more... Just happy-go-lucky developers who know how to run things on top of a credit card, on someone else's computer.
Love that punchline, it summed it all.
1) HTML + CSS + JS
2) HTML + CSS + Templating system
I would pick 2) for sure.
This is basically why we are building kit55 (https://stack55.com).
So many small things are just now better - aligned with what we really needed to start with. Whether it's the automatic reactive updating dev server, the fact I can embed CSS directly with my component and have it scoped there, or that I can use properly DRY CSS, or that I can unit test my code separate to the DOM, that I can build my pages in a truly "functional" way such that they are free from complex state bugs ... all these things are small ... but big.
It’s awesome, yes, but it’s quite orthogonal to the nodejs/npm way of doing things. It’s far better.
Tangential to this thread but... why? I'm asking from a country where that is not a done thing, and where heave and shrinkage under foundations cause enough problems without even thinking of moving them.
Personally I think JS is a much better language. Python is still recovering from the 2 to 3 migration. Meanwhile JS will always be backwards compatible and with TS is a great language to work in. Python still doesn't have a good type system.
But Python code is also not as dynamic as JavaScript, so you can get most of the way with what's already in the standard library. (again, disregarding the missing pervasive typings for the ecosystem)
FWIW, there are many JS templating engines as well that work with NodeJS too. There are pretty obvious downsides to templating engines that libraries like React and Vue improve upon.
Using flat files as a backend database is great, but not scalable. Does everything need to scale, not always, but it's a lot nicer to have that option and to build it that way from the beginning. It's also ridiculously easy to do so today.
You'd probably be blown away how quickly someone can get a full stack website set up complete with user authentication/accounts management (including reset flows, magic links etc), database integration, front end system, CMS, component design system, and any other goodies.
All this is easily doable in relatively short amounts of time, and makes working with other teams - designers, product owners, marketing teams - so much easier.
Not to mention being able to do everything in a single language. That's a huge win. Engineers can hop around easily and have access to the same dependency management system, language features, etc.
> You'd probably be blown away how quickly someone can get a full stack website set up complete with user authentication/accounts management (including reset flows, magic links etc), database integration, front end system, CMS, component design system, and any other goodies.
> Not to mention being able to do everything in a single language.
I’m interested in learning more about this, especially user authentication and and account management. Also, the single language appealing is appealing.
I’m from the PHP world of things and need to get experience with what the modern stuff you’re describing. Are there platforms or projects that provide the foundation of what you’re describing?
Clojure and ClojureScript is probably the best real-world and actually practical example of this in the wild. .cljc files can be loaded by any Clojure runtime, while .clj files are for Clojure and .cljs are for ClojureScript. Many of the libraries in the ecosystem all use .cljc, so you can use the same libraries both in the backend and in the frontend.
I do agree that you can pump out sites quickly with a modern JS stack, but I definitely think there is room for improvement and it should be idolized as "good" or the way it _should_ be.
I set my stuff up to always use import syntax over require now which is what typescript works best with.
Of course the APIs in node vs DOM are very different. They do very different things but the benefit comes from having the same language support, syntax, type system, and methods. Types can be shared across the client and server so changes on one side are immediately detected on the other. It is annoying there’s no native fetch in Node but there’s a east npm package to support isomorphic fetch (node-fetch)
JSX is “just js” in that they are compiled down to simple function calls (React.createElement), there’s just a nicer syntax but there are systems (hyperscript I think) that just export functions like h1(), div() etc that do the same thing.
In terms of learning that and anything else, the best thing to do is have a project you can work on that supports these and other features. Pick a database (either sql or nosql), a login mechanism (maybe via GitHub to start if you’re building something aimed at developers), and build a simple todo app to start or something else you’re interested in.
The documentation for open source JS libraries tend to be excellent. There are many blog posts and articles as well.
Just go slowly. There’s a lot to learn on both sides (front end and back end) so don’t try to learn everything at once.
If you want to focus on the front end find client side libraries that maybe don’t need a server (googles firebase comes to mind).
If you want to do back end work, don’t focus on the front end tooling as much and just get enough running to hit your server and see data.
what file formats in particular?
Lesser number of software to run on the server has resulted in predictable performance and larger savings on cloud costs.
For me the reason to use nginx is ease of configuration. Recreating that kind of configuration in code is possible, but tedious and time-consuming.
In Go you can use default http server, multiplexer and router to serve your http requests directly to your application logic. It also has support built-in for Lets Encrypt SSL certificate via autocert covering all fundamental reasons you'd want a standalone web server for your web application.
Other operating systems have drawbacks as well.
It's probably a safer and maybe even more efficient bet to just do the stats and opens and hope that the kernel/OS file system caches will save the day. Or you can go the nginx route and not support .htaccess like facilities (e.g. turn if off in apache).
You can also detect when you have too many watches needed or a network filesystem to fall back to the existing path. It’s a philosophical difference ultimately.
Changes being adding a new file, changes to an existing one and so on.
.
While I hadn't thought of it, I haven't noticed issues around it. Using a platform like Drupal, Wordpress, Django, etc most paths don't exist on disk and just fall to the index file or get proxied to another server.
So this might be an issue for static files uploaded or static sites. Talking about Drupal and Wordpress, that would usually be,
I've interacted with the development teams of Apache, NGinx and HAProxy. The lead developer of HAProxy has by far been the easiest to work and interact with.
Personally I've found apache is more fully featured for niche use cases. For example you can do client cert authentication, then further look up a username from the certificate in ldap for authorisation - all from your apache configuration. For Nginx many of these niche use cases seem to be gated behind Nginx Plus.
2.) Sticky Sessions (and various other features) without having to pay $$$ to F5
I end up reaching for Nginx before Apache these days, but I have a lot of production that uses Apache.
My servers mostly proxy requests to a backend (PHP-FPM, but this is applicable to all other server-side languages). If m requests come in for /foo and all requests have the same cookies, Apache will pass all m requests through to the backend.
nginx instead will pass one request to the backend and then serve the response to all m requesters, reducing backend load. The setting is called proxy_cache_lock (https://nginx.org/en/docs/http/ngx_http_proxy_module.html#pr...)
With Apache I have to put other software in front of the web server (Varnish usually) that does this for me. So switching to a server where I can reduce installs to support by 50% is appealing.
Still no enhanced error code messages for improper use of `.htaccess` files?
(sigh)
Oh god, it didn’t have SHA-256 support before today? Was it using MD5 and SHA-1?
I knew basic auth was weak but jeez.
I know that everyone uses nginx now and that in the end it has more scalable - event based architecture. But for my scale httpd was never a bottleneck.
It’s just like an “old friend” you can always rely on.