A couple other stabs at this problem: uiji.js http://aakilfernandes.com/uiji.html domo.js http://domo-js.com/
It reminds me of EnyoJS http://enyojs.com
No more CSS and HTML, just JS
111–120 of 191 posts
Re: No more CSS and HTML, just JS
#112This 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…
SEO should not be a problem, doesn't matter if it's client-side or server side. https://developers.google.com/webmasters/ajax-crawling/
Code size can't be ignored because the JS community at large values small modular components, i.e., Sinatra over Rails. Libraries live or die mostly by popularity, so there you go.
The trade-offs you listed are not really significant. We all pick up frameworks and languages almost any year anyway, and the comments about client-side SEO are just way off.
I keep harping on this bit, but that keeps popping up in HN all the time. Again, client-side apps won't hurt your SEO, and there's even services based around it like http://seo4ajax.com
Re: No more CSS and HTML, just JS
#113There'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 HTML Creation . Is that right? Interesting. But why would we use this? Or is it just for fun?
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!
Re: No more CSS and HTML, just JS
#114HTML Version - 56 Characters, no dependencies: They create themselves 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.
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 more efficiently. Or even better, offering a way like TW Bootstrap does, where you can choose your components and it spits out what you want.
I wouldn't use 95% of the functionality of this code so having thousands of lines of code that i will never use is very unattractive for me when im thinking about optimization, debugging, etc.
ADDITION: And i mean something that compiles your main ojjs js file, BEFORE the plugins. For example: I would never need any of the css functionality in this but it's included in the core. That's what i meant. I'm aware you have the ability to add 'plugins'. My idea of choosing parts was to choose parts within the current 'core' code.
However, it looks like you are investing a lot of time into this and it's not a bad idea, so i applaud that. Just think it needs a little organizing/re-thinking in some aspects. Good luck :)
Re: No more CSS and HTML, just JS
#115HTML Version - 56 Characters, no dependencies: They create themselves 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.
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.
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.
Re: No more CSS and HTML, just JS
#116Earlier quoted context omitted.
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…
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 compo…
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.
Re: No more CSS and HTML, just JS
#117I 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.
This is my favorite comment by far. Dare I say this could be the the work of the Illuminati? =)
Re: No more CSS and HTML, just JS
#118Man ... Every day there is a new ".js" library coming up. How to even keep track of them? :O
Re: No more CSS and HTML, just JS
#119Well, 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...
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 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.
Re: No more CSS and HTML, just JS
#120This 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…
SEO should not be a problem, doesn't matter if it's client-side or server side. https://developers.google.com/webmasters/ajax-crawling/ Code size can't be ignored because the JS community at large values small modular components, i.e., Sinatra over Rails. Libraries live or die mostly by popularity, so there you go. The trade-offs you listed are not really significant. We all pick up frameworks and languages almost an…
Because SEO is so important, you should be really careful about the sort of assertion you're making - most people will read your post and assume that the googles can read html generated by js template rendering. AFAIK, this is false, and this is a huge problem for single page js apps - they're often SEO crippled.
Most people running js webapps are not following google's ajax webcrawling directives or paying seo4ajax to solve the problem for them. It's irresponsible to say that there's no SEO problem with client side rendering.