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

by asadm • 7 years ago

513 245 7 years ago

rekshaw4• 7 years ago

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?

yodon• 7 years ago

If your requirements include "optimum efficiency", you almost certainly are not in the sweet spot for a general purpose zero configuration product.

rekshaw4• 7 years ago

I guess optimum/optimal efficiency is a lot to ask for, of anyone, let alone a convention over configuration framework, but you get my point!

asadlionpk28• 7 years ago

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.

rekshaw4• 7 years ago

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!

photonios• 7 years ago

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.

sametmax• 7 years ago

I find that the best thing about create-react-app is the eject feature.

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.

PerryCox• 7 years ago

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.

scrollaway2• 7 years ago

Caddy also has native Markdown functionality, by the way. https://caddyserver.com/docs/markdown

gjmacd• 7 years ago

Why is this any different than say, next.js?

asadlionpk28• 7 years ago

Next.js does file-based routing for React pages. This does the same for your API functions too.

dzek692• 7 years ago

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

dzek692• 7 years ago

server is up again and it wasn't the case.

the page and code styling misleaded me

joshstrange8• 7 years ago

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...

asadlionpk28• 7 years ago

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.

joshstrange8• 7 years ago

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.

ricardobeat• 7 years ago

It actually has a ton of magic. This is what's acting as the initial package.json:

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 :)

lugg• 7 years ago

At quick glance. Cool. Dig the idea, going to have to take a deep dive to see how things work later.

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?

asadlionpk28• 7 years ago

I started with PHP / Wordpress themes myself and the aim here to bring back the simplicity of web development. Def inspired by PHP/Apache setup.

gumbo2• 7 years ago

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.

asadlionpk28• 7 years ago

You are very right (and I did try that). I just wanted to avoid redundant docs for now. As it's a bit sparse and is continuously being updated.

bryanlarsen2• 7 years ago

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.

dstroot• 7 years ago

Supports the new hotness MDX. JSX/React components inside markdown. This is awesome for standing something up quickly. Thanks for creating this!

xxandroxygen3• 7 years ago

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.

asadlionpk28• 7 years ago

Currently this is as scalable as a normal node+express app. The aim for now is to improve development experience for now.

xxandroxygen3• 7 years ago

Love it, that's what I figured, and I agree with the aim!

giancarlostoro• 7 years ago

The time example reminds me of WSGI for Python. Neat that it supports templates too.

desmondl• 7 years ago

Are there any plans to make this support Typescript in the future? :)

asadlionpk28• 7 years ago

Yes. Should be easy! As we are not a typescript shop yet, we might need a hand with that. Otherwise, I will try to figure it out soon.

q3k6• 7 years ago

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.

untog• 7 years ago

...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.

q3k6• 7 years ago

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.

aboutruby• 7 years ago

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.

[1] https://help.github.com/en/articles/files-that-start-with-an...

gpmcadam• 7 years ago

Just like "good ol' PHP days!" as the docs say :D

jayar952• 7 years ago

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

beefhash• 7 years ago

If security is a concern

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

james_s_tayler• 7 years ago

_some_ backend functionality

Famous last words.

nailer2• 7 years ago

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.

q3k6• 7 years ago

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.

Cu3PO423• 7 years ago

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.

jecxjo• 7 years ago

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.

SahAssar7• 7 years ago

Well, for one giving the app the kinds of write permissions needed for this to work is not exactly ideal.

q3k6• 7 years ago

Putting my money where my mouth is - use this to leak any file accessible by the running user of zero from the filesystem:

    # curl -v --path-as-is 127.0.0.1:3000/../../../../../etc/passwd
    root:x:0:0:root:/root:/bin/bash
    [...]

asadlionpk28• 7 years ago

Thanks for pointing this out. Fixed this particular bug!

IshKebab• 7 years ago

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.

brianberns• 7 years ago

Hah. Now that’s a Zero day Zero server exploit. :)

johnpipi• 7 years ago

can just put some logic to set the root directory where can start to include from?

davish• 7 years ago

Looking through the code on github found a .py file handler in the works: https://github.com/remoteinterview/zero/blob/master/packages...

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.

asadlionpk28• 7 years ago

The js part (React, MDX, Node) is almost complete. I will put out a basic handler for python ASAP if that's going to be useful to you :)

