13 ms·

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 s

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.html https://github.com/ojjs/ojjs.github.com/blob/master/index.ht...

diminish 13y ago
When will we write a full browser in js and render to canvas?
- sorghum 13y ago
  Today if you feel like it: http://html2canvas.hertzen.com/ http://html2canvas.hertzen.com/
- nkassis 13y ago
  Just like the Flash sites from a decade ago.
mistermumble 13y ago
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 to messing with code and debugging it? Unless I am missing something, heavy-weight pages with potential for bugs does not seem like a win.
- evanmoran 13y ago
  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 YouTubeVideo component is well tested, then you are actually saving your self time and will make a more robust site.
  - diminish 13y ago
    could be great if i could describe the reusable UI building blocks in a markup language, do their formatting separately with style sheet fragments and add a simple scripting language for actions and animations.
    - JanezStupar 13y ago
      Yeah I vote that it be our first priority to implement those immediately after we complete our framework. And then we can have laymen code the templates and styling because it will be so simple. It will be glorious!
    - meemoo 13y ago
      Sounds like the Custom Element standard that's coming soon. http://www.polymer-project.org/ http://www.polymer-project.org/ makes polyfills to use it today.
  - ulisesrmzroche 13y ago
    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.
    - rickjames28 13y ago
      Yeah, once I read his explanation web components immediately came to mind. You know what the status of web components is in the major browser engines?
      - ulisesrmzroche 13y ago
        Natively, on most evergreen browsers, mutation observers and a limited shadow-dom on chrome canary. The polymer project gets you all the way though, check http://www.polymer-project.org/compatibility.html http://www.polymer-project.org/compatibility.html.
- tomphoolery 13y ago
  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.
  - kunai 13y ago
    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 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.
    - zalew 13y ago
      > he web can serve up both types of data: document-based (e.g. Wikipedia) and application-based (e.g. Gmail). an email message is a document too.
evanmoran 13y ago
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 feedback it is just going to get faster, smaller, and better. Let me assure you perf and filesize are big priorities, as is better Express and Node templating integration.
- cocoflunchy 13y ago
  Yeah, I'm kind of bummed now that my snarky, not very useful comment is at the top here :/ Congrats on the release, I wish you luck for the rest!
  - evanmoran 13y ago
    Thanks man. Really appreciate the positive thoughts=).
mstrem 13y ago
I agree, also I personally prefer the idea of having things separate, HTML for the structure, CSS for the style, and JavaScript for the behavior. You can create very clean and neat pages like that especially if you don't mix each technology e.g. keep everything separate in different files.. I am however open to new ways of doing things so I will keep an eye on this, but I must admit, that index page looks a lot more daunting to edit than a normal HTML page, especially if you are not familiar with JavaScript.
- iopq 13y ago
  Except CSS sucks for styling. You can't even make a "scroll to top button" disappear with CSS because it doesn't know if the document is at the top. CSS is missing a ton of things.
  - hrjet 13y ago
    One could argue if that is "style" or "behaviour".
    - iopq 13y ago
      I mean I want that button to disappear when the page is already scrolled to the top. The scrolling up part I'm fine with making with JS. I just don't feel right about attaching a scroll handler to have a very unoptimized implementation of such a thing since that scroll handler will fire EVERY SINGLE SCROLL. But the browser could optimize away "is document at the top" CSS calls by knowing we scrolled down (and by definition we can't be at the top then).

diminish 13y ago

When will we write a full browser in js and render to canvas?

sorghum 13y ago
Today if you feel like it: http://html2canvas.hertzen.com/ http://html2canvas.hertzen.com/
nkassis 13y ago
Just like the Flash sites from a decade ago.

mistermumble 13y ago

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 to messing with code and debugging it? Unless I am missing something, heavy-weight pages with potential for bugs does not seem like a win.

evanmoran 13y ago
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 YouTubeVideo component is well tested, then you are actually saving your self time and will make a more robust site.
- diminish 13y ago
  could be great if i could describe the reusable UI building blocks in a markup language, do their formatting separately with style sheet fragments and add a simple scripting language for actions and animations.
  - JanezStupar 13y ago
    Yeah I vote that it be our first priority to implement those immediately after we complete our framework. And then we can have laymen code the templates and styling because it will be so simple. It will be glorious!
  - meemoo 13y ago
    Sounds like the Custom Element standard that's coming soon. http://www.polymer-project.org/ http://www.polymer-project.org/ makes polyfills to use it today.
- ulisesrmzroche 13y ago
  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.
  - rickjames28 13y ago
    Yeah, once I read his explanation web components immediately came to mind. You know what the status of web components is in the major browser engines?
    - ulisesrmzroche 13y ago
      Natively, on most evergreen browsers, mutation observers and a limited shadow-dom on chrome canary. The polymer project gets you all the way though, check http://www.polymer-project.org/compatibility.html http://www.polymer-project.org/compatibility.html.
tomphoolery 13y ago
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.
- kunai 13y ago
  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 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.
  - zalew 13y ago
    > he web can serve up both types of data: document-based (e.g. Wikipedia) and application-based (e.g. Gmail). an email message is a document too.

evanmoran 13y ago

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 feedback it is just going to get faster, smaller, and better. Let me assure you perf and filesize are big priorities, as is better Express and Node templating integration.

cocoflunchy 13y ago
Yeah, I'm kind of bummed now that my snarky, not very useful comment is at the top here :/ Congrats on the release, I wish you luck for the rest!
- evanmoran 13y ago
  Thanks man. Really appreciate the positive thoughts=).

mstrem 13y ago

I agree, also I personally prefer the idea of having things separate, HTML for the structure, CSS for the style, and JavaScript for the behavior. You can create very clean and neat pages like that especially if you don't mix each technology e.g. keep everything separate in different files.. I am however open to new ways of doing things so I will keep an eye on this, but I must admit, that index page looks a lot more daunting to edit than a normal HTML page, especially if you are not familiar with JavaScript.

iopq 13y ago
Except CSS sucks for styling. You can't even make a "scroll to top button" disappear with CSS because it doesn't know if the document is at the top. CSS is missing a ton of things.
- hrjet 13y ago
  One could argue if that is "style" or "behaviour".
  - iopq 13y ago
    I mean I want that button to disappear when the page is already scrolled to the top. The scrolling up part I'm fine with making with JS. I just don't feel right about attaching a scroll handler to have a very unoptimized implementation of such a thing since that scroll handler will fire EVERY SINGLE SCROLL. But the browser could optimize away "is document at the top" CSS calls by knowing we scrolled down (and by definition we can't be at the top then).