Writing everything in JS isn't gonna make it better all of a sudden, even if it's sanitized JS. HTML and CSS are fine for the jobs they do which is data description and layout.
The problem is JS itself. Specifically, the lack of opinionated language design infers on code. Then we end up having to reinvent the wheel all over again, and again. And we all know how productive that can be.
We have two options here. Writing in yet another language and compiling to JS or writing a JS framework that works around its flaws. I vote for the latter.
Clojure has this sort of thing and any other homoiconic language gets it for free.
Would you mind explaining what you mean by "the lack of opinionated language design infers on code"? Are you referring to the fact that it's not specialised for either layout or presentation?
What I'm referring to is Javascript syntax. It's way too ambiguous which often leeds to programming errors. For instance: the global variables gaffe, the scope mess, the sloppy prototypal implementation, etc.
Hiding that behind a compiler doesn't make the problems go away. It makes them worse.
This is my side-project that I've been working on for a while. It would mean a great deal if you'd give me some feedback.
If you deference a JS function from an object, you lose the context of `this`. So in
Ruby.prototype.cut = function () {
this.shape(); this.polish();
};
var old = Ruby.prototype.cut;
Ruby.prototype.cut = function () {
old(); this.engrave();
};
`Ruby.prototype.cut` will be called with `window` as `this`, so `this.shape` will be undefined. Use `old.call(this)` to get the behaviour you want.?!? Why would anyone, ever, serve APP as static pages to those having JS disabled. Web site, thousand times yes, but APP?
I wrote a simple implementation that uses google closure templates to pre-render the page with dynamic content on the server, and to me the app felt more stable. This feeling may be entirely subjective, as I didn't make any actualy measurements.
A counterargument may be that this approach does not scale and would overload a server resulting in worse stabilit/render-time in the end.
There is an inherent simplicity in HTML / CSS / JS that can be easily forgotten and difficult to replace. Each has its responsibility: Organization, Style, and Function - The combinations of these 3 simple entities are amazingly capable of representing the entire internet. That's a pretty difficult thing to simplify further.
Nonetheless, I like your approach and I wish you luck.
I agree in the simplicity of HTML and CSS if we're talking about simple websites. I've found that for more complex apps, and especially if you're using features of newer, half-specified standards (with style prefixes etc.) things can get a bit out of hand. One thing I want to point out is that you can separate your Dub code by style and function if you want to, although I can understand if you do not want that option.
Thanks for the feedback.
But they continue to exist because there are countless businesses demanding customized software for cheap. My thought is that a tool like this could very well be a welcome addition to the marketplace if it lowered the bar to entry of building web apps by a not-insignificant margin.
As long as DubJS isn't viewed as an effort to replace standard web app development, but merely another way for getting from A to Z that some developers find useful, I think it has a lot of promise!
Thanks for your kind words.
I don't feel any pain in writing HTML/CSS as it is. Also, I would feel a bit uncomfortable moving away from the underlying language, with the feeling that it might make writing/debugging regular javascript more difficult.