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?
No more CSS and HTML, just JS
41–50 of 191 posts
Re: No more CSS and HTML, just JS
#42What 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"...
Yes, definitely.
Re: No more CSS and HTML, just JS
#43Not 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/ [2]:…
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/ [2]: http://registry.x-tags.org/ [3]: http://mozilla.github.io/brick/
Re: No more CSS and HTML, just JS
#44Stuff 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.
Re: No more CSS and HTML, just JS
#45This dosen't really work at all with SEO
Re: No more CSS and HTML, just JS
#46What 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"...
They are called "designers".
Re: No more CSS and HTML, just JS
#47What 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…
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.
Re: No more CSS and HTML, just JS
#48Similar 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.
Re: No more CSS and HTML, just JS
#49What 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…
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 Javascript include.
Re: No more CSS and HTML, just JS
#50Stuff 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 int…
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?