4 ms·

Because developers & designers prefer to have control over their HTML, and HTML really isn't that hard. Any attempt to create a true multi-purpose UI builder f

by richev 9y ago

Because developers & designers prefer to have control over their HTML, and HTML really isn't that hard. Any attempt to create a true multi-purpose UI builder for web applications has resulted in something more complex and hard to use than the problem it was trying to solve. Case study: Rewind 10-15 years and Microsoft's ASP.NET WebForms was popular (subjective use of "popular", I know), and was designed to give pretty much what you are asking for. It really did work and was great in many ways. However, it achieved this was at the cost of a _lot_ of proprietary complexity (search for "ViewState" or "ASP.NET page lifecycle"), which over time became burdensome. Then AJAX came along, and WebForms was updated to achieve this but with even more complexity (search "ASP.NET leaky abstraction"). I was using ASP.NET WebForms extensively around this time and we found ourselves increasingly "fighting" the framework, trying to bend it to suit our specific requirements (which weren't all that radical). Also, our design team started delivering their work in the form of HTML and CSS, which was a nightmare to integrated with WebForms as it dictates the exact HTML that is used at the UI control level. Then we moved over to an MVC framework, and were enlightened...

davidjnelson 9y ago
Right, I used webforms back in 2002-2005 as well. Not the best experience. I am talking about modern single page applications that leverage xmlhttprequest and common frameworks such as react and angular.
- cm2187 9y ago
  Removing the viewstate and using more ajax are merely a modernisation of webforms. Fundamentally you are calling for what webforms was actually doing, ie generating a UI, binding it to a database and dealing with the boiler plate code in between. The problem with these all-in frameworks is that they are very good at giving you a fully functional and OK looking app in a few clicks. But from there they work against you. You don't want to expose everything in the database to the user, or you want to include some custom validation logic, or you are dealing with some data that is partially normalised, or you are mixing SQL and noSQL data, etc. And then you are fighting the framework to hack something together that the designers didn't intend. And after a few years you realise it is less work to do it yourself with a bunch of helper methods.

by richev 9y ago

davidjnelson 9y ago

Right, I used webforms back in 2002-2005 as well. Not the best experience. I am talking about modern single page applications that leverage xmlhttprequest and common frameworks such as react and angular.

cm2187 9y ago
Removing the viewstate and using more ajax are merely a modernisation of webforms. Fundamentally you are calling for what webforms was actually doing, ie generating a UI, binding it to a database and dealing with the boiler plate code in between. The problem with these all-in frameworks is that they are very good at giving you a fully functional and OK looking app in a few clicks. But from there they work against you. You don't want to expose everything in the database to the user, or you want to include some custom validation logic, or you are dealing with some data that is partially normalised, or you are mixing SQL and noSQL data, etc. And then you are fighting the framework to hack something together that the designers didn't intend. And after a few years you realise it is less work to do it yourself with a bunch of helper methods.