Re: [whatwg] HTML6 proposal for single-page apps without Javascript

Bobby,

The burden of proof is on you. This is how argumentation and debate works.
Many rebuttals have been made that you simply ignore or fail to address.
You continue to make conflated statements that only distort the
conversation more. Like I said before, I'm not opposed to you sharing an
opinion but it should not belittle other voices.


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.
>

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?

How do you handle internationalization or localization?

Start there, there are numerous more issues.



> 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 Monday, 30 March 2015 18:06:42 UTC