This post is getting a lot of flack from people who haven't given it more than a glance.
-------Benefits
1. SEO is not a problem.
Since OJ can be compiled on the server-side, it's comparable to EjS, JADE or other templating languages, which means SEO is not a problem.
2. Current code-size can be ignored in the long run.
This code doesn't have to be sent to the client (since it can run on the server), could possibly be hosted by a CDN and cached across the web, and can probably be tightened up in the future.
3. CSS is still available, but the views know about their css files and are coupled with them
4. True MVC on the front end
OJ gives us the chance to do true MVC in the web frontend, without having a javascript view and an dom view and css styles that are separate, but that work together to make one thing. It seems to me that they're really made for each other - shouldn't they be together at last?
5. Sharing code will be easier
OJ could eventually be supported by a package manager that allows you to include (or install for server-side) js objects for things like youtube videos, but also for tweets etc. Separation of concerns (So your app doesn't just have one huge CSS file, but each view has it's own css, and it's own html & js etc) will also reduce complexity in larger apps.
------Trade offs
1. Yet another framework to learn/use
2. May be slower than what you currently do to render pages
3. If used client side, you may weaken your site's SEO
4. New engineers to your team will likely need to be brought up to speed.
5. (short term) There are likely weird bugs you'll pull your hair out over.
Just to add to #5: OJ already is using Node's npm as a package manager. It was my thought that server-side templating aligns perfectly with node, so all plugins are already just a require away (packages are named: oj-youtube-video, oj-markdown, oj-twitter-button, etc).
In addition oj has an (optional) server side commandline tool that already supports a Browserify-like approach of building websites that can use Node packages. So if you are looking to make a static page for say GitHub pages, the OJ commandline tool already supports using npm as an OJ package manager.
One last thing: my top priority right now is Express Server integration to finish out the dream of shared Client and Server code in node. This will allow use of npm as packages even more, so if any experts on Express are out there, I'd love to talk to you.
Nice!
I've built several production systems using node/express/jade + require/backbone/handlebars, and I completely see why you made OJ. To me, OJ is the logical next step, just beyond where we are now. Please ignore the hate and accept my Kudos.
I think this is fascinating -- but I'm not quite sold yet.
I've been thinking a lot about frameworks along these lines; use js (or something that compiles to js) for the logic, allowing shared code-bases on server and client. One major motivation would be to seamlessly render on server for clients that doesn't support javascript (be they lynx/w3m or some crawler etc). Another would of course be to try and keep things reusable.
I'm not so sure html+css+"interactive/event-handling"-js is a good "compile target", though. I'd much rather see something as close to the output as reasonable -- because there are so many corner-cases with html and css. This is one of the reasons why I like the idea of zope's TAL/METAL templating[M] so much. My interest in TAL is also why I don't think this (general architecture) is going to quite work.
With TAL, you can basically make a mockup that is a template, complete with sample data. But then you need to break up that template to have widgets. And widgets need to be inserted across different areas of the document (think a calendar, where you mouse over events to change an info box. That can be structured, but it is going to cut across a lot of you entire page/app. Even if you don't load content asynchronously). This is done in Plone/Zope using METAL (Macro Expansion for Template Attribute Language).
In fact, the Plone project has essentially given up the idea of using TAL+METAL to theme a site -- it is now (ME)TAL->html+css+js -> page/app "base". Then that base is modified/rewrtitten using diazo[D] (xml transform but with easy support for using css selectors rather than forcing full xpath syntax on a poor dev) - that basically can include new css and js -- but fundamentally can rewrite the entire html-document, splicing in content in sections.
I'm not sure that that is the best way forward either -- but I think that is one of the best ways of writing rich html "documents" -- or systems that revolve around pages. For "pure" apps, I think maybe a full on js approach like ELM[E] is better -- the code is cleaner -- you don't really care about the html, css or even javascript as such -- you focus on the functionality.
As for Ojs, I looked a bit at the examples:
http://ojjs.org/download.html#examples
and one thing struck me -- is there really a reason for the js client and server examples to be different? Couldn't/shouldn't the server side tools be able to deal with the code for client side -- so that you can write once, and then deliver server side or client side from the (exact) same code base?
Despite all this, I think it is an interesting project.
This is really insightful. Thank you for giving it serious thought=). The main reason to make them different is I saw them as different use cases: the client-side folks just want a single script (oj.js) include to make things easy to get started with. The server-side people are already comfortable with the Node npm module system and so using `require` to include different files / modules made sense. I mostly didn't want to force everyone to use a command-line tool / Node just to use OJ.
That said, I completely agree and hope over time more and more people will embrace the server-side way as it makes downloading and updating plugins really simple. Maybe in time that path should be emphasized more.
Perhaps adding support for thin "client-side" shim, so that you'll have just a html of something along the lines of:
<html>
<head>
<title>OJ Example: html shim</title>
<!--Include OJ -->
<script src="oj.min.js" type='text/javascript'>
</script>
<!--Include OJ app/page -->
<script src="example.oj" type='text/javascript'>
</script>
</head>
<body>
<noscript>
<h1>Something went wrong</h1>
<p>So sorry. The server was unable to detect that
your client doesn't support javascript. Please try:
<a href="?force-server-side-rendering=true">magick</a>.
(Maybe that should be a client side redirect, via a meta-tag:)
<meta http-equiv="refresh"
content="1; url=?force-server-side-rendering=true">
</p>
</noscript>
</body>
</html>
Now, example.oj will pull in stuff via require etc, and given a "smart"
server, the same page/app can render client side and server side?
[edit: The oj.js script should also probably be able to redirect the client "back" to client side rendering, if it detects js -- so that if google links to url/?server-side-rendring=true -- not all clients from google will be "forced" to do server side rendering.]
Code size can't be ignored because the JS community at large values small modular components, i.e., Sinatra over Rails. Libraries live or die mostly by popularity, so there you go.
The trade-offs you listed are not really significant. We all pick up frameworks and languages almost any year anyway, and the comments about client-side SEO are just way off.
I keep harping on this bit, but that keeps popping up in HN all the time. Again, client-side apps won't hurt your SEO, and there's even services based around it like http://seo4ajax.com
Because SEO is so important, you should be really careful about the sort of assertion you're making - most people will read your post and assume that the googles can read html generated by js template rendering. AFAIK, this is false, and this is a huge problem for single page js apps - they're often SEO crippled.
Most people running js webapps are not following google's ajax webcrawling directives or paying seo4ajax to solve the problem for them. It's irresponsible to say that there's no SEO problem with client side rendering.
But there's a right way to do it already, and the definition of a solved problem is one people are making money off, so steering people away from js webapps because of SEO is just bad
There are no large caveats here, either follow a tutorial off Google Dev Guides or pay someone like $5 bucks a month to do it.
Gawker did this a while back. And reverted after their Google rankings took a hefty plunge. That is one very large caveat, that Ajax crawler spec is no magic bullet.
And while google certainly is important, it isn't the only crawler. Others are important both in "absolute" terms (duckduckgo/bing ?) -- and for "local" and possibly "domain" search (yandex, baidu).
Not to mention internal crawlers for site-wide search (although you can of course adapt those -- why do it if you don't have to?).
Agreed, this is a good summary. My first initial reaction was one of slight skepticism, but one can reason pretty easily the output can be done on the server. When you work back on logic that way, what about having your site pre-built sitting on the server with only oj.s on your dev machines? As evan mentioned re-usable components that are easily dropped in to create faster website builds. Seems like an interesting concept to me.
If that's the case, then why not use one of the many static Web site generators? Combined with a simple CSS library like Pure.io for some of the UI elements.
It is possible that some more complex UI elements (say a Calendar) will have to be done in Javascript, but that seems like a worthwhile tradeoff for simplicity, efficiency, and maintainability.
I'm ignoring it because I'm assuming that you'll download the file ONCE from cdn.awesomesauce.com/oj.js when you're on my website, then the next time you return to my website, or you go to tom, dick or harry's website, once they have the same url for the file and it's cached in your browser, the load time will be near 0.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
OJJS Version - 57 Characters, thousands of lines of js dependencies:
var myList = oj.BulletList('They','create','themselves');
The fact that just writing the html output is the same (and in this case less) amount of characters then the ojjs functions makes me unsure about this. especially considering all the extra dependencies.
I would also argue that in terms of maintenance, it would be more time consuming for me to debug native html, css, and javascript, and then fix those bug in a completely different environment.
Absolutely. I agree. And there are lots of other points worth arguing too.
My point in bringing up something like the difference in character count (not counting characters in the dependencies) is that just calling the function is already more work than basic html. That immediately is a NO for me.
One could argue maintenance, incompatibilities, bloat, optimization, debugging, and so much more.
> My point in bringing up something like the difference in character count (not counting characters in the dependencies) is that just calling the function is already more work than basic html.
To nitpick, to get your HTML, the OJ example could actually be:
Even if i had an unordered list with 1,000 items (which why would I ever have that), it would still be less characters then the jquery dependency alone. That doesnt even include the ojjs source itself.
I get what you're trying to do, because i did something similar with forms in PHP, but the dependencies and functions are too much... especially for production use.
my advice is i would maybe focus on doing less things more efficiently. Or even better, offering a way like TW Bootstrap does, where you can choose your components and it spits out what you want.
I wouldn't use 95% of the functionality of this code so having thousands of lines of code that i will never use is very unattractive for me when im thinking about optimization, debugging, etc.
ADDITION: And i mean something that compiles your main ojjs js file, BEFORE the plugins. For example: I would never need any of the css functionality in this but it's included in the core. That's what i meant. I'm aware you have the ability to add 'plugins'. My idea of choosing parts was to choose parts within the current 'core' code.
However, it looks like you are investing a lot of time into this and it's not a bad idea, so i applaud that. Just think it needs a little organizing/re-thinking in some aspects. Good luck :)
Great feedback, thank you! If you don't want a jQuery dependency then you probably don't want OJ =).
As for the CSS support it is actually quite elegant. Maybe 100 lines with full support for '&:nested' selectors, and nestable '@media' query support.
One thing that I've been considering is right now 40-50% of the oj.js filesize is support for the Form Elements (TextBox, ListBox, CheckBox,Button) and the "collection" elements (BulletList,NumberList,Table). I'm still considering pulling these out of the core and making them plugins. The issue is they manipulate the basic tags (input,textarea,table,ul,etc) so they seem pretty fundamental. Is that something you would want?
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.
Please do not use something like this if you're building your next project. NOTHING is wrong with using mustache or so for templating, but this is just plain wrong.
You will know how much it costs to use something like this if you have a project that you've worked on for weeks or months and need to hand it over to another developer. Or actually any other interaction with a third party like a designer or frontender that's used to just juggling around some tags for preference or layout optimisation.
Sorry, but there will always be new tools and newer, better ways of doing things: best-practices will aways change, and people will always need to be re-educated. This is even more true in this industry than anywhere else, and I've noticed that the rate of this change has been dramatically increasing (which is why there's such framework fatigue in this thread).
Do you have any other reason why we shouldn't use OJ?
I am sorry, you make a good point, but it's for "better way of doing things". Such comment is so far deep into the common sense territory that there is hardly any reason to mention it explicitly. This discussion is happening with exactly that in mind.
Other folks here have mention the separation of concerns. Is there something that you can say related to that? Loved your summary of benefits and trade-offs, but can you please address MarkHarmon's comments? Thanks.
Separation of concerns is increased with OJ: Your app doesn't just have one huge CSS file, but each view has it's own css, and it's own html(template) & js. This will significantly reduce complexity in larger apps.
How is that different than another framework such as Angular JS, or something like web components perhaps? Each view, or directory or component can have it's own CSS file with existing solutions too.
What we are seeing here is an attempt to solve the same problem, but by doing all the work by using JavaScript. Cool. But not impressed.
Currently, views are split into 3 places: html, css + js (for rendering updates - usually done with a template). The big difference here is saying that the view is actually all three things/ that it's made up of all three components, which is closer to the truth than other systems of thinking.
Can HTML be the view without css and without js binding for events and updates? Not in a modern app!
Can CSS be the view without HTML/JS? NO!
Can JS alone be the view? Yes, but you'd have a lot of inline css and html - it'd be and a pain in the ass to maintain.
So if you want a single, true View in your MVC, you'd need a view that has all three parts. Other frameworks like backbone try to do something similar - backbone allows you to let your view have a template, but backbone views rely on external css and often attach to dom elements that aren't even in the view's template. So what you have is a view that's only referring to/aware of a few of it's actual dependencies. That seems sloppy if you ask me.
Also, if I had a TweetView that was a backbone view, and I wanted to move it to another person's system - maybe I created an awesome design and called it AwesomeTweet - other people who wanted to consume AwesomeTweet without OJ today would have to include a css file, some html (or a template) and some JS. Each presents a rich opportunity for namespace collisions, and for my bad documentation to make it difficult to import AwesomeTweet as a module. Instead, OJ could allow a simple line like showAwesomeTweet('2131221121'), which would be guaranteed to work everywhere, simply.
"Instead, OJ could allow a simple line like showAwesomeTweet('2131221121'), which would be guaranteed to work everywhere, simply."
Ah, but you are sacrificing uniformity of design there. What if I would like the style of the tweet to be consistent with the overall style of my app? And this style is managed by a separate designer not a programmer?
Modularity works fine for behaviour, because it is better to abstract and encapsulate behaviour. But modularity doesn't necessarily work great for looks and feels.
OJ actually supports the ability to Theme objects which makes it much simpler to create design abstractions like you're talking about. It was inspired by the Bootstrap approach for customizing the look of different elements. The basic notion is OJ creates a CSS class that you can add and remove from an object to change its look. This can be done in a separate file (or even plugin) for designers to configure separately.
Here is a JSFiddle I made to demonstrate. This isn't even in the docs yet, so I made this just for you=).
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.
Why do people keep trying to abstract away the parts of web applications that have been carefully designed to solve that particular part of the problem as best they can with a ‘one size fits all’ solution?
To me the answer is obvious: we have people who don't understand CSS, who don't understand HTML, who do understand JavaScript (or Java, or Ruby, or Go, or whatever) who want to make web applications but have no interest in learning or understanding the reasons why we do things a certain way.
Frankly it depresses the hell out of me for the next generation of web applications, because it feels like we're taking a technological leap backwards.
Similar to something like ExtJS. Using Ext you declare the UI purely with JavaScript (CSS and HTML can be inserted if desired but that is antithetical to the standard practices).
It works pretty well. But when you have complex layouts, your JavaScript files can become very complex with many layers of nested object definitions. I use Ext and love it, but personally I think an HTML markup approach to defining UI's is cleaner.
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
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.
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.
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.
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.
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.
"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.
In other words, if you think of this as a way to generate HTML snippets with events binding, then, this might not looked as such crazy idea. Of curse when it aims at building the entire website with, one will wonder why.
Having said that, a suggestion to the author, start using name spaces, i.e. put all plugins under the namespace of .plugins, e.g. plugins.YouTube(), plugins.Ace() instead of just YouTube() and Ace().
I absolutely love JavaScript and being able to use one language from database to server to client in my current stack BUT I am very skeptical about using JS for representation and styling. Maybe JS can be massaged into a great language for representation and presentation, but I would bet HTML and CSS are far better suited.
OK, I won't add another "Why?"...but I'll just say that this paradigm already evokes a stomach-turning reaction from some people...why do the colors have to be so off-putting? It's tolerable on a standard Mac screen, but on my (cheaper) Dell monitor...which, let's face it, a lot of monitors are uncalibrated, the colors are not comforting...
There's already a lot of work put into this, it's worth going that extra step and make things look less like the messy days of HTML and Java and Flash a decade ago.
Although I respect the effort put into making the API look neat and work properly, I don't think it's a good idea to use JS for yet another thing instead of using the right tools for the right job.
This is horrible horrible things to do, a giant step...back. The entire separation of concern is destroyed this way by mashing up everything into object that is completely unnecessary. The entire internet is built around loosed couple system so it wont' fall apart when a ending body tag is missing. But with objects, that's not the case.
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.
There's a javascript wrapper around all html and css functionality so instead of creating a .html file you create a .js file and have javascript functions like h1('HTML Creation') instead of html like <h1>HTML Creation</h1>. Is that right?
Interesting. But why would we use this? Or is it just for fun?
The real goal is create objects that act as reusable building blocks for the web. The tag functions like h1/div are just a stepping stone to get there. The real point is to help everyone make a YouTubeVideo or a TwitterButton with one line of code=).
Well, to be fair, ASP.NET Web Forms still encourages you to use a lot of hand-coded HTML/declarative markup with code-behind files in C#/VB. However, from my experience writing custom web controls in ASP.NET, OJ is similar in concept to using things like System.Web.UI.HtmlControls or the HTMLTextWriterTags with HTMLTextWriter to generate HTML content in code. Or like ASP.NET MVC HtmlHelpers. Still, all those technologies were strictly meant to be server side - one place where things like OJ are useful (rather than typing in big strings of HTML!).
I've toyed with my own similar tech to OJ in Javascript before, but couldn't justify the overhead in the client at the time.
It seems like a clever way to avoid the decoupling of content, presentation, and behavior, each with their own focussed, domain-centered language offered by the traditional HTML/JS/CSS set up...
Maybe I should really say designers, but it's the same, there are designers who can learn a new syntax in two afternoons, and there are those (in my experience, more) than no.
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.
I think the title presages the coming of the apocalypse. The two ok-ish parts of the web replaced by the horrible one that we are all stuck with. Next step, replace all three with 666 and call it quits.
Good idea, I am currently working on something very similar, but built on Scala/Scala.js. Javascript is just not the right language for this, just as Java (GWT) wasn't.
First off Scala is amazing -- I'm using it for API servers -- so I'm very curious how your framework turns out=).
As you might imagine I would disagree that JS is the wrong language simply because it _is_ the web. Clearly abstracting JS to other languages can be quite useful (CoffeeScript), but by making your building blocks in JS every developer, library, or framework can use them. They become universal. If OJ can add YouTubeVideos, anyone can. It would be harder to do this if it was written in another language.
I agree with you that JS has more wide-spread appeal. But it just is not the right tool for the job. Obviously, I have to be clear about the job. The job is writing a web application that lets gmail look like a school project.
but contrary to what people believe you dont create such apps with a big monolitic framework , but by using a lot of little modular libs. Gmail is build on google closure lib which is exactly that.
Bug report: When the page loads the caret is focused in the textarea but using the arrow keys moves the entire page and not the caret inside the text area.
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.
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.
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']].
There's a fundamental disjunction between today's search crawlers and these kind of dynamic Javascript apps that's just going to become even worse.
If anything, I think libraries like OJ point out the disjunction and therefore encourage discussion of what the future should be. HTML and Javascript have served us admirably, and given the nature of the web one wonders if we will ever get away from these technologies. That said, using one in isolation without the other (i.e. Javascript to generate HTML but not writing HTML) diminishes both as far as the usefulness of the "web" as we used to know it, at least.
I might even go so far as to say that fully dynamic browser apps, without the proper functionality for search engine indexing, are a direct threat to the business model and usefulness of search engines.
Check out the results for the 1st link (aakilfernandes.com/uiji.html) and then check the source code. You'll see that the entire body of the page is written with javascript.
I stand corrected - sort of - a bit more research shows the reality is "some dynamic/Ajax content" is indexed by Google, and not all search engines (i.e. Bing) are doing it yet.
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.
-------Benefits
1. SEO is not a problem.
Since OJ can be compiled on the server-side, it's comparable to EjS, JADE or other templating languages, which means SEO is not a problem.
2. Current code-size can be ignored in the long run.
This code doesn't have to be sent to the client (since it can run on the server), could possibly be hosted by a CDN and cached across the web, and can probably be tightened up in the future.
3. CSS is still available, but the views know about their css files and are coupled with them
4. True MVC on the front end
OJ gives us the chance to do true MVC in the web frontend, without having a javascript view and an dom view and css styles that are separate, but that work together to make one thing. It seems to me that they're really made for each other - shouldn't they be together at last?
5. Sharing code will be easier
OJ could eventually be supported by a package manager that allows you to include (or install for server-side) js objects for things like youtube videos, but also for tweets etc. Separation of concerns (So your app doesn't just have one huge CSS file, but each view has it's own css, and it's own html & js etc) will also reduce complexity in larger apps.
------Trade offs
1. Yet another framework to learn/use
2. May be slower than what you currently do to render pages
3. If used client side, you may weaken your site's SEO
4. New engineers to your team will likely need to be brought up to speed.
5. (short term) There are likely weird bugs you'll pull your hair out over.