12 ms·
No more CSS and HTML, just JS
- gluxon 13y agoSeeing CSS before HTML freaks me out more than it should. *HTML & CSS
- colinmegill 13y agoI suppose this post may benefit from the misspelled advert effect =)
- DanielRibeiro 13y agoSeems similar to Reactive Coffee: http://yang.github.io/reactive-coffee/ http://yang.github.io/reactive-coffee/ Having proper components is a big win. However, it seems it requires a command line dependency to the build app, which would be nice not to: http://ojjs.org/docs.html#file-types http://ojjs.org/docs.html#file-types
- evanmoran 13y agoAuthor here -- Just to clarify OJ is a javascript library (oj.js) with only one dependency jQuery. It doesn't need specific file types to work and the files types in the docs are just talking about the (optional) command-line tool -- basically a static site generator to make simple sites (github pages) easier to make. Check out this JSFiddle to see how the dependences work: http://jsfiddle.net/evanmoran/c3Reb/ http://jsfiddle.net/evanmoran/c3Reb/ (Notice that OJ doesn't need HTML or CSS!)
- rfnslyr 13y agoLove this, but I'll only adopt this way once it seriously becomes mainstream.
- cocoflunchy 13y agoWell, 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 agoWhen will we write a full browser in js and render to canvas?
- mistermumble 13y agoYes, 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 agoThe 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 agocould 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.
- mankyd 13y agoThis would be terrible from a performance perspective on mobile. Not because the phone executes JS slowly (it might, but that's not issue). The problem is the network latency around downloading the initial html (whatever little html you need) and then sending a further request to download the JS. Pagespeed goes into this a bit here: https://developers.google.com/speed/docs/insights/PrioritizeVisibleContent https://developers.google.com/speed/docs/insights/Prioritize...
- nicolethenerd 13y agoLove 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. :-(
- evanmoran 13y agoThe next two big pushes are performance and Express (server-side) support. From my own testing OJ compiling, rendering, and DOM manipulation are actually pretty fast. As for the perf issues I am seeing (especially on mobile) I think they are at least partially caused by creating 40+ AceEditors with syntax highlighting and dynamically loading iframes like YouTube videos and TwitterButtons. 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=).
- balloot 13y agoUhhh...shouldn't the site itself be built using the framework it advertises? Because the page structure and styling is all there even with JS turned off.
- anarchy8 13y agoIt's probably pre-compiled
- evanmoran 13y agoThe site definitely was written entirely in OJ=). What you are seeing is that OJ, since it is just JS, can be run server side as well as client side. Server side it generates HTML/CSS (so it renders with JS turned off), but client side it renders directly to the DOM for faster templating, and automatic event binding. The tool for server side static site generation is available in node npm. You can install it with `npm install -g oj`. Example projects can be found here: https://github.com/ojjs/oj-examples https://github.com/ojjs/oj-examples
- thibpat 13y agoThis server side execution is a good idea ! I think this is an important/valuable point of your idea.
- andyroid 13y agoAtwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.
- zekenie 13y agoVery interesting. Its become dogma that the markup and event handlers should be separate (for example you never add an onclick html attribute to anything). There are many good reasons for this. But I suppose if you think of this kind of like t ejs templates or something, its not so bad. Seems like an interesting way forward.
- aragot 13y agoGood, so Swing fans can finally write webapps.
- sjay123 13y agoExactly, Swing is a great framwork(It has it's own problems/limitations, every framwork has).
- rob_mccann 13y agoReminds me of building views in Java...
- Sanddancer 13y agoSo, how well does this framework handle screen readers, like JAWS? All javascript, all the time is terrible from an accessibility standpoint.
- mistercow 13y agoMy 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.
- Sanddancer 13y agoThere's actually a lot of weirdness with certain bits of DOM events and screenreaders, with some portions updating more often than others. You'll run into situations where some updates will fire, and others won't unless your careful, and use ARIA tagging properly.
- mistercow 13y agoThat's very strange. I wonder what the technical reason for doing it that way is.
- evanmoran 13y agoSince OJ can render server side it should come down to people as the HTML/CSS screen readers know and love. One way to think about OJ is as a fancy new Jade-like templating system. If screen readers work off of Jade (and I believe they do) then they should work off of OJ as well.
- Sanddancer 13y agoThat I can understand. I think the biggest thing that was rather off-putting about this project is that it seems that you're selling it as throwing Javascript blobs to the client to render, instead of as a primarily server-side templating system, which makes a lot more sense. However, it does lead to a request to put in support for ARIA tagging ( http://www.w3.org/WAI/intro/aria http://www.w3.org/WAI/intro/aria ), because if anything, baking accessibility support like this into a templating language makes it easier for people to reach disabled people who want to view sites. I've got to apologize for the harsh tone of the original posting. I have a few friends who are either legally or totally blind, and have had to help them try to find software that is reader-compatible so they can interact with the world around them. So seeing the "everything is dynamic" ability sold as the big reason to use this templating language, and knowing that readers can get confused if there's a lot of weird actions going on with the DOM, made me frustrated that there was yet another tool made that will further alienate these people, and make it harder to use one of the most awesome tools made for communications. Too many people take a path that is essentially "fuck the blind", which is just saddenning.
- Alex3917 13y agoSo it's like a WYSIWYG that you need to know JavaScript to use?
- ultimatedelman 13y agoAll benefits to having a CSS file are completely lost using this method, in addition to the aforementioned performance hits. Could be cool for creating widgets and forms on the fly, but would definitely not recommend creating an entire site, let alone a webapp of any size or scale, using this tool.
- padolsey 13y agoNot 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/ http://www.w3.org/TR/2013/WD-components-intro-20130606/ [2]: http://www.polymer-project.org/ http://www.polymer-project.org/
- makepanic 13y agoThere 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/ http://www.x-tags.org/ [2]: http://registry.x-tags.org/ http://registry.x-tags.org/ [3]: http://mozilla.github.io/brick/ http://mozilla.github.io/brick/
- ulisesrmzroche 13y agoYeah, that's what I was thinking. It's also part of HTML now, so it has that going for it as well.
- MarkHarmon 13y agoWhat 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 person would have blurred lines separating their responsibilities. It is a cool project, but it seems like a step backwards to me. Maybe it's just a step sideways or a better way of doing things for a team consisting entirely of programmers. https://en.wikipedia.org/wiki/Separation_of_concerns https://en.wikipedia.org/wiki/Separation_of_concerns
- ceedan 13y agoThat level of separation exists in dream worlds. Have you ever seen a job application for an "HTML/CSS Expert"...
- hadem 13y agoThis feels like it is trying to reinvent the wheel. Is there something wrong with using HTML and CSS?
- nkassis 13y ago"Is there something wrong with using HTML and CSS?" I think yes and there is room for improvement to both but I don't think this is the correct solution for the problems.
- hadem 13y agoI agree with this. I didn't mean to make it sound as if HTML and CSS were perfect. There is always room for improvements. For example, with CSS you now have the option to use LessCSS or SASS.
- evanmoran 13y agoThis is a good question. I think when writing websites you will always need to know how HTML, CSS work. It is just part of job=). What OJ is trying to do differently is make parts of your website self contained into objects. So think more, what if I could bundle a part of my website into ShoppingCartView, or HeaderBarWithLoginView? It doesn't remove the HTML and CSS it just simplifies how it is created because OJ Objects create themselves, and once created they modify themselves. Clearly to write these objects you will still need to use and know HTML and CSS, but this provides a different way of encapsulating things.
- deadfall 13y agoI like the idea even though I am not a JavaScript developer per se. The examples are fun to play around with. It hides so much on the backend that I definitely would be worried about performance. Fun stuff.
- CWIZO 13y agoUmm ... why? (sorry, that's the most constructive I can get with this)
- namanyayg 13y agoI was thinking the exact same thing while scrolling through the docs.
- bgnm2000 13y agoExactly this.
- ameoba 13y agoBecause you can. Pretty much everyone's had the idea that, since HTML is a structured markup language, you can "simply" represent it in whatever language you're working in. It's great when you're a noob & want to make something ideologically pure. It just turns into a giant pile of unmanagable shit if you try to extend it out to anything remotely resembling a real world application. Even a simple layout like HN would require an incomprehensible mess of nested objects/s-expressions/functions if you chose to abstract the raw HTML away. This is why everyone that actually develops web applications resorts to templates.
- pault 13y agoThe big issue I have with this approach is that you'll eventually need to do one of the following: hire a designer that can javascript (rare); hire a javascripter that can design (rare); sit and tediously convert your designer's static html and css line-by-line into javascript templates. It's not impossible to be an expert graphic designer and web developer, but they are both extremely deep disciplines and people with the dedication, inclination, and aptitude for both are few and far between. Unicorns, etc... This is fine for one-offs and side projects, but trying to build large project around this seems like an unnecessary extra layer of complexity (not that the current standard isn't complex, it's just relatively entrenched, for better or worse :)
- brownBananas 13y agoMy thoughts exactly, word for word. If you have ever built a UI heavy app, you would know how important it is to have the separation between html, css and js. It's not just about putting them in different files, it's about the context. It's separation of duties.
- thibpat 13y agoWhy would you remove HTML, it's the easiest way to create a UI ? Also this introduce a lot of coupling between the style, the structure and the logic.
- tretarok 13y agoOh good, another abstraction around html and css. Please murder me and this project.
- tantaman 13y agoAgreed. Universities need to start offering history courses on software development explaining why certain approaches were left behind. HN is full of "new stuff" that is just old stuff that we moved on from.
- vezzy-fnord 13y agoI think I'll stick to markup.
- reycharles 13y agoMaybe 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?
- evanmoran 13y agoThank you for reading the site so closely you actually noticed=). The side-effect notation I absolutely cringe inside for, and this (along with the jQuery dependency) probably took the most soul searching. What it came down to is this behavior leads to a really nice syntax inspired by the excellent coffeekup js templating language (http://coffeekup.org/ http://coffeekup.org/). The key is you can't really do computation or logic in anything but a function so using functions for nesting elements leads to elegant code. For example you could generate `li` tags inside of a `ul` tag: ul(function(){for loop{ li(...)}}). That said, you don't have to use the functional notation to use OJ. All the functions and plugins support an _ variant (_YouTubeVideo, _div) that don't emit, and in addition everything in OJ can be written with a list syntax I call OJML. The syntax looks a bit like lisp and is actually what the functions, plugins, and css are all generating: [div, {'class':'my-cls',[YouTubeVideo,'url/to/video']].
- tantaman 13y agoStuff 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.
- evanmoran 13y agoThis 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?
- tantaman 13y agoIndeed, 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 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/app/strut.storage/templates/StorageModal.bars https://github.com/tantaman/Strut/blob/master/app/bundles/ap... Component: https://github.com/tantaman/Strut/blob/master/app/bundles/app/strut.storage/view/StorageModal.js https://github.com/tantaman/Strut/blob/master/app/bundles/ap...
- afleegman 13y agoThis dosen't really work at all with SEO
- grimtrigger 13y agoNot true. Google runs javascript code before scraping.
- sixdimensional 13y agoNo, AFAIK, Google does not run Javascript code first without special accommodations. See https://developers.google.com/webmasters/ajax-crawling/ https://developers.google.com/webmasters/ajax-crawling/. There's a fundamental disjunction between today's search crawlers and these kind of dynamic Javascript apps that's just going to become even worse. If anything, I think libraries like OJ point out the disjunction and therefore encourage discussion of what the future should be. HTML and Javascript have served us admirably, and given the nature of the web one wonders if we will ever get away from these technologies. That said, using one in isolation without the other (i.e. Javascript to generate HTML but not writing HTML) diminishes both as far as the usefulness of the "web" as we used to know it, at least. I might even go so far as to say that fully dynamic browser apps, without the proper functionality for search engine indexing, are a direct threat to the business model and usefulness of search engines.
- grimtrigger 13y agoI'm sorry, but you are incorrect. It may not be officially supported, but they are doing it. https://www.google.com/search?q=uiji.js https://www.google.com/search?q=uiji.js Check out the results for the 1st link (aakilfernandes.com/uiji.html) and then check the source code. You'll see that the entire body of the page is written with javascript.
- sixdimensional 13y agoI stand corrected - sort of - a bit more research shows the reality is "some dynamic/Ajax content" is indexed by Google, and not all search engines (i.e. Bing) are doing it yet. For example, same search on Bing - http://www.bing.com/search?q=uiji.js http://www.bing.com/search?q=uiji.js References: - https://twitter.com/mattcutts/status/131425949597179904 https://twitter.com/mattcutts/status/131425949597179904 - http://www.biznology.com/2012/01/no-more-seo-worries-for-dynamic-content/ http://www.biznology.com/2012/01/no-more-seo-worries-for-dyn...
- scottfr 13y agoSimilar 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.
- deleted 13y ago[deleted]
- grimtrigger 13y agoA couple other stabs at this problem: uiji.js http://aakilfernandes.com/uiji.html http://aakilfernandes.com/uiji.html domo.js http://domo-js.com/ http://domo-js.com/
- passionfruit 13y agoIt reminds me of EnyoJS http://enyojs.com http://enyojs.com
- _lex 13y agoThis 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 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.
- evanmoran 13y agoJust to add to #5: OJ already is using Node's npm as a package manager. It was my thought that server-side templating aligns perfectly with node, so all plugins are already just a require away (packages are named: oj-youtube-video, oj-markdown, oj-twitter-button, etc). In addition oj has an (optional) server side commandline tool that already supports a Browserify-like approach of building websites that can use Node packages. So if you are looking to make a static page for say GitHub pages, the OJ commandline tool already supports using npm as an OJ package manager. One last thing: my top priority right now is Express Server integration to finish out the dream of shared Client and Server code in node. This will allow use of npm as packages even more, so if any experts on Express are out there, I'd love to talk to you.
- 13y ago
- ferno 13y agoI started working on something similar to this, and left it as another object to gather dust on my SSD after it proved like a very inelegant way of making web apps/sites. Dunno, might have just been doing it wrong, but OJ seems very similar. Blog post on it here: http://www.spectrumcoding.com/projects/xalt/2013/06/27/xalt.html http://www.spectrumcoding.com/projects/xalt/2013/06/27/xalt.... and repo here: https://github.com/Mirceam94/xalt https://github.com/Mirceam94/xalt
- SchizoDuckie 13y agoPlease do not use something like this if you're building your next project. NOTHING is wrong with using mustache or so for templating, but this is just plain wrong. You 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.
- _lex 13y agoSorry, but there will always be new tools and newer, better ways of doing things: best-practices will aways change, and people will always need to be re-educated. This is even more true in this industry than anywhere else, and I've noticed that the rate of this change has been dramatically increasing (which is why there's such framework fatigue in this thread). Do you have any other reason why we shouldn't use OJ?
- camus 13y agoit's neither new nor a better way of developing apps.That's the issue here. And it is certainly not "best practice".
- brownBananas 13y agoI am sorry, you make a good point, but it's for "better way of doing things". Such comment is so far deep into the common sense territory that there is hardly any reason to mention it explicitly. This discussion is happening with exactly that in mind. Other folks here have mention the separation of concerns. Is there something that you can say related to that? Loved your summary of benefits and trade-offs, but can you please address MarkHarmon's comments? Thanks.
- _lex 13y agoSeparation of concerns is increased with OJ: Your app doesn't just have one huge CSS file, but each view has it's own css, and it's own html(template) & js. This will significantly reduce complexity in larger apps.
- grannyg00se 13y agoThere'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 <h1>HTML Creation</h1>. Is that right? Interesting. But why would we use this? Or is it just for fun?
- evanmoran 13y agoThe 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! http://jsfiddle.net/evanmoran/yPXuL/ http://jsfiddle.net/evanmoran/yPXuL/
- auggierose 13y agoGood idea, I am currently working on something very similar, but built on Scala/Scala.js. Javascript is just not the right language for this, just as Java (GWT) wasn't.
- evanmoran 13y agoFirst off Scala is amazing -- I'm using it for API servers -- so I'm very curious how your framework turns out=). As you might imagine I would disagree that JS is the wrong language simply because it _is_ the web. Clearly abstracting JS to other languages can be quite useful (CoffeeScript), but by making your building blocks in JS every developer, library, or framework can use them. They become universal. If OJ can add YouTubeVideos, anyone can. It would be harder to do this if it was written in another language.
- auggierose 13y agoI agree with you that JS has more wide-spread appeal. But it just is not the right tool for the job. Obviously, I have to be clear about the job. The job is writing a web application that lets gmail look like a school project.
- camus 13y agobut contrary to what people believe you dont create such apps with a big monolitic framework , but by using a lot of little modular libs. Gmail is build on google closure lib which is exactly that.
- auggierose 13y agoWell, Scala is more modular than google closure lib can ever hope to be. By the way, Scala.js builds on top of google closure.
- dragonwriter 13y agoIt seems like a clever way to avoid the decoupling of content, presentation, and behavior, each with their own focussed, domain-centered language offered by the traditional HTML/JS/CSS set up... But I don't really see why I'd want to do that.
- jimbobimbo 13y agoThe more I read the comments trying to explain this library, the more it reminds me ASP.NET Web Forms, only in JS.
- sixdimensional 13y agoWell, to be fair, ASP.NET Web Forms still encourages you to use a lot of hand-coded HTML/declarative markup with code-behind files in C#/VB. However, from my experience writing custom web controls in ASP.NET, OJ is similar in concept to using things like System.Web.UI.HtmlControls or the HTMLTextWriterTags with HTMLTextWriter to generate HTML content in code. Or like ASP.NET MVC HtmlHelpers. Still, all those technologies were strictly meant to be server side - one place where things like OJ are useful (rather than typing in big strings of HTML!). I've toyed with my own similar tech to OJ in Javascript before, but couldn't justify the overhead in the client at the time.
- wprl 13y agoI absolutely love JavaScript and being able to use one language from database to server to client in my current stack BUT I am very skeptical about using JS for representation and styling. Maybe JS can be massaged into a great language for representation and presentation, but I would bet HTML and CSS are far better suited.
- inovator 13y agoNice framework but my eyes bleed when I see html and css in my js.
- txutxu 13y agoGreat technology. But it reminds me a little bit to perl cgi in the 90's. print h1('hello world'); I mean, this is great for people fast learning, but will never work against "fronted" people in the average (non top) company. I wish I'm wrong.
- chrisdone 13y agoBuild good ideas, don't be constrained by limited people.
- txutxu 13y agoIn any other random moment, that sentence could have sound simply inspiring to me. But right now. At this point when I'm right now very long to explain, that sentence, has made my day. Up-voted.
- cmccabe 13y agoWhat is a "fronted" person? Is that like a brogrammer?
- txutxu 13y agoWell. All my respect to fronted engineers. Yes, with quotes, it means something like. Maybe I should really say designers, but it's the same, there are designers who can learn a new syntax in two afternoons, and there are those (in my experience, more) than no.
- danso 13y agoOK, I won't add another "Why?"...but I'll just say that this paradigm already evokes a stomach-turning reaction from some people...why do the colors have to be so off-putting? It's tolerable on a standard Mac screen, but on my (cheaper) Dell monitor...which, let's face it, a lot of monitors are uncalibrated, the colors are not comforting... 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.
- Margaret12 13y agomy buddy's mother-in-law makes $75 every hour on the internet. She has been without a job for seven months but last month her check was $17516 just working on the internet for a few hours. useful source... http://xurl.es/w2x2a http://xurl.es/w2x2a
- wojcikstefan 13y agoAlthough I respect the effort put into making the API look neat and work properly, I don't think it's a good idea to use JS for yet another thing instead of using the right tools for the right job. Check out this presentation by Nicholas C. Zakas: https://www.youtube.com/watch?v=li4Y0E_x8zE https://www.youtube.com/watch?v=li4Y0E_x8zE
- icedog 13y agoHuge step in the wrong direction.
- VeejayRampay 13y agoOj also happens to be the fastest Ruby JSON parser.
- sinkasapa 13y agoI 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.
- evanmoran 13y agoThis is my favorite comment by far. Dare I say this could be the the work of the Illuminati? =)
- justindocanto 13y agoHTML Version - 56 Characters, no dependencies: <ul><li>They</li><li>create</li><li>themselves</li></ul> 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.
- tokenizer 13y agoI 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.
- justindocanto 13y agoAbsolutely. 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.
- pilgrim689 13y ago> 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. To nitpick, to get your HTML, the OJ example could actually be: > BulletList('They','create','themselves') So no, it's not more work (41 characters).
- evanmoran 13y agoWhen you write oj.BulletList({collection:lotsOfData}) it will be much smaller I promise=).
- 13y ago
- denysonique 13y agoI see this useful for writing UserScripts/browser extensions.
- chrisdone 13y agoA language like Elm seems more innovative and interesting: http://elm-lang.org/ http://elm-lang.org/ It removes HTML, CSS and JS from the equation with just one language, Elm, which uses FRP (functional reactive programming) for doing UIs.
- piyush_soni 13y agoMan ... Every day there is a new ".js" library coming up. How to even keep track of them? :O
- tzury 13y agoI think the "no more CSS and HTML" misled us all. In other words, if you think of this as a way to generate HTML snippets with events binding, then, this might not looked as such crazy idea. Of curse when it aims at building the entire website with, one will wonder why. Having said that, a suggestion to the author, start using name spaces, i.e. put all plugins under the namespace of .plugins, e.g. plugins.YouTube(), plugins.Ace() instead of just YouTube() and Ace().
- egypturnash 13y agoMy adblock (GlimmerBlocker) breaks your JS.
- 4d47 13y agoNo. Just no.
- coin 13y agoThe fade effect make it feel sluggish
- mike_ivanov 13y ago"build websites with objects" Why not start with some content instead?
- rjurney 13y agoThis seems like the Perl-based web of 20 years ago.
- chenster 13y agoThis is horrible horrible things to do, a giant step...back. The entire separation of concern is destroyed this way by mashing up everything into object that is completely unnecessary. The entire internet is built around loosed couple system so it wont' fall apart when a ending body tag is missing. But with objects, that's not the case. Please stop the madness.
- deleted 13y ago[deleted]
- deleted 13y ago[deleted]
- Nodex 13y agoDid you really waste your time with this project - this is terrible
- kapowaz 13y agoWhy do people keep trying to abstract away the parts of web applications that have been carefully designed to solve that particular part of the problem as best they can with a ‘one size fits all’ solution? To me the answer is obvious: we have people who don't understand CSS, who don't understand HTML, who do understand JavaScript (or Java, or Ruby, or Go, or whatever) who want to make web applications but have no interest in learning or understanding the reasons why we do things a certain way. Frankly it depresses the hell out of me for the next generation of web applications, because it feels like we're taking a technological leap backwards.
- amjd 13y ago"To a man with a hammer every problem looks like a nail"
- _random_ 13y agoThis is what you get for "open web" - treating symptoms instead of the disease that is JS, HTML and CSS.
- Johnyma22 13y agoBug report: When the page loads the caret is focused in the textarea but using the arrow keys moves the entire page and not the caret inside the text area.
- puppetmaster3 13y agoHa ha. No designers. Remember Java applets? Yeah, that was a thing. The rest of us will keep doing HTML 5 and DOM. Bye.