
No more CSS and HTML, just JS - colinmegill
http://ojjs.org/
======
_lex
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.

~~~
evanmoran
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.

~~~
e12e
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.

[M]
[http://en.wikipedia.org/wiki/Template_Attribute_Language](http://en.wikipedia.org/wiki/Template_Attribute_Language)
[E] [http://elm-lang.org/](http://elm-lang.org/) [D]
[http://docs.diazo.org/en/latest/index.html](http://docs.diazo.org/en/latest/index.html)

~~~
evanmoran
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.

~~~
e12e
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.]

------
cocoflunchy
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...](https://github.com/ojjs/ojjs.github.com/blob/master/index.html)

~~~
mistermumble
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.

~~~
tomphoolery
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.

~~~
kunai
Why can't it be both?

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.

~~~
zalew
> he web can serve up both types of data: document-based (e.g. Wikipedia) and
> application-based (e.g. Gmail).

an email message is a document too.

~~~
evincarofautumn
> an email message is a document too.

An email _client_ is not.

------
MarkHarmon
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.

[https://en.wikipedia.org/wiki/Separation_of_concerns](https://en.wikipedia.org/wiki/Separation_of_concerns)

~~~
ceedan
That level of separation exists in dream worlds. Have you ever seen a job
application for an "HTML/CSS Expert"...

~~~
gisenberg
This isn't as uncommon as you might think.

------
padolsey
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.

[1]: [http://www.w3.org/TR/2013/WD-components-
intro-20130606/](http://www.w3.org/TR/2013/WD-components-intro-20130606/) [2]:
[http://www.polymer-project.org/](http://www.polymer-project.org/)

~~~
makepanic
There is also x-tags [1] by Mozilla which uses some polyfills from polymer.

They also have some repositories for ready to use webcomponents like
x-registry [2] or brick [3].

[1]: [http://www.x-tags.org/](http://www.x-tags.org/) [2]:
[http://registry.x-tags.org/](http://registry.x-tags.org/) [3]:
[http://mozilla.github.io/brick/](http://mozilla.github.io/brick/)

------
justindocanto
_HTML Version - 56 Characters, no dependencies:_

<ul><li>They</li><li>create</li><li>themselves</li></ul>

 _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.

~~~
tokenizer
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.

~~~
justindocanto
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.

~~~
pilgrim689
> 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:

> BulletList('They','create','themselves')

So no, it's not more work (41 characters).

------
pault
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 :)

~~~
brownBananas
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.

------
SchizoDuckie
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.

~~~
_lex
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?

~~~
brownBananas
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.

~~~
_lex
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.

~~~
brownBananas
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.

~~~
_lex
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.

Does this explain the "why" better?

~~~
hrjet
"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.

~~~
evanmoran
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=).

[http://jsfiddle.net/evanmoran/RmM96/](http://jsfiddle.net/evanmoran/RmM96/)

------
mankyd
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.

Pagespeed goes into this a bit here:
[https://developers.google.com/speed/docs/insights/Prioritize...](https://developers.google.com/speed/docs/insights/PrioritizeVisibleContent)

------
kapowaz
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.

------
scottfr
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.

------
nicolethenerd
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. :-(

~~~
evanmoran
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=).

------
balloot
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.

~~~
evanmoran
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](https://github.com/ojjs/oj-examples)

~~~
thibpat
This server side execution is a good idea ! I think this is an
important/valuable point of your idea.

------
ultimatedelman
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.

------
CWIZO
Umm ... why?

(sorry, that's the most constructive I can get with this)

~~~
ameoba
Because you can.

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.

------
DanielRibeiro
Seems similar to Reactive Coffee: [http://yang.github.io/reactive-
coffee/](http://yang.github.io/reactive-coffee/)

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](http://ojjs.org/docs.html#file-types)

~~~
evanmoran
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.

Check out this JSFiddle to see how the dependences work:
[http://jsfiddle.net/evanmoran/c3Reb/](http://jsfiddle.net/evanmoran/c3Reb/)

(Notice that OJ doesn't need HTML or CSS!)

------
chrisdone
A language like Elm seems more innovative and interesting: [http://elm-
lang.org/](http://elm-lang.org/)

It removes HTML, CSS and JS from the equation with just one language, Elm,
which uses FRP (functional reactive programming) for doing UIs.

------
tantaman
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.

~~~
evanmoran
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?

~~~
tantaman
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.

Concrete example: Template:
[https://github.com/tantaman/Strut/blob/master/app/bundles/ap...](https://github.com/tantaman/Strut/blob/master/app/bundles/app/strut.storage/templates/StorageModal.bars)
Component:
[https://github.com/tantaman/Strut/blob/master/app/bundles/ap...](https://github.com/tantaman/Strut/blob/master/app/bundles/app/strut.storage/view/StorageModal.js)

~~~
evanmoran
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.

------
andyroid
Atwood's Law: any application that can be written in JavaScript, will
eventually be written in JavaScript.

------
hadem
This feels like it is trying to reinvent the wheel. Is there something wrong
with using HTML and CSS?

~~~
nkassis
"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.

~~~
hadem
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.

------
tzury
I think the "no more CSS and HTML" misled us all.

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().

------
wprl
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.

------
icedog
Huge step in the wrong direction.

------
ferno
I started working on something similar to this, and left it as another object
to gather dust on my SSD after it proved like a very inelegant way of making
web apps/sites. Dunno, might have just been doing it wrong, but OJ seems very
similar. Blog post on it here:
[http://www.spectrumcoding.com/projects/xalt/2013/06/27/xalt....](http://www.spectrumcoding.com/projects/xalt/2013/06/27/xalt.html)
and repo here:
[https://github.com/Mirceam94/xalt](https://github.com/Mirceam94/xalt)

------
aragot
Good, so Swing fans can finally write webapps.

~~~
sjay123
Exactly, Swing is a great framwork(It has it's own problems/limitations, every
framwork has).

------
danso
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.

------
rob_mccann
Reminds me of building views in Java...

------
amjd
"To a man with a hammer every problem looks like a nail"

------
mike_ivanov
"build websites with objects"

Why not start with some content instead?

------
thibpat
Why would you remove HTML, it's the easiest way to create a UI ? Also this
introduce a lot of coupling between the style, the structure and the logic.

------
wojcikstefan
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.

Check out this presentation by Nicholas C. Zakas:
[https://www.youtube.com/watch?v=li4Y0E_x8zE](https://www.youtube.com/watch?v=li4Y0E_x8zE)

------
chenster
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.

Please stop the madness.

------
zekenie
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.

------
grannyg00se
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?

~~~
evanmoran
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=).

Check out this JSFiddle to make Vimeo videos!

[http://jsfiddle.net/evanmoran/yPXuL/](http://jsfiddle.net/evanmoran/yPXuL/)

------
jimbobimbo
The more I read the comments trying to explain this library, the more it
reminds me ASP.NET Web Forms, only in JS.

~~~
sixdimensional
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.

------
dragonwriter
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...

But I don't really see _why_ I'd want to do that.

------
txutxu
Great technology.

But it reminds me a little bit to perl cgi in the 90's.

    
    
        print h1('hello world');
    

I mean, this is great for people fast learning, but will never work against
"fronted" people in the average (non top) company.

I wish I'm wrong.

~~~
chrisdone
Build good ideas, don't be constrained by limited people.

~~~
txutxu
In any other random moment, that sentence could have sound simply inspiring to
me.

But right now. At this point when I'm right now very long to explain, that
sentence, has made my day. Up-voted.

------
grimtrigger
A couple other stabs at this problem:

uiji.js
[http://aakilfernandes.com/uiji.html](http://aakilfernandes.com/uiji.html)

domo.js [http://domo-js.com/](http://domo-js.com/)

~~~
passionfruit
It reminds me of EnyoJS [http://enyojs.com](http://enyojs.com)

------
deadfall
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.

------
sinkasapa
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.

~~~
evanmoran
This is my favorite comment by far. Dare I say this could be the the work of
the Illuminati? =)

------
Alex3917
So it's like a WYSIWYG that you need to know JavaScript to use?

------
auggierose
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.

~~~
evanmoran
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.

~~~
auggierose
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.

~~~
camus
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.

~~~
auggierose
Well, Scala is more modular than google closure lib can ever hope to be. By
the way, Scala.js builds on top of google closure.

------
Johnyma22
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.

------
gluxon
Seeing CSS before HTML freaks me out more than it should.

*HTML & CSS

~~~
colinmegill
I suppose this post may benefit from the misspelled advert effect =)

------
Sanddancer
So, how well does this framework handle screen readers, like JAWS? All
javascript, all the time is terrible from an accessibility standpoint.

~~~
evanmoran
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.

~~~
Sanddancer
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](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.

------
reycharles
Maybe I am misunderstanding something, but it seems like all the HTML is
created as a side-effect. How can this possibly be a good idea?

~~~
evanmoran
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/](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']].

------
puppetmaster3
Ha ha. No designers. Remember Java applets? Yeah, that was a thing. The rest
of us will keep doing HTML 5 and DOM. Bye.

------
_random_
This is what you get for "open web" \- treating symptoms instead of the
disease that is JS, HTML and CSS.

------
piyush_soni
Man ... Every day there is a new ".js" library coming up. How to even keep
track of them? :O

------
4d47
No. Just no.

------
denysonique
I see this useful for writing UserScripts/browser extensions.

------
inovator
Nice framework but my eyes bleed when I see html and css in my js.

------
rjurney
This seems like the Perl-based web of 20 years ago.

------
VeejayRampay
Oj also happens to be the fastest Ruby JSON parser.

------
afleegman
This dosen't really work at all with SEO

~~~
grimtrigger
Not true. Google runs javascript code before scraping.

~~~
sixdimensional
No, AFAIK, Google does not run Javascript code first without special
accommodations. See [https://developers.google.com/webmasters/ajax-
crawling/](https://developers.google.com/webmasters/ajax-crawling/).

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.

~~~
grimtrigger
I'm sorry, but you are incorrect. It may not be officially supported, but they
are doing it.

[https://www.google.com/search?q=uiji.js](https://www.google.com/search?q=uiji.js)

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.

~~~
sixdimensional
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.

For example, same search on Bing -
[http://www.bing.com/search?q=uiji.js](http://www.bing.com/search?q=uiji.js)

References: \-
[https://twitter.com/mattcutts/status/131425949597179904](https://twitter.com/mattcutts/status/131425949597179904)
\- [http://www.biznology.com/2012/01/no-more-seo-worries-for-
dyn...](http://www.biznology.com/2012/01/no-more-seo-worries-for-dynamic-
content/)

------
egypturnash
My adblock (GlimmerBlocker) breaks your JS.

------
coin
The fade effect make it feel sluggish

------
vezzy-fnord
I think I'll stick to markup.

------
tretarok
Oh good, another abstraction around html and css. Please murder me and this
project.

~~~
tantaman
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.

~~~
cmccabe
Hey guys... let's make a programming language... for non-programmers! Pretty
wacky, eh?

It should also look like natural speech.

~~~
krapp
The basic premise sounds good...

~~~
cmccabe
Spoiler alert: it's COBOL.

------
rfnslyr
Love this, but I'll only adopt this way once it seriously becomes mainstream.

