Philosophy/manifesto/whatever

[jonathanong]

Although the name is jshttp, I see this org more for anything that satisfies "tools to BYO server-side js web framework". Some definition and a vote would be nice.

[yoshuawuyts]

If I understand correctly JS-http is an org for the smallest parts of which servers are composed. E.g. a shared denominator between all frameworks, regardless of style or philosophy.

If you're writing a manifesto / philosophy about this, maybe it'd be nice to quote the Unix philosophy about code reuse and modularity. I mean: the guys make a pretty solid point, haha.

[Raynos]

Here are some example definitions.

A module is a thing that does one thing well and does one thing wholely well. A http module is a module to operate on a HttpServer, HttpRequest or HttpResponse A jshttp module is a either a http module or a module that interacts with a http module.

It's nice if jshttp modules include either things that operate on HTTP directly or modules that interact with modules that operate on HTTP directly.

For example a ratelimiter module might interact with a session module (that interacts with req/res ) and ratelimit-serialize module ( that writes corrects headers and stuff ).

All of this stuff is really hand wavey.

One thing you want to avoid is putting kitchen sink things that are related to web frameworks here that are not related to http. For example the config-chain module from http-framework does not fit here at all even though I use it as part of my web framework for consistently loading config.

[dougwilson]

A lot of that higher-level stuff would land in the pillarjs org rather than the jshttp org.

[Fishrock123]

"tools to BYO server-side js web framework"

That's pillarjs, not this. ;)

[jonathanong]

well, no. pillarjs should only be pillar itself and all its plugins/middleware. it should be a user-facing org, not a maintenance org like this. last thing users need is a noisy org with a bunch of modules they would never touch (like expressjs, currently).

only exceptions are submodules that are pillar-specific, but those should be few to none.

[Fishrock123]

pillar is those submodules, i.e. router, views, etc.

They should really all be maintenance orgs, using an org as a middleware list is silly, that's what the docs and site are for.

[dougwilson]

Though part of pillar, I.m.o., is to build your own framework. But ultimately we need to evaluate things on a case-by-case basis rather than trying to make blanket statements :) We can still generally describe stuff, but at the same time right now we are still figuring it out :)

[jonathanong]

oh i thought that was the framework, though the pillar name does make more sense as a byo framework. what was express 5 going to be called, or did we not decide on that yet?

[Fishrock123]

That is pillar.js. (I did invite you to the org also haha)

It's BYO framework with a single-file "example" framework since people like that format still.

[dougwilson]

what was express 5 going to be called

the literal "pillar" npm module. It would join the stuff together in some way for people who don't want to decide.

[jonathanong]

okay so pillarjs.github.io should represent the modules (like this org) and pillarjs.github.io/pillar should represent the framework as the successor to express 5.

where should the middleware we maintain go then? leave it in expressjs?

[dougwilson]

leave it in expressjs?

yea, until we have a plan for it. As it is, they are express-style middleware, so they make sense there currently.

[jonathanong]

okay sounds good to me!

[jonathanong]

would be nice if someone started with a pillarjs.github.io and opened issues for modules there.

would also be nice to somehow use the same underlying code to make the list of modules and badges.

[jonathanong]

oops

[dougwilson]

lol. we actually didn't get the pillar name until earlier today. i own the relevant domain names, by the way, but only to ensure they do no resolve; we want people to go to the github org web sites so people are no going to a domain a person owns :)

[Fishrock123]

would be nice if someone started with a pillarjs.github.io and opened issues for modules there.

Will do. Edit: https://github.com/pillarjs/pillarjs.github.io/issues

would also be nice to somehow use the same underlying code to make the list of modules and badges.

We could repo-utils a thing once we have the migration stuff more settled out.

[Raynos]

well, no. pillarjs should only be pillar itself and all its plugins/middleware. it should be a user-facing org, not a maintenance org like this. last thing users need is a noisy org with a bunch of modules they would never touch (like expressjs, currently).

For collaborating with others like people working on hapi or myself working on http-framework its nicer if we place as many re-usable things in a agnostic organization like jshttp

It's a bit weird to place modules or contribute to things in pillarjs since it's a bit coupled in terms of identity and branding to the pillar "framework" (successor to express).

If something is too specific to either hapi / pillar / express / koa / http-framework it should not belong here, however putting modules that belong here but feel "too high level" in pillar instead is a bit strange.

