On 4/1/2015 9:59 PM, Bobby Mozumder wrote:
On Mar 31, 2015, at 12:43 PM, Joshua Cranmer <pidgeo...@verizon.net> wrote:

On 3/30/2015 10:02 PM, Bobby Mozumder wrote:
One thing I’m interested in is to see more technical discussions  > around this 
idea.  Like, very specific issues that show a design or
concept flaw.  It’s only been about 10 days since I proposed this and > I haven’t 
received much in that area.  (I did change one thing to > split MREF from HREF based 
on feedback about people wanting backwards > compatibility.)
Technical discussion is the last step of the process. The reason why people 
haven't provided technical feedback is because you have failed to motivate your 
I gave a limited one-page idea for now, so design faults should be obvious.
No. Simple examples don't make design faults obvious, they hide all but the most obvious design faults. My experience with designing APIs is that they can't be fully evaluated until you've tried to use them in their intended scenarios and discover the pain points.

   This will take years, but right now it’s looking like there aren’t 
fundamental problems with the proposal.  Most of the unnecessary arguments 
against it boil down to people just stuck in their comfort-zone, and those 
people aren’t the target audience for this proposal anyways.  Javascript people 
are going to be happy with their existing selection of MVC frameworks, so why 
would they want anything new like this?

The mistake Javascript developers are making is that they make the assumption 
that everybody else is a Javascript developer.

Instead, I’m mostly getting a lot of “I’m scared!” or “Everyone  > should get a 
PhD in Javascript like I did!” which obviously isn’t >
going to happen. So, if there are technical faults with the proposal > here, 
definitely list them.  (or preferably in the Github, where I > can keep track of 
issues directly)
Attacking your detractors with ad hominems is a great way to get yourself 
ignored. People aren't saying those things--they're questioning the utility of 
your proposal in the first place. You take it for granted that HTML needs a 
complex, SQL-based MVC framework. You take it for granted that JS is the devil 
and should be avoided. You appear to take it for granted that using JS 
frameworks is a problem that needs to be solved. These views are not commonly 
held on this mailing list, and you're completely ignoring the feedback which 
is, in effect, questioning these assumptions.
Not ad hominem.  I’ve literally had developers tell me everyone should learn 
Javascript.  Example: https://twitter.com/yoavweiss/status/582490158496419840

You said, and I left your original quote, "wveryone should get a PhD in Javascript" whereas your detractor said "[everyone] should all learn JS." There is a big difference between the two statements, and belittling that difference makes you seem petty.

That's obviously a horrible idea.  Why would anyone encourage millions of other 
people to do more work?   Everyone’s time is limited.  Why should a 
fashion-blogger spend time to learn JS to get a responsive high-speed site?  
They have other things to worry about, like next season’s collections.

The best experience should be on by default, and you need a built-in MVC 
framework in HTML for that to happen.

Years ago, when I first learned HTML in a class, one of the assignments had us make a table of links. I decided to make the links all point to different sites than their text indicated--and realized that the http: link in the status bar would give the game up. After asking around, I was told how to change the status bar text using JS, and then proceeded to copy-paste-tweak that into my desired goal. At that time, I didn't know how to program, and certainly never knew JS.

I bring this example up because it shows that people who are motivated to solve a problem will take the time to figure out how to do so--even if it requires technologies they never learned.
You’re asking people to learn Javascript, an MVC framework, and its associated 
templating system, to fix a basic user experience problem with the web.

I was talking with a Tumblr power user a couple of days ago about this and she 
confirmed that all Tumblr kids pretty much know the basics of HTML, somewhat 
fewer people know CSS, and nobody knows Javascript.  Tumblr maintains about 200 
million sites.

Pay attention to your quote. They know "the basics" of HTML, not they know "most" of HTML nor they know "the complex bits" of HTML. The central fallacy of your argument is that you're arguing that translating a complex design pattern from JS to HTML will automatically make people learn it, and your own quote disproves that fallacy.

This points to an obvious meta-design flaw: you're constructing a proposal based on intermediate programming principles (MVC and database query), motivating it based on perceived utility (not usability) to non-programmers, and finally resisting any attempts to discuss its applicability to complex websites.
Given all that, what’s your proposal to put forth an app-like high-speed 
responsive web experience without using Javascript?  Because any plan that 
includes “Need to know Javascript” will fail.

What's stopping people from providing templates where the user doesn't have to add any additional JS? Also, why should HTML optimize for hand-coding websites, when that's clearly the minority of websites (at least when weighted by traffic)?

Beware of bugs in the above code; I have only proved it correct, not tried it. 
-- Donald E. Knuth

Reply via email to