No. Just no.
No more CSS and HTML, just JS
141–150 of 191 posts
Re: No more CSS and HTML, just JS
#142Earlier quoted context omitted.
Just 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…
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 want to force everyone to use a command-line tool / Node just to use OJ.
That said, I completely agree and hope over time more and more people will embrace the server-side way as it makes downloading and updating plugins really simple. Maybe in time that path should be emphasized more.
Re: No more CSS and HTML, just JS
#143Umm ... why? (sorry, that's the most constructive I can get with this)
Because 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.
Re: No more CSS and HTML, just JS
#144The fade effect make it feel sluggish
Re: No more CSS and HTML, just JS
#145Earlier quoted context omitted.
The solution is very similar to GWT, Google's ugly step child. Why ugly, because it uses Java... hiss! Boo! Yet it does make every optimization under the sun and boils it down to JS. Using JS to insert CSS, DOM nodes, and more JS is becoming pretty standard now. ExtJS and GWT led the way seven years ago, and frameworks need only dumb it down more to gain popular acceptance. I've been on teams that made award winning…
Have you ever used ExtJS? ...I have had the displeasure of developing with it at a large financial institution...it is madness...everything is a JSON object and what ends up happening is a mixing of concerns...putting logic, and layout in the same place. ExtJS didn't lead shit...there is a reason hardly anyone uses it. GWT I am not personally familiar with, but if it is at all like ExtJS I want to stay AWAY as much a…
> ExtJS didn't lead shit...there is a reason hardly anyone uses it.
One major reason is it's just so freaking large and unruly to do anything simple. It's one of the few frameworks I've used that even after moderate use, I still had to keep the docs open on one screen even during routine development. The error messages weren't very helpful, either.
Re: No more CSS and HTML, just JS
#146Earlier 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…
I think the web will always be more about delivering content, rather than manipulating data. Apps are all about data, documents are all about content. HTML and CSS are not fading away, they are actually getting bigger, and breaking into the desktop. I love javascript, but its more likely of being replaced by another scripting languange to work with HTML and CSS, than actually being a replacement for HTML & CSS.
Re: No more CSS and HTML, just JS
#147"build websites with objects"
Why not start with some content instead?
Re: No more CSS and HTML, just JS
#148This seems like the Perl-based web of 20 years ago.
Re: No more CSS and HTML, just JS
#149This 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.
Re: No more CSS and HTML, just JS
#150Earlier quoted context omitted.
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.
> 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).