Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

No more CSS and HTML, just JS

ojjs.org

Post reply on HN
Print view View original

171–180 of 191 posts

Re: No more CSS and HTML, just JS

#171

Post by Sanddancer »

evanmoran wrote: post #124
Sanddancer wrote: post #18

So, how well does this framework handle screen readers, like JAWS? All javascript, all the time is terrible from an accessibility standpoint.

Since 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.

That 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 ), 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.

Re: No more CSS and HTML, just JS

#173

Post by e12e »

evanmoran wrote: post #142
e12e wrote: post #139

Earlier quoted context omitted.

I think this is fascinating -- but I'm not quite sold yet. I've been thinking a lot about frameworks along these lines; use js (or something that compiles to js) for the logic, allowing shared code-bases on server and client. One major motivation would be to seamlessly render on server for clients that doesn't support javascript (be they lynx/w3m or some crawler etc). Another would of course be to try and keep things…

This is really insightful. Thank you for giving it serious thought=). The main reason to make them different is I saw them as different use cases: the client-side folks just want a single script (oj.js) include to make things easy to get started with. The server-side people are already comfortable with the Node npm module system and so using `require` to include different files / modules made sense. I mostly didn't w…

Perhaps adding support for thin "client-side" shim, so that you'll have just a html of something along the lines of:

    
      
        OJ Example: html shim
        
        
          
        
        
          
      
      
        
          Something went wrong
          
So sorry. The server was unable to detect that
          your client doesn't support javascript. Please try:
          magick.
          (Maybe that should be a client side redirect, via a meta-tag:)
Now, example.oj will pull in stuff via require etc, and given a "smart" server, the same page/app can render client side and server side?

[edit: The oj.js script should also probably be able to redirect the client "back" to client side rendering, if it detects js -- so that if google links to url/?server-side-rendring=true -- not all clients from google will be "forced" to do server side rendering.]

Re: No more CSS and HTML, just JS

#174

Post by e12e »

ulisesrmzroche wrote: post #112
_lex wrote: post #62

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…

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…

And while google certainly is important, it isn't the only crawler. Others are important both in "absolute" terms (duckduckgo/bing ?) -- and for "local" and possibly "domain" search (yandex, baidu).

Not to mention internal crawlers for site-wide search (although you can of course adapt those -- why do it if you don't have to?).

Re: No more CSS and HTML, just JS

#175

Post by auggierose »

evanmoran wrote: post #100
auggierose wrote: post #70

Good 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.

First 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 a…

I 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.

Re: No more CSS and HTML, just JS

#176

Post by zanny »

tomphoolery wrote: post #119
mistermumble wrote: post #19

Earlier quoted context omitted.

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 u…

The reason this is happening at all in the first place is because html / css / js is the only platform agnostic toolkit. Everything else lacks support somewhere, and the big businesses behind technologies will actively avoid supporting someone elses otherwise cross platform framework.

Same thing with dynamic languages. You cannot write a Java, Python, or Ruby app and expect it to run on any device. Just doesn't work when you need to also distribute the runtime framework on a per platform basis.

Similarly, you have semi-portable C# and C++ through Mono and Qt that reach pretty much every major platform (the primary limiter is ios being so locked down) but they both need to do ugly repackaging of their entire toolkit runtime and framework that has to somehow jump through hoops to get installed locally whenever you try to install such a program.

But you can expect html, css, and js on everything. And that is why everyone tries to stick completely tangential computing techologies (html is not a widget toolkit) and hope for the best. Because it is the only write once, run everywhere where the run everywhere actually happens, even if your site ends up being double in size for mobile and desktop versions or reactive with tons of overhead in element scaling, plus all the conditionals for old versions of IE, having to import require.js or something to check for feature compatability, etc.

But you can work with that. You can write megabytes of JS to try to weasel around the mess. There is literally nothing you can do to get a python app running on average joes iphone.

I really hope qml can take off in a big way, and become a standard of some sort. It is in my experience the portable ui toolkit for actual applications that is portable and looks native since 5.2, and it even lets you script it in js so you never have to compile anything with a qmlscene binary. And it is designed ground up to have any resource local or networked.

Re: No more CSS and HTML, just JS

#178

Post by hrjet »

iopq wrote: post #161
mstrem wrote: post #138

Earlier quoted context omitted.

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…

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.

One could argue if that is "style" or "behaviour".

Re: No more CSS and HTML, just JS

#179

Post by hrjet »

_lex wrote: post #164
brownBananas wrote: post #160

Earlier quoted context omitted.

How is that different than another framework such as Angular JS, or something like web components perhaps? Each view, or directory or component can have it's own CSS file with existing solutions too. What we are seeing here is an attempt to solve the same problem, but by doing all the work by using JavaScript. Cool. But not impressed.

Currently, views are split into 3 places: html, css + js (for rendering updates - usually done with a template). The big difference here is saying that the view is actually all three things/ that it's made up of all three components, which is closer to the truth than other systems of thinking. Can HTML be the view without css and without js binding for events and updates? Not in a modern app! Can CSS be the view with…

"Instead, OJ could allow a simple line like showAwesomeTweet('2131221121'), which would be guaranteed to work everywhere, simply."

Ah, but you are sacrificing uniformity of design there. What if I would like the style of the tweet to be consistent with the overall style of my app? And this style is managed by a separate designer not a programmer?

Modularity works fine for behaviour, because it is better to abstract and encapsulate behaviour. But modularity doesn't necessarily work great for looks and feels.

Post reply on HN