3 Reasons To Use Tables instead of ASP.NET MVC WebGrids

With the absence of WebGrids in ASP.NET Core, developers are looking for alternatives. Today, we'll cover 3 reasons why we could use tables instead of WebGrids.

For the majority of my projects, I constantly use the ASP.NET MVC WebGrid. I also wrote a series of posts on how to maximize your WebGrids (WebGrid Series, Ultimate WebGrid Cookbook).

But we're in a different world now, aren't we?

There's a new version of ASP.NET called Core (version 1.1 at the moment) and for those who want to transition their old projects over to ASP.NET Core, you may be wondering what happened to the WebGrid.

Heck, I was wondering where it went.

I'm in the process of converting a project of mine over to ASP.NET MVC Core. I use WebGrids all over the place for tabular data (NOT layout!), but I couldn't find WebGrid.

I found out it's missing from Core.

OMG! What am I to do? This is HORRIBLE!

Calm down.

Even though it's missing from Core, to be honest, would this be a bad thing?

Today, I discuss three reasons why tables may make a comeback (and I talk myself off the ledge).

1. WebGrid is not flexible enough

Now, while I've always loved how the WebGrid works, I experienced some warts with the code. I mentioned these warts in a post called Creating a Responsive WebGrid in ASP.NET MVC.

It seems the WebGrid isn't granular enough.

In an HTML5 world, I can't add a simple "data-" attribute to something. It has to be a class. End of story. I can't add custom attributes to a table row (TR) or table data (TD).

When you also have hard-coded HTML in the library, I tend to raise an eyebrow suggesting something isn't right.

2. No WebGrid library is available for ASP.NET Core

I've got a gut feeling that the majority of developers out there are already working through this. They are moving forward without a WebGrid.

I've looked around for ASP.NET Core WebGrids and the closest thing I found was NonFactors's WebGrid which is open-source and pretty solid.

But do we really need a WebGrid when we can just use the ol' table tags and then sprinkle some JavaScript (and Bootstrap for alternating rows) on top to make it pretty.

3. It's becoming a JavaScript world

With everything moving towards JavaScript lately, the WebGrid always addressed 80-90% of what you needed...a table with formatted data columns. That was your 80-90%. After that, it was mostly how do you want your data to interact with the user. It was icing on the cake.

Looking back over the WebGrid series, a large number of features are JavaScript-based (i.e. inline-editing with SignalR, Filtering). All I was doing was sending formatted columns that would render a table on the client-side. Once that was done, I needed JavaScript to finish the feature.

If you look at a majority of grids, they are all JavaScript-based.

Fortunately, with Angular, Ember, Meteor, Aurelia, and every other JavaScript framework under the sun, they come with data-binding right out of the box making it one of the must-have features of a JavaScript framework.

Conclusion

In this post, I explain why it may be better to move back to tables instead of looking for a WebGrid replacement library to "rule them all." Are the old table tags "new" again?

Give me your thoughts on this. I've been going back and forth on whether to write a more modular WebGrid for Core or to just start using tables and sprinkling JavaScript on top of it.

Post your thoughts below as to whether we need WebGrids or not.