
Ask HN: What would your dream web framework look like? - ralmidani
I intend to write a web framework that brings together the best ideas from server-side and client-side frameworks.<p>I am biased toward Django&#x2F;Ember, so a lot of my ideas come from there. But I know some Rails as well as some Angular, Backbone, and Knockout.<p>My ideas:<p>0) Isomorphism via a CoffeeScript-like language that compiles to JS and Python, or a full-stack Node framework written in a CoffeeScript-like language.<p>1) Folders for server, client, and shared code. And maybe more folders to build a Replicant&#x2F;Android client with something akin to NativeScript.<p>2) Support server-side rendering for faster loading in the browser (a la Ember FastBoot).<p>3) A Model which contains the definitive representation of real-world objects. DB interaction, validations, forms, serializers, etc. all derive as much as possible from the model. Model &quot;classes&quot; have field instances which, in one place, define how they fit in the database and what developers&#x2F;end-users can do with them. Inspired by Django and, to a lesser extent, Ember.<p>4) Don&#x27;t Don&#x27;t Repeat Repeat Yourself Yourself. See 0, 1, and 3.<p>5) Real-time with no need for more than one or two lines of code to opt in and make it work. New, updated, or deleted models publish automatically, notifying something like a Django class-based view, which pushes the new data to all clients subscribed to that view.<p>6) Declarative templates like Ember. But even a basic operation, such as updating a template when an attribute in the model changes, has a default (replace part of the template to reflect the new data) which can be overridden easily to get animated updates, without jumping through hoops and&#x2F;or accessing private APIs.<p>7) First-class support for indented languages such as Emblem, Sass, and CoffeeScript (or a similar language).<p>8) Free as in Freedom. Preferably AGPL, but LGPL or Apache--with its explicit patent grant--could work if a more permissive license is needed to promote adoption.<p>Your ideas?
======
jefflinwood
Also just as important as all of the above is a strong contribution to
documentation and community - easy start guides, sample web applications that
are more than just a TODO list, forums, email lists, etc.

~~~
ralmidani
Absolutely. Thanks for sharing!

------
gravypod
Nothing matters more than the programmers ability to understand what is
happening, and how to do what they want.

If you write something that does absolute magic, it doesn't matter if no one
can use it.

Make sure that everything is simple, easy to understand, and as basic as it
can be. If you do that than it will not only be a good framework, but will
also have very source code. Simplicity makes everything better.

------
dllthomas
For _me_ , the most interesting feature would be making it easy to expose
actions from the command line.

~~~
ralmidani
What kind of actions? Response handlers (edit: should have said request
handlers)?

~~~
dllthomas
"Actions" in a domain-relevant sense, not so much a technical one. I want the
framework to help me assure that anything users can do from within the web app
they can also do from a CLI client (possibly decomposed differently).

My biggest objection to web apps is an extension of my objection to
applications in general: because the individual steps of my workflow aren't
exposed to the shell, I can't manipulate, script, and compose them as I do
other sorts of actions.

~~~
ralmidani
Wow. Interesting idea. I suspect it's not currently supported because web app
developers are not expected to work at such a low level.

The closest thing I can think of is if your back-end is simply a JSON API, you
can use a tool such as cURL or httpie to make requests from the command line.

~~~
dllthomas
The shell doesn't have to be low-level. Curling the end-points directly
probably would be. A client utility could wrap up higher level actions (which
may involve hitting several end-points) with with a clean UI.

------
krapp
As simple as possible, with as little magic as necessary. Practically no more
than a router, basic response handling functions, a plugin API and some kind
of package management. Don't even ship it with a templating language or an ORM
- everything else should be up to the developer and available libraries. Let
the community do the rest.

And the package management shouldn't depend on any particular server or
repository. I should be able to mix git and svn, local and remote and it
should just work. As little of the code should be specific to that framework
as possible, in order to make migration to another framework easier.

Granted, this might not be the most fun or gratifying framework to build, but
I think it would be more future-proof and tolerant than one that just codifies
the arbitrary preferences of a Benevolent Dictator.

