In my own experience, such simplications begin to fall apart as soon as you find the slightest bit of complexity in what you're building upon them. As soon as something doesn't fit the mold, you adjust the mold - or worse, you adjust the something. The next thing you know, you're spending more time customizing your framework than you are being truly productive.
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.
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
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.
If it's possible to change the title, please prepend with Show HN. Some people (including me) like to vote just for the sake of it. There was a discussion here to vote up Show HNs to support those who ship (can't remember the link though).
I can't see how the compiled code for Type is supposed to work?
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.
As long as it doesn't become abandonware, I could certainly see this serving a niche segment of developers. There continues to exist a surprisingly large number of RAD tools on the market despite many having innate limitations that drastically limit their scope and applicability.
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!
The code looks very cool. Great job on creating such a concise dialect. I would have fun experimenting with this, but that's probably as far as it would go as the massive number of people that are already comfortable HTML/CSS can't be ignored. I think it's easy to discount the value of mind share, but why try to replace HTML/CSS when every beginning web developer knows it?
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.
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.
I think it could totally fly with a language with good declarative support. Why learn separate syntax (html, css) when all you need is some declarative semantics?
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?
"In many cases you might want part (or all) of your app to be served as static markup. Reasons can include rendering speed, supporting environments where JavaScript is missing (or disabled), or search engine optimization."
?!? Why would anyone, ever, serve APP as static pages to those having JS disabled. Web site, thousand times yes, but APP?
There is a case for doing both, pre-rendering on the server, and rendering updates on the client. This approach is used by Google plus for example.
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.
Interesting approach, but I far prefer the tack that Angular.js is taking, where they are embracing HTML and extending it's utility, not abstracting it away.
My thinking is that HTML has limitations, and can cause a lot of repetition. That's one of the reasons for the abstraction (along with avoiding the need for three separate languages), but I can understand that some people might prefer it as is.
enobrev|13 years ago
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.
keen|13 years ago
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.
keen|13 years ago
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.
wiradikusuma|13 years ago
timruffles|13 years ago
If you deference a JS function from an object, you lose the context of `this`. So in
`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.dpriddle|13 years ago
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!
keen|13 years ago
Thanks for your kind words.
ericingram|13 years ago
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.
mmariani|13 years ago
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.
lucian1900|13 years ago
Clojure has this sort of thing and any other homoiconic language gets it for free.
keen|13 years ago
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?
atirip|13 years ago
?!? Why would anyone, ever, serve APP as static pages to those having JS disabled. Web site, thousand times yes, but APP?
deliminator|13 years ago
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.
keen|13 years ago
marknutter|13 years ago
keen|13 years ago