nvusuvu• 7 years ago

Would be for me.

brillout4• 7 years ago

Reframe author here (https://github.com/reframejs/reframe).

This is super interesting, what are you plans regarding this? Super curious.

raihansaputra• 7 years ago

I'm interested

sjroot3• 7 years ago

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.

sjroot3• 7 years ago

I would propose adding support for a 'zeroignore' file to handle this. :)

asadlionpk28• 7 years ago

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.

sjroot3• 7 years ago

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.

jypepin• 7 years ago

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)

awb• 7 years ago

For markdown based sites, why not statically generate the site? Why render it on each request?

asadlionpk28• 7 years ago

As markdown can be dynamic in this case. (see https://mdxjs.com). Static 'export' can be a good feature though.

html5web• 7 years ago

Great job! Took 2 minutes to install and run.

miki1232112• 7 years ago

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.

asadlionpk28• 7 years ago

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.

insulfrable4• 7 years ago

Minimalism has a cost. http://npm.broofa.com/?q=zero

asadlionpk28• 7 years ago

Standing on the shoulders of giants :)

You will eventually be adding all those packages when you develop a production-grade React / Node app anyway.

insulfrable4• 7 years ago

Perhaps this should be done gradually and thoughtfully, rather than pulling half the internet into each minimalist app out there.

rekshaw4• 7 years ago

This is why we need tree-shaking and build-time optimizations to kill the unnecessary.

hombre_fatal2• 7 years ago

It's not that bad since it's an application (not just a library) that basically exists to glue those modules together.

broofa2• 7 years ago

It's worth noting that (for now) npm.broofa.com includes `devDependencies` in it's graph. Zero doesn't have any production `dependencies`.

broofa2• 7 years ago

Ignore that. Apparently I don't know my own code. It just looks at `dependencies`. :-p

That said, it looks like the latest (not yet npm-published?) version of zero has moved all the dependencies to `devDependencies`.

metalrain• 7 years ago

While I embrace less configuration, you can't really avoid TLS these days. There is always configuration, many of configurations. Some implicit, some explicit.

miki1232112• 7 years ago

Zero reads credentials from environment variables. Zero also loads variables from .env file in your project root, if it's present.

Security nightmare? Can I do myapp.com/.env and read the credentials from the wider internet?

chickenfries• 7 years ago

Why would you assume that they have this bug? If you’re actually curious if the bug exists go read the code or try it yourself.

ozten• 7 years ago

Another common on this page documents this bug on their production website.

benhowdle3• 7 years ago

Maybe a silly question, but is there anything one needs to consider before deploying this to, let's say, Heroku?

notduncansmith• 7 years ago

Nah

dammod• 7 years ago

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.

benhowdle3• 7 years ago

Ace! but in terms of running it, how would Heroku know how to, ie. if there's no `package.json`, there'll be no `npm run start` defined?

benhowdle3• 7 years ago

Oh, never spotted this: https://github.com/remoteinterview/zero#running-on-cloud

Oops.

Couldn't see it on the main docs site (https://zeroserver.io/)

wesleytodd8• 7 years ago

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.

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...

progx5• 7 years ago

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.

wesleytodd8• 7 years ago

Lol, if the setup on the FE takes hours to fiddle something is wrong with the choice of tooling. I don't use webpack, so I guess I am just spoiled?

Vinnl2• 7 years ago

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.

leowoo91• 7 years ago

So cycle repeats, PHP reborn?

marcrosoft• 7 years ago

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".

Vinnl2• 7 years ago

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.

lotyrin• 7 years ago

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.

revskill• 7 years ago

How to override default routes, then ?

asadlionpk28• 7 years ago

Can you give me an example of a rewrite? Zero already does some rewrites: https://github.com/remoteinterview/zero#route-rewrites

tathougies2• 7 years ago

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

MarvelousWololo3• 7 years ago

Where can I find the other rules?

tathougies2• 7 years ago

I make them up as I go along!

SahAssar7• 7 years ago

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

anitil• 7 years ago

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

k__2• 7 years ago

Can I claim "K's rule"?

Every (web) technology will eventually be called a PHP reinvention.

eitland2• 7 years ago

That would be an insult (either to php or to the other project, depending on which).

