Web Development Goes Pre-Visual InterDev

As a longtime and hardcore ASP.NET webforms developer, I’m finding the new client-side development world a bit of a grind.  I love learning new technologies, but I can’t help feeling we’ve regressed and lost our old RAD advantage as we move heavy lifting to the client.

For my latest project, I’m using Telerik’s KendoUI in Visual Studio 2012. To say I feel clumsy writing this much JavaScript is an understatement. It seems like the only safe way to ‘write’ this code is by copying a working snippet from someone else and pasting it into my HTML page.  For me, JavaScript has largely been for small UI tasks like client-side validation and a bit of AJAX – and often emitted by a server-side control.

I find myself today lost in nests of curly braces that Ctrl+K, Ctrl+D doesn’t seem to understand that well either. IntelliSense, my old syntax saviour, doesn’t seem to have kept up with this cobweb of code either. Code completion? Not seeing it.

As I fumbled about this evening, I thought about how web development rocketed forward when Microsoft introduced Visual InterDev. Its Design-Time Controls (DTCs) changed the way we created sites. All the iterations of Visual Studio have enhanced that server-side experience where you let a tool write the bulk of the code and manually finesse it from there.

What happened? Why am I typing  properties and values (especially default values!) into VS 2012 to get a client-side grid on a page? Where are the drag and drop objects that traditionally provided 70 percent of the mark-up and configuration?  Did we forget how to write Property Pages where you enter a value and the correct syntax appears magically in the source code?

To me, the tooling was looking the other way as the scene shifted from server-side code to nimble client-side script. It’ll have to catch up.

Although JavaScript is the lingua franca of web browsers, the language is unwieldy, tough to maintain, and messy to debug. If a .NET JIT compiler can turn our VB, F#, and C# source code into an Intermediate Language that executes on a computer, I don’t see why there can’t be a client-side compiler that turns a .NET language into JavaScript that browsers can consume.

8 Comments

  • lol - it's just the thing I had thought about doing myself tirelessly. There are two ways it can be done. Do you use actual .net functions (ie: vb functions) and accept them and run the javascript equivalent behind the scenes, so this way the user doesn't need to know any JavaScript functions at all. Or, do you show the actual JavaScript functions and meeds in the vb language intellisense? This way, user needs to be familiar with js functions and methods, but everything is the exact same, you dont need to write function converters or adapters to convert a vb function to a js function (as some may accept slightly different parameters etc).

    Or, do you just do both?

  • I feel your pain brother.

  • Resharper is your friend.

  • Tools have made us lazy and apathetic about learning how to do things for ourselves. You said it yourself. Drag a control onto a page and it writes the markup for us. I know there are plenty of people who can write html and JavaScript faster than I can fire up visual studio, start a new project and edit a page by dragging and dropping controls onto the page...

  • Eventually I think we'll get back to RAD, but it will be different. I woould love to see the work done in Blend 4 for Windows 8 Html development be used for Html in general.

    Right now the move to browser development is out stripping the asp.net feature release pace. One thing I think would be helpfull is a rich set of approachable scaffolding tools from the asp.net team. T4 and powershell scaffolding work, but they are not easy or intuitive.

  • Steve lazy? I think the word is productive. If you REALLY want to work hard Steve, go program in assembler.

  • I agree. Microsoft in its effort to be everything to every one of the HTML, CSS, JavaScript world has just returned to 1999. It appears that the server side controls have been relegated to ugly step children as everything will be web APIs and of course Azure. I think that's the key, at least in my mind, is the selling of Azure and they are changing the stack to mimic their marketing focus. Sell cloud services, relegate the code to the page and let the HTML5 revolution handle it all. Well we all know that won't fly and the server side is quite important especially for LOBs with lots of business logic and time conscious business customers. I don't want to return to miles long, hand written conditional logic in JavaScript again - might as well return to classic ASP if that is the 'NEW' approach. Pretty sad, that no new server controls or real enhancements to server controls have taken place since the listview in 3.5. I see minor incremental HTML5 attribute additions here and there, but not being promoted because the SPAs and MVC4 are the things to push via the MVPs. It's not about love for any particular technology, it's about changing the perception/message that once another slice of the technology pie comes out the old slice isn't rotten to the core, but then again that doesn't help sales of the new slice. In my opinion, and that is all this is, they will see more devs leave the stack because they are not helping the business application developers who daily use RAD to provide business productivity solutions. Why should a company pay $$$ for an HTML/CSS/JS editor? Why should a company buy server licenses to run IIS if everything is cloud based services? Open source alternatives are out there and are proving with numerous open source applications that many business needs can be met through customization versus new app construction. The message is don’t follow marketing off the cliff and don’t alienate a loyal base of devs like you did the time you reset the platform in 2000. Back then there weren’t options, in 2012 there are.

  • YES YES YES

    (still have InterDev in my CD box)

Comments have been disabled for this content.