Live data from Hacker News

Show HN: Zero – A fast, zero-configuration server for React, Node.js, Markdown

zeroserver.io

191–200 of 256 posts

Re: Show HN: Zero – A fast, zero-configuration server for React, Node.js, Markdown

#191

Rule 35: Every year, someone somewhere will reinvent PHP or CGI or some combination of the two.

Where can I find the other rules?

These will carry you over until the "real" ones appear: https://spacecraft.ssl.umd.edu/akins_laws.html

Re: Show HN: Zero – A fast, zero-configuration server for React, Node.js, Markdown

#192

Rule 35: Every year, someone somewhere will reinvent PHP or CGI or some combination of the two.

Where can I find the other rules?

If you ever watched NCIS, I have just the thing: http://www.ncisfanwiki.com/page/NCIS%3A+Gibbs%27+Rules

Re: Show HN: Zero – A fast, zero-configuration server for React, Node.js, Markdown

#193
post #44

Earlier quoted context omitted.

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

> If security is a concern At the risk of being presumptuous... When is security ever not a concern?

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.

Re: Show HN: Zero – A fast, zero-configuration server for React, Node.js, Markdown

#194
post #120
post #96

Earlier quoted context omitted.

Anyone, including yourself can do that.

or, the person who should do it should do it and not rely on others to do their job for them?

it's not their job. there's a reason anyone can do it.

Re: Show HN: Zero – A fast, zero-configuration server for React, Node.js, Markdown

#195

"Zero configuration" But, you can install express, copy paste the getting started code and be up and running at a similar level in 5 minutes. I...guess I don't understand why I should trade something super simple and easy to use for this additional level of abstraction magic. There is such a thing as too much abstraction.

Depending on what you need, setting up a React app is super complicated and time consuming. Especially when you need SSR. There is a reason why frameworks such as Next.js, Reframe, and now this one are being used. I'd actually say the opposite, it's tools like Webpack that don't have enough abstraction. I don't care how source maps are being generated, why on earth is it a good idea for Webpack to force me to dig int…

there's already a very popular react (cljs) framework called reframe

https://github.com/Day8/re-frame

Re: Show HN: Zero – A fast, zero-configuration server for React, Node.js, Markdown

#196
post #178

Earlier quoted context omitted.

Your conclusion seems to eschew the "honey" for? "Vinegar"? I'm not disagreeing, I'm just trying to figure out what this would look like.

Some might imagine it as eschewing heedless amateurism in favor of mature professionalism. One starting point might be re-examining if all the negativity shown in reaction to Zero Server is actually excessive. Some of it surely is! It's also perhaps possible that some of it could be viewed as the horrified reactions of professionals who care about quality (and think about downstream effects) coming face-to-face with…

> Some might imagine it as eschewing heedless amateurism in favor of mature professionalism.

I don't fully understand what you're advocating, so I apologize if I am misinterpreting or mischaracterizing your position. But I can't imagine "mature professionalism" including berating or embarrassing another developer for creating a security hole. Some people do need that, but most don't. Many devs I've worked with are horrified when they find out they wrote in a vulnerability, and they try to grow and find out better ways. This is startup culture tho.

When I worked in enterprise type environments it was the opposite. There, you could send the dev a working exploit and most of them would groan and bitch about how "you security guys just want to tear things down and break things." I can understand being more of a dick in those situations, but I would still contend that's a venting of frustration more than a desire to actually teach. Most people just get defensive and put up walls when they feel attacked or embarrassed, and the learning is over at that point.

Re: Show HN: Zero – A fast, zero-configuration server for React, Node.js, Markdown

#197

Earlier quoted context omitted.

I agree with you about the over-negativity, but I have to disagree about the value of the "security nightmare" comments. Nowhere on the marketing page (that I saw) does it say, "prototype/development use only!" In fact I got the opposite impression. It seems to want to be a new framework. It's critically important to surface security issues early and often. There's already a cultural anti-pattern in the js world of j…

The thing's brand spanking new, that's the biggest sign for "prototype/development use only!"

My initial reaction was, "that's fair" but then on more thought I don't think I agree. Firstly the npm package currently up is version 1.0.7, which doesn't imply "protoype/development/unstable/etc."

I've also been part of many open source projects and it's very common to not release/announce it until we've proven it ourselves in production.

So while I think one should definitely exercise caution with brand spanking new code, there's no way to know whether it was just ideated recently or has been in development for a while but just got released/opened for the first time.

Re: Show HN: Zero – A fast, zero-configuration server for React, Node.js, Markdown

#199
post #64
post #63

Earlier quoted context omitted.

So if an attacker already has access to your filesystem to modify your files, they can install stuff? By this time it's already too late.

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…

Exploiting auto-downloading modules requires that the filesystem's already been exploited to the point where the app's code can be modified.

I could add `require('foo')` but I could also just require no third party code and have fun with the `process` module.

Post reply on HN