Giter VIP home page Giter VIP logo

heisenberg's Introduction

Heisenberg.js

A project base for building modern JavaScript applications

Please note that current Heisenberg is under very active development. Large changes may happen often until we hit V1.0.0.

Features

  • Not a framework, but a base project to help you structure your JavaScript code and files.
  • Templating built in - Handlebars is included but feel free to change engines.
  • Included: jQuery, Underscore.js and Handlebars.
  • A fully commented source to show you why it's doing what it's doing and how to build upon it's foundation.
  • The JavaScript version of the HTML5 Boilerplate

Getting Started

The best place to start is on the wiki.

Changelog

All releases our tagged and listed here on Github.

V0.9.1
  • remove cruft from gitignore
V0.9.0
  • tidied up the code
  • swapped App.Utilities.Helpers out for just App.Helpers
V0.8.0
  • went back to basics, in preparation for creating two versions of Heisenberg, Basic (this), and Pro (to come).
  • removed RequireJS, Package.json, Grunt, Node modules, Bower, and so on
V0.7.0
  • moved back to using Bower for our package management
  • use Bower grunt plugin to better control which files we pull down (avoid the issue of Bower bringing down the entire repo of a package).
  • move components folder into /app so RequireJS' optimiser can do it exactly as we want
V0.6.0
  • added grunt server task which is a good way to quickly run a local preview server
V0.5.0
  • add mediator pattern
V0.4.0
  • use pulldown for dependencies
  • add JSHint grunt task
V0.2.0
  • updated folder structure - thanks to @phuu and others for feedback on this
V0.1.2
  • added Grunt.js and requirejs optimiser task
V0.1.1
  • Added a package.json file for Node modules (Thanks @OliverJAsh)
  • Added a RequireJS build file. (Thanks @OliverJash)
  • Added doctype to HTML file.
V0.1.0
  • Initial release

Contributors

License

The MIT License (MIT) Copyright (c) 2013 Ben Howdle

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

heisenberg's People

Contributors

benhowdle89 avatar boye avatar jackfranklin avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

heisenberg's Issues

Doctype

What's with the lack of a doctype? I'd suggest <!doctype html> โ€“ is there a reason why it ain't there?

Set up Grunt 0.4

Not officially released but should probably make steps towards doing it.

Ditch CSS

@benhowdle89 there's an argument here for not having any CSS in the repo. It is a JavaScript base after all.

Decide on Grunt tasks

  • should grunt bower be part of grunt build? if not, will the install script do that?
  • add jshint to build task
  • clean up dist directory re. #37
  • anything else people think should be added to the Gruntfile

Heisenberg organisation?

I was wondering if we should move heisenberg into a new repository under a Github organisation?

The reasoning behind this is because we're probably going to end up with 2-3 more repositories related to heisenberg (such as the npm module).

Rather than have benhowdle89/heisenberg and jackfranklin/heisenberg-npm, etc, why not have:

heisenbergjs/heisenberg
heisenbergjs/heisenberg-npm

Are we able to transfer repositories over so we don't lose histories, or would we have to make a new one?

Heisenberg npm

I know in the long run we're thinking of using an npm module for generating projects, etc.

But for now I was thinking we could have one that is simply a wrapper around git clone.

So I'm in a new, empty directory and want to use Heisenberg as a starting point. I run heisenberg init and it:

  • clones this repo
  • removes the .git folder
  • runs git init to start a new fresh git repo (maybe via a flag)

Thoughts?

Tidy up the sample modules

Whilst I get the whole Breaking Bad thing, I can't help but feel that just making a simple sample module would be a better approach?

I think we could do with stripping them down a bit too as they are pretty overwhelming?

Use tags for versions

I think the npm module should download the latest version via a tag, instead of just cloning the HEAD of this repository. At the moment it's not really safe for anyone to just clone this repository because there's changes all of the time and very little has been decided. Thoughts?

Switch to Lo-dash!

Consider swapping Underscore for Lo-dash - http://lodash.com/ - which is a drop-in replacement for Underscore that performs better and is more cross-browser compatible.

