- From: Bobby Mozumder <mozumder@futureclaw.com>
- Date: Mon, 30 Mar 2015 23:06:21 -0400
- To: Nathan White <nw@nwhite.net>
- Cc: Brian Kardell <bkardell@gmail.com>, WHATWG <whatwg@whatwg.org>
> On Mar 30, 2015, at 2:06 PM, Nathan White <nw@nwhite.net> wrote: > > Think about these larger level questions first. Why should MVC be a > standard and why is your version the correct one? There is no agreed upon > design pattern, yes MVC is popular but it takes many different forms. Some > people prefer MVVM, MVP, MVA, PAC, RMR or even Naked Objects. And there are > many more like event driven & pipelines. My point is MVC is far from being > an agreed upon solution, so why should we adopt your proposal? > Because the overall MVC won. This proposal optimizes what people do, not what they can do. This proposal isn’t a computer science project. > How do you handle internationalization or localization? What’s the issue there? HTML has LANG attributes for every element. The proposal already allows you to assign model values to any attribute, including LANG attributes. > Start there, there are numerous more issues. If you can, list them, preferably in the Github so I can track the issues. -bobby --- Bobby Mozumder Editor-in-Chief FutureClaw Magazine mozumder@futureclaw.com <mailto:mozumder@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> > >> I gave a solution that’s optimal in every case. >> > > You have failed to demonstrate this. Make a polyfill. > > >> >> There is no case where using Angular or Ember or React would be a better >> solution than having a native MVC framework in HTML. >> > > Statements like this only exacerbate your ignorance on the subject matter. > Do you even understand these frameworks? What makes your opinionated > version a standard and not a framework? All of the above don't claim to > solve every problem but offer a pathway for extensibility, How would we > extend your proposal for domain specific problems? > > > >> It’s easier (declarative syntax), it’s responsive (no need to download >> large Javascript frameworks), and uses less power (uses native code). >> > > Maybe for you. Your opting for configuration over convention approach. Many > developers despise this approach. Verbosity killed XML / XSLT how would > this not suffer the same fate? > > Again show how downloading large javascript frameworks are a burden. > Provide some numbers. > > > >> 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. >> > > No, they are using Javascript to solve state problems. HTTP/HTML is > inherently stateless. How do you solve for state? > > >> >> Maybe we need to define the authentication mechanism first? >> > > Do you not see the fallacy of your proposal? Things should not have feature > creep and require redefining every aspect of what exists. Break this down > into small pieces. Like others said, this is a losing battle. Focus on > templates first. That piece could have merit if properly defined and > contained. The web is based on small pieces loosely joined, your trying to > change the whole paradigm in one fail swoop. Tight coupling of many > specifications. > > >> >> 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. >> > > Your inherently encoding more information about the server, hence pushing a > larger burden and tighter coupling to the server. This is fine for > frameworks but not standards. > > >> >> 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. >> > > Again the burden is on you. Angular, Ember and React are frameworks and not > trying to become standards. Why is your proposal different, how is it not a > 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.) >> > > Your oversimplifying the problem. Show a proof of concept. Make that > polyfill. My suggestion would be to implement something like > http://todomvc.com/ so others have a place to compare to what already > exists. > > > > > - Nathan White > > > > > > > >> >> -bobby >> >> On Mar 28, 2015, at 1:19 PM, nw@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 >> mozumder@futureclaw.com >> +1-240-745-5287 >> www.futureclaw.com >> twitter.com/futureclaw <https://www.twitter.com/futureclaw> >> www.linkedin.com/in/mozumder >> >>
Received on Tuesday, 31 March 2015 03:06:54 UTC