Having proper components is a big win. However, it seems it requires a command line dependency to the build app, which would be nice not to: http://ojjs.org/docs.html#file-types
Author here -- Just to clarify OJ is a javascript library (oj.js) with only one dependency jQuery. It doesn't need specific file types to work and the files types in the docs are just talking about the (optional) command-line tool -- basically a static site generator to make simple sites (github pages) easier to make.
Well, it's only 11 000 lines of js... Plus Backbone, plus jQuery, plus underscore, plus ace. Loading the source page takes about 15s on my computer... I'm not sure I would like my index.html to like this https://github.com/ojjs/ojjs.github.com/blob/master/index.ht...
Yes, it seems like added complexity and reduced performance for uncertain benefit.
The whole point of HTML and CSS is to be declarative, non-procedural ways of specifying presentation and UX behavior. The rationale is that designers writing CSS rules is safer than developers writing Javascript code -- for those cases where the desired result can be achieved with either approach.
So why turn back the clock and go back to messing with code and debugging it? Unless I am missing something, heavy-weight pages with potential for bugs does not seem like a win.
The goal for OJ is create reusable UI building blocks. So I agree completely that keeping sites simple and declarative is the way forward. I would argue though that if the abstraction well reasoned it doesn't matter if it is in HTML or in JS. It still simplifies things for the programmer and maintainer.
Or another way to say it -- Imagine you can insert a YouTubeVideo as simply as you can insert a div. If that YouTubeVideo component is well tested, then you are actually saving your self time and will make a more robust site.
could be great if i could describe the reusable UI building blocks in a markup language, do their formatting separately with style sheet fragments and add a simple scripting language for actions and animations.
Web Components are already here and they're part of HTML5 itself. What does this do to differentiate itself? To me, at first glance, it looks like a dead project already.
Natively, on most evergreen browsers, mutation observers and a limited shadow-dom on chrome canary. The polymer project gets you all the way though, check http://www.polymer-project.org/compatibility.html.
HTML is a language for describing documents, right? The way I see it, there is an issue with HTML today. These days, many web developers are now exploring alternatives to a documents-based paradigm, and gearing their apps toward being "long-lived", while retaining the URLs and graphical support that modern browsers give us. Ember is a great example of this, there's very little markup you actually have to write when using Ember views and components. I don't really build "web sites" anymore, I build "web applications" which are typically one page but include all of the application's contents within that page. They do act the same, but are coded in wildly different ways.
Don't get me wrong, I like HTML and I'm not trying to disrespect what was arguably the first foray I had with "programming". But if we are intending to make the web into something more along the lines of a massively distributed application runtime, rather than a repository of documents that anyone can access, where does a document markup description language fit into all that? When developing some (kinds of) applications, I feel that HTML only serves as an obstacle, rather than a means of helping me make the app. I feel like I do most of my "real work" in CSS and JavaScript.
Applications are still, in essence, a type of interactive view hierarchy of document. The web can serve up both types of data: document-based (e.g. Wikipedia) and application-based (e.g. Gmail). Being able to have a core toolchain of three inter-related languages that can communicate with each other that you can use as required should be the final goal. For instance, if you're writing a web application, you could only use CSS/JS, and if you needed to write a very simple blog, you could use all three, or just HTML and CSS.
Having more options never hurt anyone. Better JIT of JavaScript code would break pure JS open, allowing full apps to be written without language fragmentation. Those who will still require stylesheets can use them as they wish. It's a win-win situation on both ends.
I agree with your comment that HTML by itself is insufficient for a rich user experience. But my post talked about both HTML and CSS. These two, plus the minimum amount of Javascript code necessary to deliver a rich experience.
Nowadays, there's a lot that can be done with modern CSS that in the past required Javascript code -- from dynamic menus to 3d effects to responsive web design. This is a good thing.
Code is a breeding ground for bugs (especially dynamic code with callbacks, evals, unusual inheritance model, unconventional scoping rules, etc) in a way that declarative rules are not.
I think the web will always be more about delivering content, rather than manipulating data. Apps are all about data, documents are all about content. HTML and CSS are not fading away, they are actually getting bigger, and breaking into the desktop. I love javascript, but its more likely of being replaced by another scripting languange to work with HTML and CSS, than actually being a replacement for HTML & CSS.
The reason this is happening at all in the first place is because html / css / js is the only platform agnostic toolkit. Everything else lacks support somewhere, and the big businesses behind technologies will actively avoid supporting someone elses otherwise cross platform framework.
Same thing with dynamic languages. You cannot write a Java, Python, or Ruby app and expect it to run on any device. Just doesn't work when you need to also distribute the runtime framework on a per platform basis.
Similarly, you have semi-portable C# and C++ through Mono and Qt that reach pretty much every major platform (the primary limiter is ios being so locked down) but they both need to do ugly repackaging of their entire toolkit runtime and framework that has to somehow jump through hoops to get installed locally whenever you try to install such a program.
But you can expect html, css, and js on everything. And that is why everyone tries to stick completely tangential computing techologies (html is not a widget toolkit) and hope for the best. Because it is the only write once, run everywhere where the run everywhere actually happens, even if your site ends up being double in size for mobile and desktop versions or reactive with tons of overhead in element scaling, plus all the conditionals for old versions of IE, having to import require.js or something to check for feature compatability, etc.
But you can work with that. You can write megabytes of JS to try to weasel around the mess. There is literally nothing you can do to get a python app running on average joes iphone.
I really hope qml can take off in a big way, and become a standard of some sort. It is in my experience the portable ui toolkit for actual applications that is portable and looks native since 5.2, and it even lets you script it in js so you never have to compile anything with a qmlscene binary. And it is designed ground up to have any resource local or networked.
Just to clarify -- The only dependency of oj.js is jQuery. Clearly if you want to use Backbone for model binding it has an Underscore dependency and if you want to use the AceEditor plugin then you will need Ace. So don't think you need all of these files to use OJ!
Also just for those who didn't realize, this is the initial release of OJ and was written by just one dude. As people start using it and a people give feedback it is just going to get faster, smaller, and better. Let me assure you perf and filesize are big priorities, as is better Express and Node templating integration.
I agree, also I personally prefer the idea of having things separate, HTML for the structure, CSS for the style, and JavaScript for the behavior. You can create very clean and neat pages like that especially if you don't mix each technology e.g. keep everything separate in different files..
I am however open to new ways of doing things so I will keep an eye on this, but I must admit, that index page looks a lot more daunting to edit than a normal HTML page, especially if you are not familiar with JavaScript.
Except CSS sucks for styling. You can't even make a "scroll to top button" disappear with CSS because it doesn't know if the document is at the top. CSS is missing a ton of things.
I mean I want that button to disappear when the page is already scrolled to the top. The scrolling up part I'm fine with making with JS. I just don't feel right about attaching a scroll handler to have a very unoptimized implementation of such a thing since that scroll handler will fire EVERY SINGLE SCROLL. But the browser could optimize away "is document at the top" CSS calls by knowing we scrolled down (and by definition we can't be at the top then).
This would be terrible from a performance perspective on mobile. Not because the phone executes JS slowly (it might, but that's not issue). The problem is the network latency around downloading the initial html (whatever little html you need) and then sending a further request to download the JS.
Love the concept, but the site itself (which I assume was built using the framework) is visibly laggy (in Chrome, on a MacBook Pro) - I'd be worried about using this for anything where performance was important, and for mobile (esp Android), it would probably be too slow to use. :-(
The next two big pushes are performance and Express (server-side) support. From my own testing OJ compiling, rendering, and DOM manipulation are actually pretty fast. As for the perf issues I am seeing (especially on mobile) I think they are at least partially caused by creating 40+ AceEditors with syntax highlighting and dynamically loading iframes like YouTube videos and TwitterButtons.
That said, lay all the perf blame on me! I can promise it will get better -- though in my defense this is the first release after all. Literally no one had heard of OJ until yesterday=).
Uhhh...shouldn't the site itself be built using the framework it advertises? Because the page structure and styling is all there even with JS turned off.
The site definitely was written entirely in OJ=). What you are seeing is that OJ, since it is just JS, can be run server side as well as client side. Server side it generates HTML/CSS (so it renders with JS turned off), but client side it renders directly to the DOM for faster templating, and automatic event binding.
The tool for server side static site generation is available in node npm. You can install it with `npm install -g oj`. Example projects can be found here: https://github.com/ojjs/oj-examples
Very interesting. Its become dogma that the markup and event handlers should be separate (for example you never add an onclick html attribute to anything). There are many good reasons for this. But I suppose if you think of this kind of like t ejs templates or something, its not so bad. Seems like an interesting way forward.
My understanding is that screen readers read from the DOM and update their buffer regularly, so as long as you're doing your rendering via the DOM, and not by drawing to a canvas or something weird like that, it won't really matter.
There's actually a lot of weirdness with certain bits of DOM events and screenreaders, with some portions updating more often than others. You'll run into situations where some updates will fire, and others won't unless your careful, and use ARIA tagging properly.
Since OJ can render server side it should come down to people as the HTML/CSS screen readers know and love. One way to think about OJ is as a fancy new Jade-like templating system. If screen readers work off of Jade (and I believe they do) then they should work off of OJ as well.
That I can understand. I think the biggest thing that was rather off-putting about this project is that it seems that you're selling it as throwing Javascript blobs to the client to render, instead of as a primarily server-side templating system, which makes a lot more sense. However, it does lead to a request to put in support for ARIA tagging ( http://www.w3.org/WAI/intro/aria ), because if anything, baking accessibility support like this into a templating language makes it easier for people to reach disabled people who want to view sites.
I've got to apologize for the harsh tone of the original posting. I have a few friends who are either legally or totally blind, and have had to help them try to find software that is reader-compatible so they can interact with the world around them. So seeing the "everything is dynamic" ability sold as the big reason to use this templating language, and knowing that readers can get confused if there's a lot of weird actions going on with the DOM, made me frustrated that there was yet another tool made that will further alienate these people, and make it harder to use one of the most awesome tools made for communications. Too many people take a path that is essentially "fuck the blind", which is just saddenning.
All benefits to having a CSS file are completely lost using this method, in addition to the aforementioned performance hits. Could be cool for creating widgets and forms on the fly, but would definitely not recommend creating an entire site, let alone a webapp of any size or scale, using this tool.
Not really sure what problem this is trying to solve. I am more enthused about the potential of Web Components, shadow-dom etc. [1] Take a look at Polymer [2]. By abstracting away the concept of the contrived set of HTML Elements we currently have we can create new 'complex' elements/components while retaining consistency with the rest of the DOM API.
What problem is ojjs solving and what are the trade-offs?
For me personally, the design principle of "separation of concerns" has always worked well, especially in a team environment. Having a pure designer (on photoshop or illustrator), then an html/css expert for coding pages and finally a programmer for adding dynamic content works out as a nice pipeline for web development. With ojjs, the programmer and html/css person would have blurred lines separating their responsibilities. It is a cool project, but it seems like a step backwards to me. Maybe it's just a step sideways or a better way of doing things for a team consisting entirely of programmers.
The goal of these types of systems (react.js essentially does the same thing) is to fully abstract away the need for direct HTML/DOM manipulation.
Now it's possible that the layout of the current browser DOM represents ultimate perfection and we will never improve upon it. However, it is more likely that we will find some way to come up with a better design for the DOM in the future (i.e. new types of nodes, node attributes, member functions, or some sort of entirely new data structure) and these types of frameworks allow us to experiment with new DOM ideas. With oj.js or react.js you could write to this "new DOM" and the library will project changes back to the legacy DOM.
Author here=). OJ is trying to solve the View layer by creating objects that act like website building blocks. So you can insert a YouTubeVideo or a TwitterButton as easily as you add an img or a div. Check out the plugins: http://ojjs.org/plugins.html
But to your question should all CSS be in JS? I'd say no, that wouldn't make sense. Clearly site level CSS should remain in a file and can be just included in a link tag normally.
The CSS being moved into JavaScript would be just that CSS used by the objects. This is how OJ Objects have no dependencies. The CSS for the YouTubeVideo, or Tab control, or the TwitterButton is included in the objects themselves. So definitely imagine still using CSS as you do now, but pulling out only the css needed for the reusable components into OJ Objects.
This approach creates multiple sources of truth for how elements should look, and in general I would avoid it - in the same way that I avoid using the style attribute or <style> tags.
For structure (the meaning and content of each element), use HTML. For presentation (e.g. colors, fonts, transition appearance), stick to your linked stylesheet. If you need to modify behavior (e.g. what happens on a given event), do that in a Javascript include.
To be fair, so does Twitter Bootstrap, with its use of classes like "pagination-centered" - but even that's an antipattern. I tend to agree with etj's approach.
It really depends where you're coming from. For the kind of sites that prevailed maybe five years ago, you could separate HTML and CSS quite neatly and JS was a minor element used to add some effects. But these days you're starting to get web apps etc. with very rich interactivity; and once you're past a certain level of complexity it's inevitable that you'll end up modifying lots of HTML and CSS from JS. So if you reach that point then you can efficiently make JS your main (or even only) source of truth.
Ten years ago, we were all tempted to put <style> tags in the HTML "in order to have the entire website in one place." As site complexity grew, we realized we needed to start separating components that had distinct roles. If I'm changing a font site-wide, I don't want to scroll through lines of totally unrelated copy to get to my styles. I want completely separate files that only need to reference each other (via classes and ids).
I am a huge fan of AngularJS, because it's essentially following the same separation pattern. It uses references (like ng-model, ng-controller, etc.) to attach elements to associated interactive behavior, but doesn't actually interfere with the structure of the page.
Things like fonts can be defined at a high level by higher-level css tags or classes. I usually use less instead of direct css, so for me I'd just throw in an import in each view's less file to get the default styling applied, or I'd just have basic font styling done at a higher level in css so at the level closer to the actual class, I'd only need to apply tweaks as needed.
The solution is very similar to GWT, Google's ugly step child. Why ugly, because it uses Java... hiss! Boo! Yet it does make every optimization under the sun and boils it down to JS.
Using JS to insert CSS, DOM nodes, and more JS is becoming pretty standard now. ExtJS and GWT led the way seven years ago, and frameworks need only dumb it down more to gain popular acceptance. I've been on teams that made award winning sites with GWT, but you had a steep learning curve. Perhaps OJ can overcome that.
Have you ever used ExtJS? ...I have had the displeasure of developing with it at a large financial institution...it is madness...everything is a JSON object and what ends up happening is a mixing of concerns...putting logic, and layout in the same place.
ExtJS didn't lead shit...there is a reason hardly anyone uses it.
GWT I am not personally familiar with, but if it is at all like ExtJS I want to stay AWAY as much as possible.
> ExtJS didn't lead shit...there is a reason hardly anyone uses it.
One major reason is it's just so freaking large and unruly to do anything simple. It's one of the few frameworks I've used that even after moderate use, I still had to keep the docs open on one screen even during routine development. The error messages weren't very helpful, either.
I did use it for a large project over about 14 months. You do need those docs open and since Sencha's doc servers were always overwhelmed, they suggested you run your own locally ;)
Even so, the GWT creators ended up recognizing the value of presentation markup and introduced the UIBinder system (HTML markup + XML for custom widgets), which arguably made my life a whole lot easier when I was working on a moderate-sized GWT codebase. It's definitely better compared to mucking around with Swing-looking code soup.
GWT-P takes this a step further with completely isolated layers (MVP) so that you can easily make permutations of your app bound to a Tablet, Mobile, and Desktop set of Views very easily. I've been using it a year now and love it.
You are right, it doesn't have to. But there are a lot of newcomers to front-end web app development (either moving from other technologies, or new to dev altogether) that might think this library is fit for all sorts of projects and businesses.
That being said, this library does try to solve a problem, it's not useless. In my opinion, it's just not the right tool.. yet.
"Is there something wrong with using HTML and CSS?" I think yes and there is room for improvement to both but I don't think this is the correct solution for the problems.
I agree with this. I didn't mean to make it sound as if HTML and CSS were perfect. There is always room for improvements. For example, with CSS you now have the option to use LessCSS or SASS.
This is a good question. I think when writing websites you will always need to know how HTML, CSS work. It is just part of job=). What OJ is trying to do differently is make parts of your website self contained into objects.
So think more, what if I could bundle a part of my website into ShoppingCartView, or HeaderBarWithLoginView? It doesn't remove the HTML and CSS it just simplifies how it is created because OJ Objects create themselves, and once created they modify themselves. Clearly to write these objects you will still need to use and know HTML and CSS, but this provides a different way of encapsulating things.
I like the idea even though I am not a JavaScript developer per se. The examples are fun to play around with. It hides so much on the backend that I definitely would be worried about performance. Fun stuff.
Pretty much everyone's had the idea that, since HTML is a structured markup language, you can "simply" represent it in whatever language you're working in. It's great when you're a noob & want to make something ideologically pure.
It just turns into a giant pile of unmanagable shit if you try to extend it out to anything remotely resembling a real world application. Even a simple layout like HN would require an incomprehensible mess of nested objects/s-expressions/functions if you chose to abstract the raw HTML away. This is why everyone that actually develops web applications resorts to templates.
The big issue I have with this approach is that you'll eventually need to do one of the following: hire a designer that can javascript (rare); hire a javascripter that can design (rare); sit and tediously convert your designer's static html and css line-by-line into javascript templates.
It's not impossible to be an expert graphic designer and web developer, but they are both extremely deep disciplines and people with the dedication, inclination, and aptitude for both are few and far between. Unicorns, etc...
This is fine for one-offs and side projects, but trying to build large project around this seems like an unnecessary extra layer of complexity (not that the current standard isn't complex, it's just relatively entrenched, for better or worse :)
My thoughts exactly, word for word. If you have ever built a UI heavy app, you would know how important it is to have the separation between html, css and js. It's not just about putting them in different files, it's about the context. It's separation of duties.
Agreed. Universities need to start offering history courses on software development explaining why certain approaches were left behind. HN is full of "new stuff" that is just old stuff that we moved on from.
Thank you for reading the site so closely you actually noticed=). The side-effect notation I absolutely cringe inside for, and this (along with the jQuery dependency) probably took the most soul searching.
What it came down to is this behavior leads to a really nice syntax inspired by the excellent coffeekup js templating language (http://coffeekup.org/). The key is you can't really do computation or logic in anything but a function so using functions for nesting elements leads to elegant code. For example you could generate `li` tags inside of a `ul` tag: ul(function(){for loop{ li(...)}}).
That said, you don't have to use the functional notation to use OJ. All the functions and plugins support an _ variant (_YouTubeVideo, _div) that don't emit, and in addition everything in OJ can be written with a list syntax I call OJML. The syntax looks a bit like lisp and is actually what the functions, plugins, and css are all generating: [div, {'class':'my-cls',[YouTubeVideo,'url/to/video']].
Stuff like this is useful to an extent but not when you go so low level as to generating individual divs, ol and spans like this.
For example, it makes sense to have a Javascript class such as "ShoppingListView" that takes care of rendering a shopping list via a template that it references. A component like a shopping list is coarse grained enough to be styled and designed on its own (by designers) and then stuck into a template (by designers) that the Javascript developer can then use and populate in code.
oj just takes us back to the tedious GUI development of Swing style frameworks. It is unfortunate that some people in every generation forget what the previous generation has already learned.
This is actually exactly what OJ is trying to solve: creating your own helpful objects to make reasoning about your site. The plugin objects are just a bonus!
So ShoppingListView would be a powerful object that you could test and reuse. For example in the ojjs.org site I have an object called TryEditor, which does the live compiling examples. Clearly this isn't a plugin people will want (though it is made with the AceEditor plugin, which is pretty darn useful!), but it helped me to abstract it easily so I could use it, well, pretty much everywhere=).
Another way to think of it is imagine you were making Gmail. It would be helpeful to have an object handle EmailView, LabelView, and FriendView. These things are tied to data but wouldn't it be easier to interface with them as an object interface (addEmail, archiveEmail), then with direct DOM manipulation?
Indeed, that is actually how my project (strut.io) does it.
IMO you'd get a better reaction if you put a large chunk of your Plugins page on your main page. The "plugins" page better illustrates the purpose and vision of OJJS. The example on the main page is so low level it turns people off.
That being said, I still think the bulk of the "markup" should be in markup and reside as a template for your "plugin" or component to use.
So you have an EmailView component but with an EmailView template file as well. The EmailView is instantiated and manipulated in Javascript but it still has the benefits of markup via its template file.
Thanks for the suggestion about the plugins. I think you are right they aren't emphasized enough=).
As for separating templating from the View it is a good point. In OJ you can use functions to create templates (or partials) since everything is just code.
I did find the unification of structure (HTML) and code (JS event bindings) quite helpful because this way the code that needs to find the HTML to bind an event is the very same code that created it. This removes the need to have class names / ids just so you can refer across HTML/CSS/JS boundaries.
190 comments
[ 5.0 ms ] story [ 226 ms ] thread*HTML & CSS
Having proper components is a big win. However, it seems it requires a command line dependency to the build app, which would be nice not to: http://ojjs.org/docs.html#file-types
Check out this JSFiddle to see how the dependences work: http://jsfiddle.net/evanmoran/c3Reb/
(Notice that OJ doesn't need HTML or CSS!)
The whole point of HTML and CSS is to be declarative, non-procedural ways of specifying presentation and UX behavior. The rationale is that designers writing CSS rules is safer than developers writing Javascript code -- for those cases where the desired result can be achieved with either approach.
So why turn back the clock and go back to messing with code and debugging it? Unless I am missing something, heavy-weight pages with potential for bugs does not seem like a win.
Or another way to say it -- Imagine you can insert a YouTubeVideo as simply as you can insert a div. If that YouTubeVideo component is well tested, then you are actually saving your self time and will make a more robust site.
And then we can have laymen code the templates and styling because it will be so simple.
It will be glorious!
Don't get me wrong, I like HTML and I'm not trying to disrespect what was arguably the first foray I had with "programming". But if we are intending to make the web into something more along the lines of a massively distributed application runtime, rather than a repository of documents that anyone can access, where does a document markup description language fit into all that? When developing some (kinds of) applications, I feel that HTML only serves as an obstacle, rather than a means of helping me make the app. I feel like I do most of my "real work" in CSS and JavaScript.
Applications are still, in essence, a type of interactive view hierarchy of document. The web can serve up both types of data: document-based (e.g. Wikipedia) and application-based (e.g. Gmail). Being able to have a core toolchain of three inter-related languages that can communicate with each other that you can use as required should be the final goal. For instance, if you're writing a web application, you could only use CSS/JS, and if you needed to write a very simple blog, you could use all three, or just HTML and CSS.
Having more options never hurt anyone. Better JIT of JavaScript code would break pure JS open, allowing full apps to be written without language fragmentation. Those who will still require stylesheets can use them as they wish. It's a win-win situation on both ends.
an email message is a document too.
An email client is not.
Nowadays, there's a lot that can be done with modern CSS that in the past required Javascript code -- from dynamic menus to 3d effects to responsive web design. This is a good thing.
Code is a breeding ground for bugs (especially dynamic code with callbacks, evals, unusual inheritance model, unconventional scoping rules, etc) in a way that declarative rules are not.
Same thing with dynamic languages. You cannot write a Java, Python, or Ruby app and expect it to run on any device. Just doesn't work when you need to also distribute the runtime framework on a per platform basis.
Similarly, you have semi-portable C# and C++ through Mono and Qt that reach pretty much every major platform (the primary limiter is ios being so locked down) but they both need to do ugly repackaging of their entire toolkit runtime and framework that has to somehow jump through hoops to get installed locally whenever you try to install such a program.
But you can expect html, css, and js on everything. And that is why everyone tries to stick completely tangential computing techologies (html is not a widget toolkit) and hope for the best. Because it is the only write once, run everywhere where the run everywhere actually happens, even if your site ends up being double in size for mobile and desktop versions or reactive with tons of overhead in element scaling, plus all the conditionals for old versions of IE, having to import require.js or something to check for feature compatability, etc.
But you can work with that. You can write megabytes of JS to try to weasel around the mess. There is literally nothing you can do to get a python app running on average joes iphone.
I really hope qml can take off in a big way, and become a standard of some sort. It is in my experience the portable ui toolkit for actual applications that is portable and looks native since 5.2, and it even lets you script it in js so you never have to compile anything with a qmlscene binary. And it is designed ground up to have any resource local or networked.
Also just for those who didn't realize, this is the initial release of OJ and was written by just one dude. As people start using it and a people give feedback it is just going to get faster, smaller, and better. Let me assure you perf and filesize are big priorities, as is better Express and Node templating integration.
Congrats on the release, I wish you luck for the rest!
I am however open to new ways of doing things so I will keep an eye on this, but I must admit, that index page looks a lot more daunting to edit than a normal HTML page, especially if you are not familiar with JavaScript.
Pagespeed goes into this a bit here: https://developers.google.com/speed/docs/insights/Prioritize...
That said, lay all the perf blame on me! I can promise it will get better -- though in my defense this is the first release after all. Literally no one had heard of OJ until yesterday=).
The tool for server side static site generation is available in node npm. You can install it with `npm install -g oj`. Example projects can be found here: https://github.com/ojjs/oj-examples
I've got to apologize for the harsh tone of the original posting. I have a few friends who are either legally or totally blind, and have had to help them try to find software that is reader-compatible so they can interact with the world around them. So seeing the "everything is dynamic" ability sold as the big reason to use this templating language, and knowing that readers can get confused if there's a lot of weird actions going on with the DOM, made me frustrated that there was yet another tool made that will further alienate these people, and make it harder to use one of the most awesome tools made for communications. Too many people take a path that is essentially "fuck the blind", which is just saddenning.
[1]: http://www.w3.org/TR/2013/WD-components-intro-20130606/ [2]: http://www.polymer-project.org/
They also have some repositories for ready to use webcomponents like x-registry [2] or brick [3].
[1]: http://www.x-tags.org/ [2]: http://registry.x-tags.org/ [3]: http://mozilla.github.io/brick/
For me personally, the design principle of "separation of concerns" has always worked well, especially in a team environment. Having a pure designer (on photoshop or illustrator), then an html/css expert for coding pages and finally a programmer for adding dynamic content works out as a nice pipeline for web development. With ojjs, the programmer and html/css person would have blurred lines separating their responsibilities. It is a cool project, but it seems like a step backwards to me. Maybe it's just a step sideways or a better way of doing things for a team consisting entirely of programmers.
https://en.wikipedia.org/wiki/Separation_of_concerns
Now it's possible that the layout of the current browser DOM represents ultimate perfection and we will never improve upon it. However, it is more likely that we will find some way to come up with a better design for the DOM in the future (i.e. new types of nodes, node attributes, member functions, or some sort of entirely new data structure) and these types of frameworks allow us to experiment with new DOM ideas. With oj.js or react.js you could write to this "new DOM" and the library will project changes back to the legacy DOM.
But to your question should all CSS be in JS? I'd say no, that wouldn't make sense. Clearly site level CSS should remain in a file and can be just included in a link tag normally.
The CSS being moved into JavaScript would be just that CSS used by the objects. This is how OJ Objects have no dependencies. The CSS for the YouTubeVideo, or Tab control, or the TwitterButton is included in the objects themselves. So definitely imagine still using CSS as you do now, but pulling out only the css needed for the reusable components into OJ Objects.
For structure (the meaning and content of each element), use HTML. For presentation (e.g. colors, fonts, transition appearance), stick to your linked stylesheet. If you need to modify behavior (e.g. what happens on a given event), do that in a Javascript include.
I am a huge fan of AngularJS, because it's essentially following the same separation pattern. It uses references (like ng-model, ng-controller, etc.) to attach elements to associated interactive behavior, but doesn't actually interfere with the structure of the page.
Using JS to insert CSS, DOM nodes, and more JS is becoming pretty standard now. ExtJS and GWT led the way seven years ago, and frameworks need only dumb it down more to gain popular acceptance. I've been on teams that made award winning sites with GWT, but you had a steep learning curve. Perhaps OJ can overcome that.
ExtJS didn't lead shit...there is a reason hardly anyone uses it.
GWT I am not personally familiar with, but if it is at all like ExtJS I want to stay AWAY as much as possible.
One major reason is it's just so freaking large and unruly to do anything simple. It's one of the few frameworks I've used that even after moderate use, I still had to keep the docs open on one screen even during routine development. The error messages weren't very helpful, either.
Just experimenting around it's pretty valid IMO.
That being said, this library does try to solve a problem, it's not useless. In my opinion, it's just not the right tool.. yet.
So think more, what if I could bundle a part of my website into ShoppingCartView, or HeaderBarWithLoginView? It doesn't remove the HTML and CSS it just simplifies how it is created because OJ Objects create themselves, and once created they modify themselves. Clearly to write these objects you will still need to use and know HTML and CSS, but this provides a different way of encapsulating things.
(sorry, that's the most constructive I can get with this)
Pretty much everyone's had the idea that, since HTML is a structured markup language, you can "simply" represent it in whatever language you're working in. It's great when you're a noob & want to make something ideologically pure.
It just turns into a giant pile of unmanagable shit if you try to extend it out to anything remotely resembling a real world application. Even a simple layout like HN would require an incomprehensible mess of nested objects/s-expressions/functions if you chose to abstract the raw HTML away. This is why everyone that actually develops web applications resorts to templates.
It's not impossible to be an expert graphic designer and web developer, but they are both extremely deep disciplines and people with the dedication, inclination, and aptitude for both are few and far between. Unicorns, etc...
This is fine for one-offs and side projects, but trying to build large project around this seems like an unnecessary extra layer of complexity (not that the current standard isn't complex, it's just relatively entrenched, for better or worse :)
It should also look like natural speech.
What it came down to is this behavior leads to a really nice syntax inspired by the excellent coffeekup js templating language (http://coffeekup.org/). The key is you can't really do computation or logic in anything but a function so using functions for nesting elements leads to elegant code. For example you could generate `li` tags inside of a `ul` tag: ul(function(){for loop{ li(...)}}).
That said, you don't have to use the functional notation to use OJ. All the functions and plugins support an _ variant (_YouTubeVideo, _div) that don't emit, and in addition everything in OJ can be written with a list syntax I call OJML. The syntax looks a bit like lisp and is actually what the functions, plugins, and css are all generating: [div, {'class':'my-cls',[YouTubeVideo,'url/to/video']].
For example, it makes sense to have a Javascript class such as "ShoppingListView" that takes care of rendering a shopping list via a template that it references. A component like a shopping list is coarse grained enough to be styled and designed on its own (by designers) and then stuck into a template (by designers) that the Javascript developer can then use and populate in code.
oj just takes us back to the tedious GUI development of Swing style frameworks. It is unfortunate that some people in every generation forget what the previous generation has already learned.
So ShoppingListView would be a powerful object that you could test and reuse. For example in the ojjs.org site I have an object called TryEditor, which does the live compiling examples. Clearly this isn't a plugin people will want (though it is made with the AceEditor plugin, which is pretty darn useful!), but it helped me to abstract it easily so I could use it, well, pretty much everywhere=).
Another way to think of it is imagine you were making Gmail. It would be helpeful to have an object handle EmailView, LabelView, and FriendView. These things are tied to data but wouldn't it be easier to interface with them as an object interface (addEmail, archiveEmail), then with direct DOM manipulation?
IMO you'd get a better reaction if you put a large chunk of your Plugins page on your main page. The "plugins" page better illustrates the purpose and vision of OJJS. The example on the main page is so low level it turns people off.
That being said, I still think the bulk of the "markup" should be in markup and reside as a template for your "plugin" or component to use.
So you have an EmailView component but with an EmailView template file as well. The EmailView is instantiated and manipulated in Javascript but it still has the benefits of markup via its template file.
Concrete example: Template: https://github.com/tantaman/Strut/blob/master/app/bundles/ap... Component: https://github.com/tantaman/Strut/blob/master/app/bundles/ap...
As for separating templating from the View it is a good point. In OJ you can use functions to create templates (or partials) since everything is just code.
I did find the unification of structure (HTML) and code (JS event bindings) quite helpful because this way the code that needs to find the HTML to bind an event is the very same code that created it. This removes the need to have class names / ids just so you can refer across HTML/CSS/JS boundaries.