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

161–170 of 191 posts

Re: No more CSS and HTML, just JS

#161

Post by iopq »

mstrem wrote: post #138
cocoflunchy wrote: post #6

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

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.

Re: No more CSS and HTML, just JS

#162

Post by evincarofautumn »

zalew wrote: post #125
kunai wrote: post #123

Earlier quoted context omitted.

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

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

> an email message is a document too.

An email client is not.

Re: No more CSS and HTML, just JS

#163

Post by txutxu »

cmccabe wrote: post #155
txutxu wrote: post #81

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

What is a "fronted" person? Is that like a brogrammer?

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

Re: No more CSS and HTML, just JS

#164

Post by _lex »

brownBananas wrote: post #160
_lex wrote: post #132

Earlier quoted context omitted.

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

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 without HTML/JS? NO!

Can JS alone be the view? Yes, but you'd have a lot of inline css and html - it'd be and a pain in the ass to maintain.

So if you want a single, true View in your MVC, you'd need a view that has all three parts. Other frameworks like backbone try to do something similar - backbone allows you to let your view have a template, but backbone views rely on external css and often attach to dom elements that aren't even in the view's template. So what you have is a view that's only referring to/aware of a few of it's actual dependencies. That seems sloppy if you ask me.

Also, if I had a TweetView that was a backbone view, and I wanted to move it to another person's system - maybe I created an awesome design and called it AwesomeTweet - other people who wanted to consume AwesomeTweet without OJ today would have to include a css file, some html (or a template) and some JS. Each presents a rich opportunity for namespace collisions, and for my bad documentation to make it difficult to import AwesomeTweet as a module. Instead, OJ could allow a simple line like showAwesomeTweet('2131221121'), which would be guaranteed to work everywhere, simply.

Does this explain the "why" better?

Re: No more CSS and HTML, just JS

#165

Post by _lex »

kcbanner wrote: post #159
_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…

Why would you ignore code size? Its a huge factor in load times.

I'm ignoring it because I'm assuming that you'll download the file ONCE from cdn.awesomesauce.com/oj.js when you're on my website, then the next time you return to my website, or you go to tom, dick or harry's website, once they have the same url for the file and it's cached in your browser, the load time will be near 0.

Re: No more CSS and HTML, just JS

#166

Post by _lex »

etjossem wrote: post #87
zeteo wrote: post #69

Earlier quoted context omitted.

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…

Ten years ago, we were all tempted to put tags in the HTML "in order to have the entire website in one place." As site complexity grew, we realized we needed to start separating components that had distinct roles. If I'm changing a font site-wide, I don't want to scroll through lines of totally unrelated copy to get to my styles. I want completely separate files that only need to reference each other (via classes and…

Things like fonts can be defined at a high level by higher-level css tags or classes. I usually use less instead of direct css, so for me I'd just throw in an import in each view's less file to get the default styling applied, or I'd just have basic font styling done at a higher level in css so at the level closer to the actual class, I'd only need to apply tweaks as needed.

Re: No more CSS and HTML, just JS

#168

Post by kapowaz »

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

Re: No more CSS and HTML, just JS

#169

Post by Isofarro »

ulisesrmzroche wrote: post #140
_lex wrote: post #120

Earlier quoted context omitted.

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…

But there's a right way to do it already, and the definition of a solved problem is one people are making money off, so steering people away from js webapps because of SEO is just bad There are no large caveats here, either follow a tutorial off Google Dev Guides or pay someone like $5 bucks a month to do it.

Gawker did this a while back. And reverted after their Google rankings took a hefty plunge. That is one very large caveat, that Ajax crawler spec is no magic bullet.

Nick Denton: "Dip in uniques largely because of drop in Google refers. Pageviews (which are driven more by core audience) less affected." -- http://twitter.com/nicknotned/status/61152134929981440

Nick Denton: "Google does not fully support "hashbang" URLs. So we're eliminating them rather than waiting for Mountain View." -- http://twitter.com/nicknotned/status/61465859079671808

Nick Denton: "Yeah, I'd advise against hashbang urls. Will kill search traffic -- even if you abide by Google protocol." -- http://twitter.com/nicknotned/status/62595141927583745

Post reply on HN