I've personally found that it's that if your going to have a meta module / "framework" (i.e. pillar / http-framework / mercury / ampersand / koa ) it's best to avoid branding individual modules under that framework. This is because meta modules only last a year or two but small focus modules last 10 years.

We should look at this on a case by case basis though.

[jonathanong]

Agree. That's why we open separate issues for each. Routing for example is always going to opinionated IMO

[dougwilson]

Right. I don't don't particularly want pillar to be another complete framework like express / hapi / koa, etc. I would like pillar to be the framework framework (so meta)--basically I would like to see pillar full of a bunch of different things like types of routers, types of layout engines, etc. I don't know, haha.

So like I was trying to envision the division like: (express / koa / whatever) -> (pillar stuff) -> (jshttp) and of course when necessary side-stepping the pillar layer.

One thing that is awesome is how we are even all talking about this :) I love how we're coming together to talk about these things.

As far as the "successor to express" thing goes; IDK. So like express was pretty bare-bones. The only thing that probably made it generally usable was that it has the res.render, otherwise it's unlikely many people would even be using it. I think most people want full-featured frameworks like sails, hapi, etc. But if those framework have to focus on building the lower-level pieces like header parsing/writing, url routering, etc., they cannot focus on the higher-level things that people want like models, realtime, etc.

The way in which I envisioned it being the "successor" was really in spirit. I wanted to see a "generator" project that people could use to like "build your own express" rather than giving them a pre-packaged thing, but IDK. I would like to see people migrate away from express at some point (to where doesn't particularly matter :) )

Of course, forgive me, @Raynos , as I do not (yet) know enough about http-framework to know where it fits in.

[Raynos]

@dougwilson your description of pillar is very similar to http-framework. It is also a framework "framework" used to build your own web apps from a bunch of modules.

It just encourages the approach of bundling a custom framework with your app rather then building a custom framework on pillar and then building your app on the custom framework.

[rlidwka]

So we have sails based on express based on pillar based on jshttp. Should we add another layer or two? :)

[Raynos]

Don't forget http and net, tcpwrap.cc and libuv

[ahdinosaur]

this is awesome. so happy to see more module ecosystems coming to life. :)

i like @Raynos's definition as it focuses the scope of jshttp on HTTP. this is similar to say, npm-dom that focuses on the DOM and stackgl that focuses on WebGL.

keeping this in mind, it may be beneficial to refine the scope of pillarjs from "modules in a Sinatra-like server-side web framework" to something more explicit like modules that do path routing, rendering, sessions, etc. with clear scope, we have a more clear understanding of the boundaries between layers above and below, plus it also focuses more on what the modules do rather than any brand.

just some thoughts. thanks for everyone here having this conversation together. i'm excited for express becoming an ecosystem of modules as pillarjs, i can't wait to see what "full-featured frameworks" can be built as ecosystems of modules.

[Fishrock123]

So we have sails based on express based on pillar based on jshttp. Should we add another layer or two? :)

It's going to be sails based on pillar using jshttp, I think. ;)

Basically pillar is a better base for all those frameworks that fit ontop of express, and maybe even ones that didn't depend on express.

And, there is the pillar module, which is basically just an example of how to do so in the form of "express 5".

[dougwilson]

@dougwilson your description of pillar is very similar to http-framework. It is also a framework "framework" used to build your own web apps from a bunch of modules.

so i've been trying to look though the http-framework module and learn more about it. it's ideas do seems to be pretty much the same as pillar, yes, which leads to if we want to join up them, or keep them separate and share in the lower, jshttp layer :) one of the main this i'm trying to make happen with pillarjs and stuff is that it all is in github orgs with multiple owners and transcends a single user. i even bought some relevant domain names so i could make sure the dns zone was left empty so people would have to go directly to the github.io page, which is owned by the org and not a single person :)

plus it also focuses more on what the modules do rather than any brand.

yes. if there is any reference to "Sinatra" it should be dropped from the pillar org :) people could make their framework "Sinatra-like" using pillar stuff, but also non-Sinatra-like, haha. we shouldn't care and should enable this.

It's going to be sails based on pillar using jshttp, I think. ;)

most likely; using express was mainly because "it was there" kind of scenario. ultimately it's up to the sails team, though :)

[rlidwka]

people could make their framework "Sinatra-like" using pillar stuff, but also non-Sinatra-like, haha

That would be nice description for a pillar project:

"Pillarjs allows you to build Sinatra-like stuff and non-Sinatra-like stuff"

:)