AstroJetson• 7 years ago

Does this mean we need to update Greenspun's 10th rule "Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp." to say "Any sufficiently complicated development environment contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of PHP?.

LoSboccacc• 7 years ago

Weird how does it knows what certificate to get for https

asadlionpk28• 7 years ago

You probably need nginx in front of this.

mighty_bander2• 7 years ago

My God, the people on this thread. There are people out there, working as software "engineers," who think that if they can't personally find a vuln in 5 seconds, the system must be secure. How is this #1 on the site right now?

asadlionpk28• 7 years ago

I thought that was ‘banter’ in your username.

didip• 7 years ago

Where have I seen this before... CGI scripts?

coolgoose• 7 years ago

I am so confused why the 'good old days' of php is a good example of how to do application development.

Every php framework got away from that for really good mesure, including not having your logic in the server document root.

playpause• 7 years ago

It's for quick experiments and prototypes. PHP (without frameworks) was great for that.

asadlionpk28• 7 years ago

Easier to create. With a path to scalability if ever needed.

slim• 7 years ago

  Every php framework got away from that for really good mesure, including not having your logic in the server document root.

IMHO unless you are building a http daemon, "your logic" should probably not include routing http requests. Using directory tree, url rewriting or generally leaving the controller part of your logic to the underlying httpd is probably fine in most php projects. Note: php frameworks can't do microservices

joshstrange8• 7 years ago

People in this thread are way overly negative. I understand this tool as something to be used for prototyping and locally-only but everyone is jumping on how insecure it is or how it's got a bunch of dependencies, or it's just express, etc. None of that matters if you aren't exposing this to the internet. This is a really neat project that lets you play with something right away and a lot of you all are bashing the author for things not even in the scope of the project.

Lastly this has so many upvotes and is #1 on the front page because it's cool, fun, and perfect for a little prototype or POC. There are a number of positive comments buried at the bottom but the highest comment is about how this is a "Security Nightmare".

Edit: Typo and I wanted to add: Not everything posted on HN has to be battle-tested, scalable, parallelizable, profitable, cloud-ready, secure, etc. It's the kind of attitude in this thread that keeps people from posting their own work at all. No one want's to get torn apart, back off and provide constructive criticism or keep quiet. (Note: advice I have not always practiced in the past)

Edit 2: Show HN rules (https://news.ycombinator.com/showhn.html), I think this makes my point better than I can.

Show HN

Show HN is a way to share something that you've made on Hacker News. The current Show HNs can be found via show in the top bar, and the newest are here. To post one, simply submit a story whose title begins with "Show HN".

What to Submit

Show HN is for something you've made that other people can play with. HN users can try it out, give you feedback, and ask questions in the thread.
A Show HN needn't be complicated or look slick. The community is comfortable with work that's at an early stage.
If your work isn't ready for people to try out yet, please don't do a Show HN. Once it's ready, come back and do it then.
Blog posts, sign-up pages, and fundraisers can't be tried out, so they can't be Show HNs.
New features and upgrades ("Foo 1.3.1 is out") generally aren't substantive enough to be Show HNs. A major overhaul is probably ok.

In Comments

Be respectful. Anyone sharing work is making a contribution, however modest.
Ask questions out of curiosity. Don't cross-examine.
Instead of "you're doing it wrong", suggest alternatives. When someone is learning, help them learn more.
When something isn't good, you needn't pretend that it is. But don't be gratuitously negative.

scottmf2• 7 years ago

People in this thread are way overly negative.

That's most of HN these days, and why I never visit anymore.

lyjackal• 7 years ago

Seems like it's been this way for at least a decade (that's about as far back as I've looked)

dragonwriter2• 7 years ago

For someone who doesn't visit, you are a pretty active participant

kukabynd• 7 years ago

Your comment is here though, no?

asadlionpk28• 7 years ago

Thank you! We only recently started working on this and ofcourse it’s not perfect.

All those concerns are very valid and will be addressed one-by-one. The project is open source under a decent license, I am VERY willing to accept any security PRs.

wiremine• 7 years ago

+1 on your positive approach to the negative comments. It looks like a great project: just remember not to loose your focus. :-)

tlrobinson3• 7 years ago

