81–90 of 191 posts
But it reminds me a little bit to perl cgi in the 90's.
print h1('hello world');
I wish I'm wrong.
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.
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…
That level of separation exists in dream worlds. Have you ever seen a job application for an "HTML/CSS Expert"...
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 b…
Check out this presentation by Nicholas C. Zakas: https://www.youtube.com/watch?v=li4Y0E_x8zE
Earlier quoted context omitted.
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…
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 r…
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.
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 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 Ac…
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... Component: https://github.com/tantaman/Strut/blob/master/app/bundles/ap...
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…
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…