I have no idea why people say this is a “hard problem.” You’re making this more complicated than it needs to be. Simplify the problem domain. We just need a declarative, native MVC framework in the browser.
I gave a solution that’s optimal in every case. There is no case where using Angular or Ember or React would be a better solution than having a native MVC framework in HTML. It’s easier (declarative syntax), it’s responsive (no need to download large Javascript frameworks), and uses less power (uses native code). Most of the issues around the current frameworks are due to Javascript itself and its interaction with the DOM. React’s framework has a virtual DOM implementation to help speed things and other frameworks are being rewritten to do the same. A user doesn’t have to worry about this. They’re experimenting and redesigning because they’re solving Javascript problems. So what exactly is incorrect about the proposed solution? If there are technical problems with it, do explain. Do you feel the response codes need to be defined now? We have standard response codes in HTTP, should we standardize on them here? Maybe we need to define the authentication mechanism first? Or maybe the models need more data-type options? All of these would be fleshed out as the spec is defined. And we already serve JSON API endpoints, so I don’t know why you feel this adds more work to the server? This proposal would use the same data that API servers already provide. And if you need backwards compatibility, it’s there as well. I’d like to see where this solution causes something to break. Or where Angular or Ember or React would be a better solution than this. With this proposal, you can still use Javascript for more advanced applications, you just don’t have to worry about loading in another MVC framework. So saying this is a “hard problem” just reeks of Javascript developer laziness, stuck in local-minima comfort-zone. But this comfort zone doesn’t matter to non-Javascript people. (note that i’ve written thousands of lines of Javascript, but have no desire to write more Javascript than necessary.) -bobby > On Mar 28, 2015, at 1:19 PM, n...@nwhite.net wrote: > > > Bobby, > > I think your enthusiasm to question and challenge the status quo is great. > Many individuals like you challenge the standards in this mailing list. I'm > constantly learning from the discussions that takes place from such proposals > and I value it immensely. > > However, I'm kinda pissed off on how you went about sharing your insight. > Unlike you everyone has encouraged discourse while respecting the enormous > amount of effort it took to get here. Posting a title with HTML6 is > hyperbolic and link bait at best. HTML5 is a living spec, changing the > version with no dialog from committee members is disrespectful. The trash > statistics you used to "support" your argument reeks of laziness, they waste > everyones time. Give us a case study or some large sample of data before > asserting such nonsense. > > If you really want to make this happen write a polyfill. Many proposals and > even standards are implemented as a proof of concept before ever reaching a > vendor. Your proposal can be implemented with javascript right now with not > much effort. This is the beauty of javascript and why we have so many > frameworks. No one agrees on how we solve these really hard problems. > Everyone is experimenting and testing. That's my biggest gripe about your > proposal, oversimplifying the problem domain. What you propose pushes tighter > coupling and implementation details to the servers. Your just moving the > problem not removing it. > > Your core argument for your proposal asserts JavaScript is hard and slow. Yet > at the same time you want HTML to act like such because single page apps are > fast. Do you see the fallacy in this argument? Please provide some data > especially on the slow bloated part. I often find optimizing even a few > images will yield file size savings that far exceed the payload size of an > entire sites JavaScript. Yes, JavaScript is hard but the problems associated > with web are really hard. There are so many layers and ways to solve. In my > opinion your proposal is simply not generic enough to be called a standard, > it would be classified as a framework much like the ones you attack. This is > the beauty of the standards we have, we have wiggle room to create, explore > and learn. They do not tell us how to solve the problem, I think this is what > frustrates you. > > If you want to continue this dialog please take sometime and read through how > others addressed proposals to the community. Like I said I'm not against you > sharing your view point but try and respect the process. This will save > everyone time. > --- Bobby Mozumder Editor-in-Chief FutureClaw Magazine mozum...@futureclaw.com <mailto:mozum...@futureclaw.com> +1-240-745-5287 www.futureclaw.com <http://www.futureclaw.com/> twitter.com/futureclaw <https://www.twitter.com/futureclaw> www.linkedin.com/in/mozumder <http://www.linkedin.com/in/mozumder>
