So, how well does this framework handle screen readers, like JAWS? All javascript, all the time is terrible from an accessibility standpoint.
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.
No more CSS and HTML, just JS
61–70 of 191 posts
Re: No more CSS and HTML, just JS
#62-------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.
Re: No more CSS and HTML, just JS
#63What 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…
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…
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.
Re: No more CSS and HTML, just JS
#64Re: No more CSS and HTML, just JS
#65You 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.
Re: No more CSS and HTML, just JS
#66Love 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. :-(
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=).
Re: No more CSS and HTML, just JS
#67What 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…
That level of separation exists in dream worlds. Have you ever seen a job application for an "HTML/CSS Expert"...
Re: No more CSS and HTML, just JS
#68Interesting. But why would we use this? Or is it just for fun?
Re: No more CSS and HTML, just JS
#69Earlier quoted context omitted.
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 t…
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 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…