I agree people tend to be overly negative on HN about projects like this, but the AFAICT the project does not state any caveats about the security and/or where it should or shouldn't be used.

wesleytodd8• 7 years ago

I think any user should be responsible for vetting their tech choices. Why would the author put a disclaimer instead of fixing the issues?

In this case, the project is clearly too new/unstable/insecure to use in any real sense. It's presence as #1 on HN says more about the audience than the project itself I think.

freedomben5• 7 years ago

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 just `npm install`ing stuff and shipping to prod without auditing well (I've heard a number of times, "well it has like 60 stars on github").

If the project marketed itself as a "development only" or non-production framework then I'd agree with you 100%. However as it stands it's dangerous and could lead to extreme compromise of a system if it gets deployed to a production environment.

That said security-minded people are often inconsiderate and horribly untactful in their approach. That needs to change. You don't need to be overly negative to point out a security issue. Something like, "Cool start, but might want to point out that it's not meant for production!" would be a lot better IMHO.

joshstrange8• 7 years ago

That said security-minded people are often inconsiderate and horribly untactful in their approach. That needs to change. You don't need to be overly negative to point out a security issue. Something like, "Cool start, but might want to point out that it's not meant for production!" would be a lot better IMHO.

Agreed, and I also agree that maybe it should have a tagline about "not production ready" or even "never production ready". Not sure what the end goals of Zero are. I will say I thought it was pretty evident that this was not for production (if only to the sheer amount of "magic" inside) but maybe that's just me and it should have a disclaimer to that effect.

Kalium9• 7 years ago

That said security-minded people are often inconsiderate and horribly untactful in their approach. That needs to change. You don't need to be overly negative to point out a security issue. Something like, "Cool start, but might want to point out that it's not meant for production!" would be a lot better IMHO.

That's a wonderful idea! I'm absolutely certain that people will invariably respond quickly and reasonably to kind, compassionate, considerately made points. Especially ones that are very cautious to cough anything that might be taken as negative as a potential or a possibility.

For my own part, I've found this practice to be both exhausting to implement and highly unreliable in deployment. I'm absolutely certain that these just reflect my own failures. I'm similarly sure that you've seen infinitely better results!

After all, everyone knows that casually documenting something to the tune of "This code might not be as safe for production as it could be" will yield a reasonable level of caution in all developers.

bryanlarsen2• 7 years ago

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

quickthrower2• 7 years ago

The website gives the impression of a polished product. It doesn’t come across as a POC. Therefore I think the security concerns are valid. Someone is bound to build something with this, get users and get hacked otherwise.

scottmf2• 7 years ago

Apart from the security concerns this actually looks awesome.

laurent123456• 7 years ago

That's pretty cool to quickly put together a POC app. There should be an "eject" command that would export everything to a "real" Node application, with package.json and so on, so that the POC can be converted to a real app easily.

brillout4• 7 years ago

Check out Reframe: https://github.com/reframejs/reframe

It's a web framework like Zero Server and Next.js but everything is ejectable.

bschwindHN• 7 years ago

Or alternatively, check out re-frame: https://github.com/Day8/re-frame

It's a web framework with a well-thought-out architecture that you don't need to "eject" from.

blunte• 7 years ago

Not to sound adversarial, but configuring a web framework tends to be one of the last difficult or time consuming parts of building a web app or backend in my experience.

brillout4• 7 years ago

If you need SPA then yea it's easy. But when you need SSR it becomes a whole different story.

Now imagine you want parts of your app to be SPA and some other parts of your app to be SSR. This becomes super complex. Frameworks like Reframe allow you to do that. (I'm Reframe's author (https://github.com/reframejs/reframe).)

Admittedly, mixing SPA and SSR views in one app is uncommon today but that's because people are not aware that they can do that. This will change.

BinaryIdiot• 7 years ago

"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.

asadlionpk28• 7 years ago

Try doing the same for React (in the same express project). With SSR enabled :)

brillout4• 7 years ago

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 into that? (If at least Webpack's default source map config would work out of the box but it doesn't.) Parcel hits the right abstraction level much better.

Disclaimer: I'm Reframe's author (https://github.com/reframejs/reframe).

coolmitch• 7 years ago

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

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

franciscop3• 7 years ago

No, you cannot, not in an easy way. I've taught many people Node.js/express and they always struggle with all of those copy/pasted configuration bits. Now if I add them, I tell them something along the lines This is just magic, copy/paste it to make your app work. Some day you will understand.

Once you get used to them it's easy, but to get started it's a nightmare. I started with PHP back in the day, and even though it's hated around here the bar to getting started there is amazingly low in a good way.

asadlionpk28• 7 years ago

Exactly this! An experienced developer might take configuration and setup for granted.

I also teach sometimes and all this friction to get started just makes it harder to get into web development these days.

Waterluvian• 7 years ago

That feeling of discomfort and tinge of frustration means you're learning. I feel like this is helping people to skip over a really useful lesson.

jjcm• 7 years ago

I'll echo this. I was hired by Atlassian to join and "make prototyping better". Part of this meant enabling designers to more easily create code based prototypes.

I learned very early on that if creating something in code means learning/entering cryptic code just to start (that is, before any work gets done), then you lose people very quickly. Inexperienced developers can easily express, "Hey if I click this button and a field has the word 'bubblegum', I want a popup to show", and likely can figure out the js necessary for it. But if you say, "Ok, before you write that javascript you have to configure a package.json and install all necessary pages, but also make sure your version of node is the correct version for our internal libs", their excitement to dive into a project is ruined.

austincheney• 7 years ago

I wrote a shallow http.createServer abstraction for one of my projects that works directly from the terminal and takes a port number as its only argument. I just copy/paste this every time I need a web server. Its literally like 2 minutes of effort and has no dependencies.

renton• 7 years ago

I thought we moved away from this sort of structure as an improvement?

openbasic• 7 years ago

So... 2019's PHP?

ihassann• 7 years ago

Nice work bro. Seems pretty solid. Congrats from fellow Karachian :)

electrotype• 7 years ago

Make a RealWorld.io implementation or it doesn't exist!

https://github.com/gothinkster/realworld

juliend2• 7 years ago

Wow, that readme file is a github repo masterpiece.

yowlingcat2• 7 years ago

This is wonderful. Great antidote to toy framework fatigue.

franciscop3• 7 years ago

I did something very similar but arguably with even less configuration, https://serverjs.io/

    const server = require('server');
    server(() => "Place your Node.js API here.");

However my project doesn't have the automatic routing/installing/React, which looks great! Keep it up, I like the direction where this is going.

tazard• 7 years ago

Hey, that looks cool too. Thanks for sharing it!

gyvastis• 7 years ago

How's this different from Koa?

IceDane• 7 years ago

Who is this for? Is the goal to enable people who don't know what they're doing at all to make applications?

Maybe at a glance that is a laudable goal, but surely there is a point where, if you need so much handholding, you should consider either sitting down and learning what you need or making someone else is build it for you.

Newbies? I guess that is possible, but I personally think that actually learning to use your tools and the libraries that are available should be the goal. Handing the control of everything to some 3rd party component is eventually going to leave the beginner with issues they have no way of solving because they've never had to learn anything.

lujim• 7 years ago

Prototyping, hobbyists, people who host a site about cats and don't need 1000 extra lbs of server side weight. Spinning up a simple API to learn a new client side library. Anywhere that tooling and configuration is getting in the way of someone learning something new. Seems perfect for some uses.

jarvuschris• 7 years ago

There's a lot of value in removing all the plumbing you typically find at the start of node project to handle basic things like routing. I'm a big fan of moving all that "outside" the app

This might seem silly if all you're use to is working on some startup's big app with a dozen other people, but for small orgs that need to run small programs for a long time it's a mess to maintain that stuff over the long term and to count on lone coders in small engagements to get right.

Handing the control of everything to some 3rd party component

In the cases I describe, this ^^ is a great idea. Keeps maintenance of the common stuff in a common place. Everyone freaked out in this thread about there being a way to get at files outside the project root. Well the author fixed that in one place and now it's fixed for everyone. How many times does an error like that come up and go undetected and uncorrected when even an experienced node coder has to copy pasta so much stock plumbing for the 1000th time to spin up a small service for a small org?

hipjiveguy• 7 years ago

I for one think this looks great! Keep up the good work and don't get discouraged!

arispen• 7 years ago

I agree. Fun idea and keep up the good work!

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

Related Stories