This is exactly what I needed. However with great abstraction comes great responsibility: you are now the gatekeepers of keeping things efficient in the backend. If I write "require('moment')", will you blindly require, or will you require, tree-shake, minify, etc?
I guess my question is: can I trust Zero to always strive for optimum efficiency, or is it just convenience?
I think that's a valid concern. We can certainly optimize and enable tree-shaking (zero uses Parcel to bundle React and HTML). The idea is to implement common optimizations so users don't have to. But also to provide enough escape hatches so advanced users can 'eject' and fine-tune themselves.
Yes please do, I just have a pet peeve against npm modules requiring mb's of files to only use a couple functions. Knowing that Zero does tree-shaking and general optimizations for me will make me happily use for most of my projects!
I think this is really nice for when I want to hack together a quick front-end for something. Once I have a working React/Node.js set up I can really quickly build something, but what usually stops me is the dozens of packages and things I need to wire together before I can actually start building something.
`create-react-app` is also pretty good, but this seems to do a bit more. I really like the simplicity of the set up and the fact that you can also just whip up an API call or something.
Having Markdown rendered as HTML is basically all I want when I'm standing up a single web page or a small website. This is definitely something I'll bookmark for later.
server is down (yay for proof of scalability ;)) so i can't tell for sure, but it looks like it's derived/based on next.js and comes from the same authors
My first thought is it doesn't have enough features or too much magic BUT that is EXACTLY why it shines. I'm not going to build the next FAANG company on this but it will let me get a backend up and running VERY quickly to test out an idea. The number of ideas of mine that have been killed in the cradle by decision paralysis is higher than I would like...
Exactly this. One of the aims to start this project was to reduce one more friction when testing an idea. Project configurations and set up is a big time suck.
Thank you for creating this! I often find I had an idea and then spend 1-2 hours doing NOTHING towards the idea trying to future-proof what I'm writing to the max. That is a trait of mine I need to work on by itself but "zero" should help let convince me to "just try it with zero before you setup TypeScript/Angular/Vue/React/Cordova/Express/etc...". I saw your other comment about making it Apache/PHP level easy and as someone who came from that background and when I first saw a query param displayed in the response from the web (ie: localhost?name=Josh -> Hello Josh!) I was hooked (you can imagine my reaction when I learned what a database was ).
In that vein do you think TypeScript is on the horizon for support? It's not a dealbreaker by any means but it would be nice to just write .ts files and have them automatically compiled (transpiled?). I can write JS just fine but TS's types are a nice sanity check for me.
the project's philsophy seems to be "use a bundler that works and don't reinvent it" so I bet adding a TS bundler would be a possibility, that'd be awesome
This is very cool framework and I will certainly use it for small to medium sized apps or website. However, just going through the doc there doesn’t seems to be a way to split components since any file is assumed to be a page. Any way around that?
Lastly, it’s a shame that the doc link points to github. The doc, as layed out in github is a perfect use case for zero.
It seems to me that you should have a folder (www?) that is served by zero, and a folder (lib?) that isn't. Then files in the www folder can import from the lib folder.
this is impressive! I would absolutely reach for this first when scraping something together quickly. I'd be super interested in seeing numbers for just how far this can scale before falling over.
> File-system Based Routing: If your code resides in ./api/login.js it's exposed at http://<SERVER>/api/login. Inspired by good ol' PHP days.
> Auto Dependency Resolution: If a file does require('underscore'), it is automatically installed and resolved. You can always create your own package.json file to install a specific version of a package.
This sounds like a security nightmare.
EDIT: to be clear, I don't meant he combination of both is a security concern, that each one of them separately is problematic.
...why? I get that file-system based routing means you know the location of a source file on disk, but if anyone can access that file you've already lost.
And auto-dependency resolution also doesn't seem any larger a security concern, all it's doing is skipping an "npm install" command.
Because if you ever have a broken upload system that allows you to drop a JS file somewhere accessible by the file system routing, you have remote code execution. Additionally, you now have to write guards in every non-endpoint JS file so that it doesn't get executed just by a misplaced HTTP request.
And as for automatic dependency resolution, this means you're not even aware of what transitive dependencies you're pulling in, what version they are and have no way to vet anything - everything is hidden behind a wall of magic.
Make your application directory read-only to the user running the application, as it ought to be anyway.
Automatic dependency resolution however... Fantastic for experimentation, but that's a dealbreaker for production. Maybe it would be OK if it actually wrote the package-lock.json to the application directory, I'd have to think about that.
Probably having .htaccess / .env / database configuration / files that are not supposed to be public be exposed.
For instance, Rails has a public/ folder for files that are going to be served. And jekyll hides files by pattern-matching them[1].
Zero doesn't seem to have exclude folders by default. The solution would be to run Zero is a subfoler and require file in the parent folder which would act as the tree's root.
Currently, files starting with _ (underscore) are hidden in zero. This is still a feature spec we need to finalize as this can create confusion. Maybe a .zeroignore file (as suggested in another comment) would be a better idea.
Why not reverse that and use a whitelist instead. It’s a lot easier to decide what folders and files should be served than to think of all the things that shouldn’t.
Nextjs uses a pages/ subdirectory which gives you implicit routing, without having to compromise on the whitelist aspect. I think it's a better compromise.
If security is a concern, this is probably a bad choice; this doesn't seem to be advertised as a bulletproof security solution to anything, rather a utility for small little one-off apps that might need _some_ backend functionality. Once you start adding features like file-uploading, youre obviously gonna want to pick a more robust option
I disagree somewhat. If the goal of a project is to teach a different skill and it may cause too much of a headache to add a real server this service might make sense. It’s like when you’re learning a new spoken language. It’s better to practice a breadth of situations and vocabularies and make mistakes (that get corrected over time) than to learn fewer things perfectly
Pretty sure student projects should teach you something other than `$ npm install`, no?
When I was a hiring manager and scoped out juniors from bootcamps I had a conversation with some candidates and they would say, "I built user registration and login". When I asked them to talk more about it they said, "well I installed auth0"... Any student project which doesn't teach them how something works is not really teaching anything of value, is it?
Expecting a student to learn how to code at all, not to mention code well, from an academic/bootcamp setting, is an expensive fool's errand for anyone that hires them.
Programming is not academic. It has more in common with plumbing and carpentry and electrician work: you learn only by doing, and you learn how to do it well by doing with critical supervision from a mentor.
That slight wobble in Earth's orbit we're experiencing, that's Dijkstra rolling in his grave.
All joking aside, programming should be treated a lot more like engineering and a lot less like craft. Yes, it does have aspects of both, but neglecting the engineering aspects of it is proving to be increasingly harmful to our end users.
> a lot more like engineering and a lot less like craft
I think the curve of diminishing returns plays an important role. A near hack job will often get you 90% there, in terms of fulfilling what was exactly requested. I don't think this is true for any other skillset. It's so easy to make something featureful and fragile in software. The time and cost above that can be very difficult to justify to customers/management.
In the words of a previous boss, after I pointed out we need more testing, "Everything is working, we'll fix the bugs as they come".
The difference between engineering and trade work is that trade work, like the jobs you mention, either follows a plan written by an engineer, or prescriptive standards designed by engineers (and usually certified by governing bodies of engineers). Prescriptive standards allow skipping all the engineering calculations as long as the guidelines are followed and tolerances respected.
Software development (and a lot of hardware development, to be fair) is unique in that doing it well requires functioning as both an engineer and a tradesperson. One's skill has to cover a wide section of the spectrum.
I agree with GP. Security is always a concern. I too used to think as long as it's behind the firewall, or a local only exploit, it doesn't matter. But it always matters. Small apps become big apps. Small user bases large ones. Someone gets onto your internal network and then your small userbase app for trusted employees becomes a jumping off point, etc.
Your sort of thinking is how you end up with Yahoo levels of account leaks.
I think your comment about scalability is accurate. Small apps become big apps, and small user bases get bigger. I’ve seen it happen — but I’m not going to think about scaling to thousands of users when I just need a small application to share with my team. If I spent five days building it to the utmost standards, instead of spending one day on something that solves a problem immediately, I’d be laughed at. It is the same with security.
> Your sort of thinking is how you end up with Yahoo levels of account leaks.
I wouldn’t store any of my customers’ data on an insecure internal service! I know that’s mad!
> Security always matters.
The first part of securing a system is to come up with your threat model, isn’t it?
> I wouldn’t store any of my customers’ data on an insecure internal service! I know that’s mad!
I'm completely sure that you're right. You know that would be irresponsible and reckless with lots of very sensitive data.
With that said, how sure can you be of every other person writing a simple, small, business app for just a handful of their coworkers? I've encountered some people doing exactly what you've described without the same level of cool-headed risk-weighing as you.
One of the key functions of GDPR and CCPA and PIPEDA is to make many businesses consider what kind of liability might be attached to things they might otherwise opt to not sweat.
If you're ever running this, and you've left it open to a LAN or the internet, your entire system is vulnerable for use in whatever way someone wants. There are bots looking for stuff like this all the time.
You know it's always a concern, but context is everything.
> small little one-off apps that might need _some_ backend functionality
The security implications of serving a static website vs. a dynamic application that processes payment and queries the database are two different beasts
When all other layers are secure, like wearing a bulletproof west inside a bulletproof car inside a bunker that can withstand a nuclear blast. And add to that some security by obscurity, like a bunker in a secret location, only accessed via a tunnel.
That said, if security is top priority you also want to be ready if you get shot from within the car. But more importantly you need to define the most common scenarios and make sure you are protected from all of them. One scenario might be someone shooting you, but another scenario might be food poisoning which would require an additional, different solution.
There's different levels of 'filesystem access' vulnerabilities.
Some classes of bugs that would be otherwise tame due to the constraints (eg., file upload that might be able to only create new files in some part of the directory tree, or a buggy routine that lets you create arbitrary symlinks, or leftover VCS/CM files that happen to end in .js and are not filtered out by the router) now become the most powerful kind, remote code execution.
I don't disagree that this doesn't seem necessarily secure and the auto dependency resolution is a bad idea for other reasons in my opinion, but I don't see the security aspect of it.
The moment I can upload files to the application folder that are executed, I can just `require('child_process').spawn("my_evil_stuff", [])`. In particular "my_evil_stuff" could be some npm install command. I don't see how automatically installing the dependencies makes this worse than it already is.
EDIT: While this is a different attack vector than I was envisioning here, jexco has provided a scenario in which there are additional vulnerabilities: Vulnerable dependencies that cannot be managed.
Where is the management of requirements? How do you force LTS versions? Or roll back if a version has a vulnerability? When things are automatic you are unable to stop bad things from happening.
Not that I was going to say this is a good idea in the first place, but rolling back vulnerable dependencies is an excellent point that I hadn't thought of. Thanks!
So the app would need write permissions to its own folder. That's obviously a bad idea in a production deployment. I guess I was thinking that the dependencies would be installed during a privileged one-time "deployment run" so you wouldn't need the permissions after. Maybe I'm giving the thing too much credit.
Seems like your fix[1] for this is a bit fast. You are already importing `path` in that file. Also, you can do this with just one `path.relative`. Lastly, the url package method you are using is deprecated[2].
A simpler fix might be to canonicalize (i.e. no "..") the public folder path and the requested file path and then ensure the public path is a prefix of the other.
I don't think I would use any package that makes this classic mistake in 2019. Web services need to be at least vaguely secure and this destroys all my confidence of that.
> This project is brand new, I posted the repo publicly this morning.
Are you implying that you don’t think it’s ready for production use? If so, maybe you should do like a lot of projects, and warn about it loud and clear in the docs. It’s not clear at all that users should expect the type of blatant security problems that were discovered here.
If the bar to posting to HN was "I am finally confident this project is mature", rather than "I can post any link I want and if people thing it's cool, it'll get upvoted", HN would have a hell of a lot less cool shit on the front page on a daily basis.
People are allowed to screw up: it's how we learn. They got comments that pointed out flaws, they fixed them and posted a follow-up regarding that fix, why the hate? This person tried to make something cool, they learned important security lessons, and now have a deeper insight into what they made, and the world it operates in. How is this possibly a bad thing we don't want to have happen on HN?
I saw your comments fixing it - which is pretty awesome by the way (& I hope you've taken on board the other comments regarding securing it even further).
Due to PHP experience, this would've been something that I ensured was implemented properly from the outset. I know this to be true, because I've dabbled in the very space you're working in now, and it was one of the very first things I ensured: that no file could be served except from direct descendants. (I rethought my project and tossed the code)
For something like this you need to be absolutely sure about security. Have a look at the annals of PHP security issues - and most likely you'll see a lot of similarities that you'll need to make sure you address.
I'm sorry if you read hate in my words: definitely was NOT intended! I have nothing against you as a co-habitor of this wonderful planet! To me, the bug highlights that a few design considerations may have been overlooked.
But after reading the thread following your fix it seemed that the fix wasn't done properly. That, more than the security issue itself, kind of ruined my confidence as well, sorry to say.
Is there any way to "ignore" specific files or directories? For example, I want to reuse React components across different routes (exposed as jsx files). However, I don't want `mysite.com/components/Container` to be a valid endpoint.
Yes. It's not written in docs yet but any file or folder starting with _ (underscore) is not exposed publicly. This feature spec is still open for discussion as on how to tackle it the best.
Check my reply to this comment. The underscore idea was one of the first things to come to mind too, but I think having a specific file makes it clear to others who might not understand Zero internals.
seems like doing something like Next.js might be a better choice, aka have a main folder that exposes publicly accessible files, instead of having to add _ to each folders that should be private (it seems to me most folder/files would be private and not the other way around)
As others have said before, I think this is amazing for small one offs and maybe for beginning programmers. I'm afraid that, like all frameworks, people will start to misuse it eventually. Someone will make a little app with that, because it's so fast, simple and amazing, right? Later, however, the app will grow and it will become a maintainability nightmare. The only good thing about it is that you can easily get out of this framework and migrate to managing express/node/react yourself, or so it seems. It isn't like rails, where if you get into it, your app is so highly coupled to it that any escaping is impossible, even if your app becomes very complex.
Escaping and writing a custom node+express+React SSR server for a zero-based app should be easy. But zero isn't a 'platform' anyway. It's just an abstraction on common config and some glue code, all open-source so you can easily fork and improve.
This is nothing to do with node. This is poor programmer decision making. You can build great node apps with a real minimalist approach. Holding up projects which pull in half of npm as "the world of node" is like holding up a hot and ready 5$ pizza and saying all Italian food is bad.
Encouraged by who? I see the same people which used to install jQuery or WordPress plugins and were able to get janky but working sites. But prolific module authors and node core contributors don't promote these approaches.
Maybe if you listen too much to twitter "thought leaders" you might get this impression, but we are all aware of the problems with social media platforms...
Well, considering the amount of dependencies in popular projects like CRA that was highlighted here a few days ago I don't think it's unreasonable to extrapolate to the general ecosystem. Of course there are module authors and devs doing it differently, but in general most node projects I see are more dependency-happy than projects I see in other languages.
Give people a useful tool (npm) and they will muck it up. This is both the best and worst part of the general node ecosystem. The issue is people saying things like "that's just node". It is not node, it is the ease of use and popularity meaning there will be more of these examples. If you care to make high quality use of the platform and tools you can, but that means not following the crowd.
Most other ecosystems inlcude more batteries (e.g. PHP). That is why you have to update this ecosystems with all their modules.
The problem is, if the core has a bug, ALL apps in this ecosystem has the bugs.
node includes not everything and concentrate on the core. If modules have bugs, not all apps a compromised.
It is a fundamental design decision, if you not like it, don't use node.
You can include all dependencies manually and update them manually, nobody keeps you away. But have fun to update all your deps.
While I embrace less configuration, you can't really avoid TLS these days. There is always configuration, many of configurations. Some implicit, some explicit.
As others have pointed out, make sure to mark files that are not supposed to be exposed to the client by prefixing them with a underscore, otherwise you'll have a bit of a security issue. Otherwise, you're good to go.
Wow, I love that people can wrap express and many of its components and end with something so different from its foundation. That being said, this level of "batteries included" approach has a cost.
In this example, it is the complexity of this file[1] and the fact that if you were to write this as a single express middleware you could probably write it in less than 20 lines.
Yes, writting an express backend is really simple, some plugins, error-handling etc. and you can run it in less than 1 hour.
But the Frontend with webpack needs definitely more time, hours and hours to fiddle webpack to your needs.
This project has a definded strucutre and support defined modules (react), so it could save you a lot of webpack config time, but you can not do everything with it. You have to use it as it is.
Setting up Webpack isn't even the time-consuming part, in my experience - it's getting the back-end and front-end to work together and having a comfortable development environment in which both live reload.
Zero configuration... read "We made choices for you, just trust us. Read our documentation to see what your missing. Oh, also since you didn't configure it we'll change (the defaults) on our next release".
> Oh, also since you didn't configure it we'll change (the defaults) on our next release
That doesn't really matter, since I'll only use the next release for my next release, and the previous prototype has either been thrown away or turned into a proper stack.
I wonder if this what the people who made the things I have to inherit and patch and secure believed.
Current app is EOL Framework Release in an EOL Language Release running on an EOL Distro Release on an unmonitored server without any patches applied... so business as usual.
255 comments
[ 0.23 ms ] story [ 284 ms ] threadI guess my question is: can I trust Zero to always strive for optimum efficiency, or is it just convenience?
`create-react-app` is also pretty good, but this seems to do a bit more. I really like the simplicity of the set up and the fact that you can also just whip up an API call or something.
It's an instant tutorial on how this damn mad hatter of an ecosystem works. They heavily commented the thing too !
Honestly, any lecture on react should have a part where people ejects and read the source code.
the page and code styling misleaded me
In that vein do you think TypeScript is on the horizon for support? It's not a dealbreaker by any means but it would be nice to just write .ts files and have them automatically compiled (transpiled?). I can write JS just fine but TS's types are a nice sanity check for me.
https://github.com/remoteinterview/zero/blob/72ea1faaef51b92...
Custom file watcher: https://github.com/remoteinterview/zero/blob/72ea1faaef51b92...
Routing / workers: https://github.com/remoteinterview/zero/blob/72ea1faaef51b92...
Dependencies for using the react renderer: https://github.com/remoteinterview/zero/blob/72ea1faaef51b92...
And so on. The routing part is a bit funny - by spawning a new process per request this is actually very close to PHP/CGI :)
I still have to have a giggle at the similarities between what you produced and what is essentially a PHP/Dom/Apache setup.
The Async wait for initial props before what is essentially a template render just drove it home.
One key thing missing is an easy wrap around running tests. What would it take to add this?
Lastly, it’s a shame that the doc link points to github. The doc, as layed out in github is a perfect use case for zero.
> Auto Dependency Resolution: If a file does require('underscore'), it is automatically installed and resolved. You can always create your own package.json file to install a specific version of a package.
This sounds like a security nightmare.
EDIT: to be clear, I don't meant he combination of both is a security concern, that each one of them separately is problematic.
And auto-dependency resolution also doesn't seem any larger a security concern, all it's doing is skipping an "npm install" command.
And as for automatic dependency resolution, this means you're not even aware of what transitive dependencies you're pulling in, what version they are and have no way to vet anything - everything is hidden behind a wall of magic.
Automatic dependency resolution however... Fantastic for experimentation, but that's a dealbreaker for production. Maybe it would be OK if it actually wrote the package-lock.json to the application directory, I'd have to think about that.
I think this framework hasn't been written with security in mind at all.
For instance, Rails has a public/ folder for files that are going to be served. And jekyll hides files by pattern-matching them[1].
Zero doesn't seem to have exclude folders by default. The solution would be to run Zero is a subfoler and require file in the parent folder which would act as the tree's root.
[1]: https://help.github.com/en/articles/files-that-start-with-an...
At the risk of being presumptuous... When is security ever not a concern?
If security is taught at the student level, by the time they get to junior developer they'll have an understanding of it / do it automatically.
When I was a hiring manager and scoped out juniors from bootcamps I had a conversation with some candidates and they would say, "I built user registration and login". When I asked them to talk more about it they said, "well I installed auth0"... Any student project which doesn't teach them how something works is not really teaching anything of value, is it?
Programming is not academic. It has more in common with plumbing and carpentry and electrician work: you learn only by doing, and you learn how to do it well by doing with critical supervision from a mentor.
All joking aside, programming should be treated a lot more like engineering and a lot less like craft. Yes, it does have aspects of both, but neglecting the engineering aspects of it is proving to be increasingly harmful to our end users.
I think the curve of diminishing returns plays an important role. A near hack job will often get you 90% there, in terms of fulfilling what was exactly requested. I don't think this is true for any other skillset. It's so easy to make something featureful and fragile in software. The time and cost above that can be very difficult to justify to customers/management.
In the words of a previous boss, after I pointed out we need more testing, "Everything is working, we'll fix the bugs as they come".
Software development (and a lot of hardware development, to be fair) is unique in that doing it well requires functioning as both an engineer and a tradesperson. One's skill has to cover a wide section of the spectrum.
Internal applications where the entirety of the userbase are trusted employees. (Preferably, the userbase is small, too.)
Nobody’s going to bother finding vulnerabilities in an application where, if they break it, their own job gets harder.
Your sort of thinking is how you end up with Yahoo levels of account leaks.
Security always matters.
> Your sort of thinking is how you end up with Yahoo levels of account leaks.
I wouldn’t store any of my customers’ data on an insecure internal service! I know that’s mad!
> Security always matters.
The first part of securing a system is to come up with your threat model, isn’t it?
I'm completely sure that you're right. You know that would be irresponsible and reckless with lots of very sensitive data.
With that said, how sure can you be of every other person writing a simple, small, business app for just a handful of their coworkers? I've encountered some people doing exactly what you've described without the same level of cool-headed risk-weighing as you.
Not everything runs online connected to the internet.
1. https://www.information-age.com/major-security-alert-40000-m...
https://www.theverge.com/2018/11/30/18119576/pewdiepie-print...
> small little one-off apps that might need _some_ backend functionality
The security implications of serving a static website vs. a dynamic application that processes payment and queries the database are two different beasts
Famous last words.
By this time it's already too late.
Some classes of bugs that would be otherwise tame due to the constraints (eg., file upload that might be able to only create new files in some part of the directory tree, or a buggy routine that lets you create arbitrary symlinks, or leftover VCS/CM files that happen to end in .js and are not filtered out by the router) now become the most powerful kind, remote code execution.
I could add `require('foo')` but I could also just require no third party code and have fun with the `process` module.
The moment I can upload files to the application folder that are executed, I can just `require('child_process').spawn("my_evil_stuff", [])`. In particular "my_evil_stuff" could be some npm install command. I don't see how automatically installing the dependencies makes this worse than it already is.
EDIT: While this is a different attack vector than I was envisioning here, jexco has provided a scenario in which there are additional vulnerabilities: Vulnerable dependencies that cannot be managed.
[1] - https://www.npmjs.com/advisories
[1] https://github.com/remoteinterview/zero/commit/b4af5325c388e... [2] https://nodejs.org/api/url.html#url_legacy_url_api
This project is brand new, I posted the repo publicly this morning. I frankly think this subthread is an overreaction. I don’t get the hate.
Are you implying that you don’t think it’s ready for production use? If so, maybe you should do like a lot of projects, and warn about it loud and clear in the docs. It’s not clear at all that users should expect the type of blatant security problems that were discovered here.
People are allowed to screw up: it's how we learn. They got comments that pointed out flaws, they fixed them and posted a follow-up regarding that fix, why the hate? This person tried to make something cool, they learned important security lessons, and now have a deeper insight into what they made, and the world it operates in. How is this possibly a bad thing we don't want to have happen on HN?
Due to PHP experience, this would've been something that I ensured was implemented properly from the outset. I know this to be true, because I've dabbled in the very space you're working in now, and it was one of the very first things I ensured: that no file could be served except from direct descendants. (I rethought my project and tossed the code)
For something like this you need to be absolutely sure about security. Have a look at the annals of PHP security issues - and most likely you'll see a lot of similarities that you'll need to make sure you address.
I'm sorry if you read hate in my words: definitely was NOT intended! I have nothing against you as a co-habitor of this wonderful planet! To me, the bug highlights that a few design considerations may have been overlooked.
Any idea of a timeline on this feature? I think it could be really awesome to be able to prototype with python in addition to js.
This is super interesting, what are you plans regarding this? Super curious.
You will eventually be adding all those packages when you develop a production-grade React / Node app anyway.
Maybe if you listen too much to twitter "thought leaders" you might get this impression, but we are all aware of the problems with social media platforms...
node includes not everything and concentrate on the core. If modules have bugs, not all apps a compromised.
It is a fundamental design decision, if you not like it, don't use node.
You can include all dependencies manually and update them manually, nobody keeps you away. But have fun to update all your deps.
That said, it looks like the latest (not yet npm-published?) version of zero has moved all the dependencies to `devDependencies`.
Security nightmare? Can I do myapp.com/.env and read the credentials from the wider internet?
Oops.
Couldn't see it on the main docs site (https://zeroserver.io/)
In this example, it is the complexity of this file[1] and the fact that if you were to write this as a single express middleware you could probably write it in less than 20 lines.
Guess this is just not my cup of tea?
[1] https://github.com/remoteinterview/zero/blob/master/packages...
Edit: also looks like the author decided to wrap their own multi process model? https://github.com/remoteinterview/zero/blob/master/packages...
But the Frontend with webpack needs definitely more time, hours and hours to fiddle webpack to your needs. This project has a definded strucutre and support defined modules (react), so it could save you a lot of webpack config time, but you can not do everything with it. You have to use it as it is.
It is nothing wrong with the tool, the tool does what it does. I sayd to configure it, to fit exactly your needs, it take a long time.
Using an other tool will not change it.
Only get them running is a thing of 2 minutes, but running with comfort and fit your needs is the hard part.
That doesn't really matter, since I'll only use the next release for my next release, and the previous prototype has either been thrown away or turned into a proper stack.
Current app is EOL Framework Release in an EOL Language Release running on an EOL Distro Release on an unmonitored server without any patches applied... so business as usual.