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