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.<p>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.<p>Nonetheless, I like your approach and I wish you luck.
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.<p>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.<p>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?<p>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.<p>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.<p>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.<p>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.
"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."<p>?!? Why would anyone, ever, serve APP as static pages to those having JS disabled. Web site, thousand times yes, but APP?
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.