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.
Show HN: DubJS: A New Way to Build Web Apps
11–20 of 24 posts
Re: Show HN: DubJS: A New Way to Build Web Apps
#12Interesting 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.
Re: Show HN: DubJS: A New Way to Build Web Apps
#13Earlier quoted context omitted.
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.
Thanks, that is my thinking: learning three separate languages is a big burden, especially on beginners.
You would need to know them a bit at least - for debugging.
Re: Show HN: DubJS: A New Way to Build Web Apps
#14In 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.
Re: Show HN: DubJS: A New Way to Build Web Apps
#15"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.
Re: Show HN: DubJS: A New Way to Build Web Apps
#16Re: Show HN: DubJS: A New Way to Build Web Apps
#17Kudos 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…
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?
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.
Re: Show HN: DubJS: A New Way to Build Web Apps
#18In 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…
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.
Re: Show HN: DubJS: A New Way to Build Web Apps
#19Hi 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.
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();
};
Re: Show HN: DubJS: A New Way to Build Web Apps
#20The 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.