121–130 of 191 posts
This feels like it is trying to reinvent the wheel. Is there something wrong with using HTML and CSS?
"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.
Earlier quoted context omitted.
When you write oj.BulletList({collection:lotsOfData}) it will be much smaller I promise=).
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…
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?
Earlier quoted context omitted.
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…
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 u…
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.
So, how well does this framework handle screen readers, like JAWS? All javascript, all the time is terrible from an accessibility standpoint.
Earlier quoted context omitted.
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 u…
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 appl…
an email message is a document too.
Earlier quoted context omitted.
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 YouTub…
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.
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?
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']].
The more I read the comments trying to explain this library, the more it reminds me ASP.NET Web Forms, only in JS.
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.
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...
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 fe…
Congrats on the release, I wish you luck for the rest!
Earlier quoted context omitted.
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…
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"…