I know framework do implement a specific architecture, but most of the times it's really not a constraint you have to follow. You can use what is given to you or you can do something else. It's hard to imagine how you can get at odds with a framework, especially on something as "simple" as a forum.

As for Yeoman being a bloatware, i can't say I've used it before but as far as I know and knowing people who use it, size/usefulness ratio aside, I wouldn't expect said size to present a problem at some point, unless of course you have serious space restriction on your sever.

So even ditching Yeoman, would you use Grunt?

It is precisely because I want a simple forum that I would rather avoid bringing external dependencies into the mix.

It's not about being "at odds" with the entire framework.  It usually starts with disliking a small function or feature inside the framework, and fixing it is never a small undertaking.  I've experienced this at least twenty times in using just three frameworks.

I said "feels" like bloatware; I did not say it "is".  To me, bloatware is anything that takes longer to learn than to solve the same problems I might have used it for, or anything that aims to solve problems I don't have.

Please let me explain why I am not in favor of yoeman.

First, yoeman is a helpful tool for distribution and local web development.  Thanks to virtual machines, I have not had to do local development in over four years.  Virtual machines are portable, allow me to reduce crap I install on the host machine, and ensure compatibility with a matching production environment.

I would say the ease of use factor is in perfect balance against actual needs.  By using yoeman with the prebuilt generators you give up control over the default architecture, resources, and resource layouts used.

If you want to maintain that control you'd have to write a generator.  By the time I write a generator to handle trivial tasks like creating folders and downloading boilerplate files, I could have already done it manually, or written a bash (or even nodejs) script to do the same thing.

There is a built in watch system in nodejs.  Without any extra tools I can already automate unit tests, minified code, and restart/push changes the node process when changes are caught.  However, I generally wouldn't want to be running unit tests unless I am watching, and we only need minified files when pushing to production (never for development).  Further, these actions can be done with extremely simple commands manually.

I am not concerned about disk space.  My concerns are for files being requested over http that slow down the users experience, and the principal of having a bunch of extra crap I am not and never will be using sitting on my disk "just because they come with X".

---

Will I use grunt?  Probably not.  Unless you have a specific use case you think justifies the need for it.

If I find a specific need, or if you really want to have it for your purposes, I may consider creating a yoeman generator.  However, so far the only useful feature yoeman offers me is the package downloader.

I will probably use bower, if it allows me to lock package versions and specify where to download them to.

I will most definitely be writing unit tests.
My project will point to a second repository with the node forever & monit setup I am using to run node.
I am still looking for tools that support db migrations, if you happen to know of any.

Posting another status update, plan to try to keep it up at least once a week to keep you all appraised of what's happening.

---

Personal Agenda:

Over the weekend I expected to receive a new motherboard and had intended to build a second platform.  I received the board on Monday and began part swapping; sadly my primary machines motherboard shorted and stopped working properly.

This machine handled several jobs, including multimedia, file server, web server, and multimedia system.  Fortunately I did not loose any data.  However, I have not had internet at home basically all week.  Further, my development environment was unavailable.  The good news is my new hardware is working, and though it is not finished, I have internet and a solid linux installation to work off of.  This will be excellent for development.

Also, a heads up that I will be gone from next saturday all the way to January.  I will check in if I have time, but I may not post any further updates until January.

---

Project Update Details:

I asked the nodejs team where I work a bunch of questions.  They use grunt, haven't needed bower, but have considered yoeman.

Due to the internet/PC troubles, I haven't had time to hash out and test my nodejs `forever` server structure, but I do intend to build a nodejs forever stack that will keep the site alive on the server.  That will probably be the first "external component" I release (external as in a separate repository).  I also want to investigate push-state methods to update the client side from the server side on changes without waiting for a refresh.  AFAIK the only methods are with some form of AJAX or WebSocket communication, but there may be another feature I have overlooked.

Investigated CSS, JS, and HTML minification tools, and methods.  For example, to prevent caching the use of timestamps is used on development platforms, but with the right tools these could be replaced with "versions" which would only change when the code has changed, making it universally acceptable to use in both production and development.  CSS minification and optimization would be helpful as well.  Also, apparently some JS minifiers now build code maps, which allow debugging to display the readable code and not the minified code.

Given that grunt minifiers now support minified code debugging, I will probably be using them.  This depends on whether they can push results from automated processes to log files, and whether they (or the minifiers) can append a "version" code to the resources.  This comes from newer concepts regarding cached resource management.  Usually when a user visits a website their browser downloads the files and keeps them in memory by their path.  This means the next time a page loads that asks for those files, it checks for a local copy first.  In development the files are changing often, so we would normally use timestamps.  However, with automation it should be possible to update a version code, which can be appended by the project instead, and fix the caching issues in both development as well as production.

