11 comments

[ 2.8 ms ] story [ 34.7 ms ] thread
I really have to ask... Why? What's the difference between this and using Nancy with a Knockout VM?
I don't know this framework, but I found the introduction page which explains what it is (1)

It also addresses the "why" question:

> build your app really fast. And this's the goal of DotVVM.

So it would automate the "boring" and boilerplate code on server and in web page to link everything up. I can't say if it's a worthwhile saving, or if the DotMVVM framework will handle the edge cases well enough. In my experience, that's where frameworks fall down if they fall down - they wow you by making the simple things trivial, but then the non-standard things become prohibitively hard.

But that that's the idea, anyway.

1) http://www.dotvvm.com/docs/tutorials/introduction

We tried to make it extensible enough to handle most use cases. Of course, neither things like GC don't solve every possible use case and I expect DotVVM to be much more "specialized". It is based on knockout and probably will not be very useful in application, where knockout would not be.

However if you would have troubles with something concrete don't mind to ask us. And have created a gitter room for chatting about it: https://gitter.im/riganti/dotvvm

I'm not sure this is a good thing... the PFM (pure fucking magic) reminds me of ASP.Net controls (including from paid vendors) and the shear nightmare they became as soon as things got mildly complex, by hiding too much.
>PFM (pure fucking magic)

This acronym is beautiful.

That's a cool library you have there but have you considered restructuring it to fit PFM pattern ?

Worked at a place it was used to get around explaining... "I'll run it through PFM, should be done by Thursday."
Still, I always found ASP.NET Web Controls easier to deal with than JSF ones.
I'm not disagreeing with that... I just found that the more I tried to create my own, more complex controls the easier it was to just use HTML with JS, and bypass the WebControl paradigm entirely. Which is a huge part of why I really liked MVC.

Though today, I'm more into writing a front end almost entirely separate from the backend. Coupled service layer in node, that acts as a gateway from front-end to back-end... Much less of a disconnect to work with. Doing things the "hard way" is usually easier once a project reaches a certain complexity.

It always comes with abstraction, it is the same with more complex Html helpers in MVC or any other .NET library.