See the site for more info, especially the "Resources" section which contains videos.

Server task

@PhUU we spoke of potentially adding a server task into Grunt to run Heisenberg locally?

Imagine just grunt server should be run, and it would throw it up on localhost:3000 or similar.

RequireJS Text Plugin

RequireJS has an awesome text plugin which lets us load in text files as dependencies / modules. This means we could strip the sample Handlebars templates out into one / multiples?

Thoughts?

Heisenberg Rewrite

So...thoughts? Lets get this nailed so we can work on it.

I, after some thinking about this, propose we create two repositories.

Heisenberg

  • more like @benhowdle89's original idea. No Bower, Grunt, Require. Just sample JS modules, Events, Pub/Sub, etc.
  • get started by just cloning the repository (or using the npm module - but this is optional).

Heisenberg Plus (working title)

  • RequireJS
  • Grunt, testing, JSHint
  • Bower / similar
  • get started either by cloning repo & running commands in the terminal, or using the npm module, which would set it all up for you.

Lets keep these as two repos separate.

Thoughts?

Wiki: Document RequireJS

  • link to getting started tutorials
  • explain reasoning behind using it
  • show how to use the optimised version

thoughts on testing?

with Heisenberg being an opinionated framework base project, a starter kit for testing should be included...

๐Ÿ’ญ thoughts?

Bundle with a server

Is it worth including a server with the package? For building single page apps, it's useful to route all requests to a single view but this doesn't work if you are just serving static files. The AngularJS seed does this, for example.

If this is needed I'll put it together and pull request.

Accessibility

There have been issues raised about the accessibility of Heisenberg in its current state.

Since its initial introduction, we have added RequireJS, Bower, and Grunt. However, to stay true to this project's goals, we still need to cater for users who:

  1. do not have Node โ€“ thus NPM โ€“ installed on their system (as raised by @michaelw90);
  2. are not aware of RequireJS/AMD;
  3. are not aware of Bower;
  4. are not aware of Grunt.

I have thoughts on all of these. Some of them we are obliged to fulfil, and some need to be protected to ensure we continue to support the notion of "delete key" friendliness.

I'll follow up with more of my thoughts on how we can improve accessibility with this criteria in mind. In the interim, feel free to comment with any ideas. ๐Ÿ˜ƒ

Wiki: Document Grunt

Things to tackle:

  • grunt tasks that are implemented
  • how to set up Grunt (especially as we use 0.4, which is not yet fully released)
  • how to add new tasks
  • link to specific Grunt documentation

Directory structure

I guess this is just a discussion or suggestion rather than a real issue: my directory structure of choice looks slightly different and I think is perhaps more suited to client-side JS apps. But I'd love your thoughts.

I tend to go with something like this:

/
  index.html
  assets/
    css/
    img/
  app/
    main.js
    modules/
      ...
  lib/
    requirejs/
    ...

Branches for RequireJS and other "more complicated" features

I know @jackfranklin is adding in AMD support with RequireJS, but I wanted to point out that it might be worth extending this repository with new branches for every additional layer of knowledge. For example, master would be the very basic framework, and requirejs branch would be the same but with AMD.

I was thinking this because "modern" (which this framework advertises itself as) is quite a bit more than that we have here so far. It's AMD and package management (and more?) โ€“ but the more you add in, the more it goes against the nature of this project โ€“ minimalism!

It would be great to see dozens of branches, each adding complexity, so that users can choose where they would like to start, and even learn from the differences in the code between each branch.

Plus, while I'm here I would like to suggest a branch with bower managing the vendor packages we have in here.

Just my two cents. What do you think?

P.S. good work Ben.

Cleaning up `dist` directory

Re. #18 (comment)

RequireJS [โ€ฆ] places files like app.js, helpers.js, and introduction.js into the dist (build directory) which are not needed as they are concatenated into main.js. I've always been curious as to how you should go about "cleaning up" build files like this.

How do you think this should be done? I'm new to the r.js optimizer. Any ideas?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.