I am still on the fence with yoeman, but if generators are easy enough to build I will add it only so that I can ask even non-developers on the forums to test things, since it would be very easy for them to setup.  The nodejs team explicitely said they don't use it because no current generators have the right set of tools (always too many, or too few).  They did say if time allowed they would create a generator.  I feel the same on that matter.  For myself and anyone who wants a full-stack, I will be adding a vagrant and puppet scripts to automate setting up a VM with similar specs to the actual web server we use.

I have confirmed the nodejs `csso` package for css minification and optimization.  I am still investigating whether I want to try the latest bootstrap.  It would certainly get us up and running faster than rolling my own CSS, but I'll have to experiment and see whether I like the code-base (because the previous iterations I loathed).

I intend to use jquery with CDN/fallback (eg. try to load from google, since most users have a cached copy, or use our local copy if they don't).  The nodejs team pushed angular, but I am still weighing the pros and cons and don't have enough to go on to make a decision yet.

Angularjs is a templating system for the frontend.  The benefits being great UI and fast client-side generated contents with easy management.  The downside is they use their own HTML templating code, and don't accept alternatives.  I am still planning to use jade templating, since it is very humanly readable for moderately simple UI elements.  This would make it much easier for non-developers to create or modify themes.  It also means the code stays that much cleaner.  Angular and jade don't mix, so I'd have inconsistent front and backend templating, or I'd have to do some magic in between them somehow.  Since I have not mapped out the UI extensively just yet, I don't know whether the benefits angular offers are worth the tradeoff.  Additionally, angularjs is 100% JS client-side, which means it has very little (if any) search engine optimization.  Fortunately because we are using nodejs, we might be able to overcome the angular limitations with SEO, by optionally running server-side angular to generate the initial components.  This would allow incompatible browsers, people with "nojs" plugin on, and crawlers to view the site.


I have also focused many hours of thought on two specific components designs.

The first is the routing engine.  Traditional routing is "path based", which used directory paths on the server.  With the way modern websites work, this is entirely unnecessary, and allows for a far more dynamic approach.  Despite this, most routing systems are still designed using that concept.  My thoughts are to build the router as an entirely independent component that parses the "route" as key/value pairs.  This set of data would then be stored per request, and used to decide what to do on the server-side by the various components.  This makes it really easy to add and handle new routes for new packages and modules, as well as separate the routing process entirely from the rest of the code.

The second component is the parser and it has been incredibly challenging.  The current site supports bbcode, and some custom tags.  Ideally I want to support those as well as [markdown](http://daringfireba...t/projects/markdown/).  Initially I had considered a simple set of regex rules, but after a bit of contemplation I realize there are numerous problems with that approach regarding nested tags (eg. having a link inside a link inside a link would be incredibly borked).  So I have spent upwards of 26 hours researching LALR (Look Ahead Left Recursion) parsers, and how to build them.  The benefits of this method would be (ideally) error-free parsing and easy to modify or add new grammar-rules.  So if someone asks me to add support for a new tag, it'd literally be one line of code.

Unfortunately I don't have a solid understanding of how compilers process, so almost all of the documentation looks like foreign gibberish (it's probably how everyone here feels when I paste code snippets).  I expect this will be one of the toughest components in the system to build.


That basically summarizes what I've been doing since my last post.  There is still much to do, most important will be creating appropriate maps and diagrams of the project.  These will help when I reach a point where I can assign components to other interested developers in our community.

---

Questions for the community:

I would like those who are interested to take a look at [jade](http://jade-lang.com/) and then at [angularjs](http://docs.angularjs.org/guide/templates) templates, and share your opinions and preferences regarding them.  Is one easier to read/understand?  Which would you prefer to look at if you had rights to modify the site theme?

Does anyone have any specific features that they definetally want to see added at launch.  Preferably anything I have not already posted in this thread (including the compressed files).



Toodles~

Casey

Hello Everybody,

The holidays came and went; hope everyone had a good time.

I'm here to post regarding the state of the project.


As I explained at great lengths in the last post I am working on several parts of the project, focusing my attention towards the more difficult components first.

- I'm still working on the parser.
- Running through theoretical routing system to identify potential flaws
- Testing the daemon server components (the thing that'll keep the forum running)
- Researching package management architecture


For me the holidays mean over half a month of lost productivity, but now that it's over I can continue to move forward.  Or so I had hoped, one of my primary development machines is down for maintenance (the motherboard failed and is in the mail for RMA).

So, I have been trying to work on simple tools and support components while I wait for that to return so I can reconfigure it.

I hope to post more progress in the coming weeks.