Show HN: DubJS: A New Way to Build Web Apps(dubjs.org)
dubjs.org
Show HN: DubJS: A New Way to Build Web Apps
http://dubjs.org/blog/intro
7 comments
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.
Thanks for the feedback.
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.
Hi HN,
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.
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 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).
Done. Thank you.
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
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();
};
You're right. I knew I'd miss something! Thanks for catching my mistake.
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!
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!
Agreed, it's not meant to be a universal replacement for standard web development, but as useful option where appropriate.
Thanks for your kind words.
Thanks for your kind words.
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.
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.
Kudos for the effort, but it won't fly.
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.
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.
Clojure has this sort of thing and any other homoiconic language gets it for free.
Thanks for your honest feedback.
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?
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?
No. Javascript is just a general purpose language. It could very well serve as a DSL for layout or presentation. But the browsers already have that, it's called HTML and CSS.
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.
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.
For what it's worth, my intention is to overcome some of those issues that you mention. First, I assume you're talking about accidental pollution of the global scope (by omitting 'var'), which can be avoided: see CoffeeScript. Also, I have some ideas to improve the 'scope mess', as well as prototypes.
"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?
?!? 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.
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.
You're right, it's a rare case. I will change that bit.
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.
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.