Thanks! This also started as an experiment with the goal of being very lightweight and simple to get started with.
Looking forward to seeing your public repo, apparently you can get a great discussion going on HN by putting it out there :)
Looking forward to seeing your public repo, apparently you can get a great discussion going on HN by putting it out there :)
I guess people will need another excuse to post Veekun's manifesto.
It's not 'rails inspired' though since I don't know Ruby/Rails.
Everyone should write their own framework, no one should release it.
The reason is that by rolling your own framework, you learn the ins and outs of a number of things. It's even better if it's a framework you've derived from a functional app.
I've rolled a number of my own frameworks including one for mobile (WAP) and the one underlying my open source project. The first was never shared publicly, the second is still the core of the app.
That said, the question I have for (both of) you is: What?
- What makes your framework better than X?
- What were your priorities in the architecture? What did you de-prioritize?
- What features did you consider absolutely mandatory? What did you decide to leave out?
- What made you take the approach you did?
probably nothing. Ill be adding links to the frameworks you'd probably rather be using in the readme anyway. it's entirely meant to scratch my personal itch.
What were your priorities in the architecture? What did you de-prioritize?
Easy static page generation and header control, and reasonable security out of the box. I like to think of it as a static site framework since its primary purpose is doing the MVC process but resulting in static pages. I don't know how well it does this to scale with complex taxonomies yet but it'll run Bootstrap.
I de-prioritized elegance and abstraction to a degree. If anyone ever sees it, they'll probably think it's kind of ugly.
What features did you consider absolutely mandatory? What did you decide to leave out? Twig as the template engine and htmlpurifier. Every view is run through twig, then markdown (so even though the views are twig files they can be entirely markdown and still work fine), then htmlpurifier with a whitelist before being either saved statically or sent. So certain things like adding forms to a page and script tags and such are made purposely more difficult because htmlpurfier will just strip them out.
I left out complex asset handling (you specify .js and .css dependencies in the routes if you want them.. which is probably breaking best practice but oh my god is it convenient) and routes in closures because at the time I wanted to tie every route to a controller and method. There are no html helper classes because I wanted nothing but data going into the templates, so nothing that generates html. A lot of things are 'left out' just because I haven't gotten to them yet.
What made you take the approach you did? I couldn't stop messing around with Laravel and I realized I didn't really understand what was going on like I wanted to. I just wanted a lightweight framework that would generate a site statically and not load a bunch of libraries and whatnot if they weren't needed. Because I'm on a cheap shared server and there don't seem to be a lot of solutions that don't assume I'd be running on Heroku with unlimited bandwidth or something.