Re: [whatwg] HTML6 proposal for single-page apps without Javascript
On 02.04.15 22:05, Bobby Mozumder wrote: On Apr 2, 2015, at 12:11 PM, Martin Janecke whatwg@prlbr.com wrote: On 02.04.15 04:59, Bobby Mozumder wrote: I understood that the motivation for your proposal is a shorter loading time for content on webpages. Your proposal might be one way to achieve this, but to me it's not obvious that we *need* a built-in MVC framework in HTML to make content load quicker, or that it is the best way to do it. Your proposal is a pretty huge, much encompassing thing for a very particular problem. I’m open to other solutions, and looked at several other proposed solutions as previously mentioned. For my solution I gave: 1. Allows high-speed dynamically loaded webpages via JSON APIs. Makes the web as fast as native apps. 2. Doesn’t require initial loading of an external Javascript framework (or multiple frameworks) 3. HTML only - broadening usability. Doesn’t require the web developer to code in Javascript. 4. Allows advanced Javascript developers to tinker with model data directly via its own model-access API if needed 5. Stateful model object. Browsers can manage this model data if needed. (save it for offline use, etc..) I get that my proposal is a huge change, but I don’t see any other path to hitting these goals other than putting in MVC in HTML. You have any other ideas or other frameworks? I pointed at HTTP/2 in the discussion on the w3.org public html mailing list. It speeds things up without putting an MVC in HTML. I think it works for more use cases. It works on a very different layer (which implies that it can be combined with further mechanisms of course, including your proposal). Are you going to create a working demonstration/polyfill for your proposal, so that people can try it, as has been suggested? I would recommend Angular with some of its directives as probably the closest polyfill to this in terms of the view layer. That's not what I meant. I meant: Are you or is somebody else going to provide a (JavaScript) script that interprets the markup from your proposal and makes it work without being natively build into browsers yet? Such a polyfill may be build using Angular of course. You know what would be better than a polyfill? If the browser vendors tackled the issue directly. I disagree. I'm convinced that it's better to identify and solve as many of the concept's problems as possible before it is natively implemented in browsers. Why are you dismissive of a polyfill? I don't know how likely your proposal is to make it into HTML at the end, but whatever the chances are, they appear to be higher with a polyfill than without one as a considerable portion of the people who commented on your proposal asked for one and explained why they consider it necessary. If your proposal get's included in HTML, the polyfill would allow people to already use your concept and enjoy most of its benefits during a transitional period when there are still many old browsers around who don't support the native implementation. If your proposal didn't become part of HTML, the script would enable everybody who likes your approach to use it anyway, with all the benefits except for point 2 in your list above. Making the polyfill wouldn't be in vain in any case. The only disadvantage I see in developing the polyfill is that it costs its developers time and energy. But it saves multiple browsers' developers' time and energy, so I don't consider this argument to be highly relevant. Happy Easter Martin
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
On Apr 3, 2015, at 8:13 PM, Christopher Rolfe
christopher.rolfe...@gmail.com wrote:
Looking through the examples on github I find myself quickly confused even
looking at the basic examples. We seem to be declaring models in the head
and then using them throughout the body in a complex manner.
I agree that my example was too complex. I simplified the example rewrote
much of the documentation. Please check the Github if it’s any clearer. Do
let me know if it isn’t. I definitely want it to be understandable.
Another issue to consider is this. The idea that MVC suits everyone has
already been brought up, but what of this, the idea that someone tries to
do something that you haven't considered?
Like what? Javascript would still be available.
You haven't really mentioned much about how Javascript fits into this new
system, this proposal isn't going to be the end of JavaScript. You've said
that callbacks will be accessible for certain actions but it still seems a
little raw.
For example, is it possible to update values within a model from
JavaScript, you've said you'll expand on that section later.
Yes. This documentation will take time, perhaps a good year before testing can
even begin. I'm still at the early concept stages.
Another potential consideration is SEO. How is the url affected when you
click a link, you give an example of when an mref link is clicked more data
is pulled in, how is the url affected? Would you use something like the
HTML push state to change the url when mref links are clicked? Is there a
way to define this etc.
Yes the HREF gets pushed onto the URL with pushState. In the A, there would
be both an MREF and an HREF. The MREF for the model data, and the HREF for the
URL pushState, and for sharing, etc..
My last point I guess echoes what a few people have already said. What's
the point of this, who is this targeted at and why.
Is the average Joe really going to take their time to learn a complex form
of XML/HTML if they aren't going to learn JavaScript. I think not.
Again, the point is to increase HTML's interaction responsiveness without going
into Javascript.
I think people are familiar with the idea of using Templates. If you look at
Tumblr’s basic users, they already use templates, and their templates look like
this:
title{Title}/title
Compare it to this proposal, which would be:
title model=‘title’/title
So, they’re not that far off. Every CMS I’ve seen has some kind of template
language, so the concept of templates should already be familiar to web
developers. In fact I believe more people would know templating than they know
Javascript.
Also, these other template syntax isn’t valid HTML, while this would be.
As I said I build websites myself and the majority that I build are not
Single Page Applications, I'd wonder how many out there are and really do
we need to change HTML to suit what I suspect would be a minority of sites.
Good luck and I hope you can understand the concerns I've raised.
Yep. Again, if there are any usability concerns, let me know. I’m trying to
avoid bad design like:
script type=“application/javascript”
When it should have been:
script type=“javascript”
Or just:
script
That sort of thing. Some languages, like Python, were designed with usability
testing, and any improvement in HTML should be done with that in mind.
-bobby
---
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
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
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
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
Polyfills aren’t going to cover all possible scenarios, either, since they’re going to be limited by test coverage. Some messages ago you suggested that Angular would serve as a proof of concept for your proposal I'm sure you didn't mean to replicate Angular.js with HTML. No polyfills will actually cover all use cases, but it's also true that you are not required to build something usable here and now. You just need something working so that authors and possible collaborators can follow your proposal. I'd suggest you a simple script with modern DOM methods that can be run, say, on Safari/Chrome/Opera latest versions (no need for legacy support), just for Web designers who wish to test how it works. It's easy - an XHR to simulate native call, a server-side script for the API and a bit of DOM traversing for content substitution. Just in order to let people know that your proposal is not a bunch of words. 2015-04-03 6:04 GMT+02:00 Bobby Mozumder mozum...@futureclaw.com: On Apr 2, 2015, at 1:16 PM, Brian Kardell bkard...@gmail.com wrote: Many of simple cases that I see that you could potentially do with your approach as described, at least my understanding of what I've seen so far, can in fact be done today with several frameworks declaratively.. There is competition in the space of how to express it and that is fundamentally no different than if we discussed it on a mailing list, there would be different ideas. The difference is that one involves speculation, no testing and is useless to people in the meantime (and the meantime means years) - very frequently only at the end of that do you find out that 'whoops, that isn't actually what developers need for 70% of real cases' and that scenario is a fundamental loss at almost every level. The issue is that that those simple cases are, in fact, not the norm, you exceed them very quickly and the question immediately becomes 'then what?’. You adapt and change things as needed. But for now you work with the information you have. Again, I’m not trying to create a large comp-sci project with all sorts of theoretical options. I just see a basic user experience problem and figuring out a solution designed to fix that. I hope you agree that there is full-page reload is a problem with the web? If you agree that it’s a problem then we can fix it. Ideally the solution would work with all parameters I previously mentioned (JSON API interfacing, no loading additional JS files, high-school kids can understand it, etc..) Other solutions don’t meet these parameters. Angular/React/etc. requires loading in an extra Javascript file, as well as JS programming, which is why they’re not widely adopted except for JS developers. XSLT doesn’t have a statefully persistent model object operates around weird XML. MDV also needs JS and the models seem tied too close to the DOM, and so on.. The fact that so many people are trying to solve this problem isn’t a good thing. It means there’s a problem with HTML itself that needs to be addressed. HTML really needs to just go ahead and fix it. There's a lot of competition and collaboration figuring out how you create a well reasoned system that allows users the proper balances of power and simplicity and ability to adapt. To answer the same sorts of questions that they answer every day, your solution will involve JavaScript too - as well as SQL and some server-side specifications which will require their own languages and probably frameworks. Those are optional features. The basic proposal offers dynamic pages without Javascript, using pure HTML. I'm honestly not trying to dissuade you here or perpetuate an argument, I'm just saying that your insistence on drawing this line to say 'it's so simple' is, surely you can appreciate, a 'big' statement and it doesn't seem unreasonable for people to ask you to actually show them. Believe it or not, participants in standards bodies have limits to the amount of time and monetary investment they can make into something and there's a lot to do. Getting something started often requires first-movers to show something, even browser makers usually don't just throw an idea out there, they work out a proof of concept with the proposal and show people what they are talking about. It's not unreasonable to think that people ask you to do a little more leg-work before they commit to ...well... even reading more if you see what I mean... we've all got limited time. Right now I’m trying to figure out advanced scenarios or use models where this proposal would be a bad idea. You have any ideas on that? Polyfills aren’t going to cover all possible scenarios, either, since they’re going to be limited by test coverage. -bobby --- 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/
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
I gave a limited one-page idea for now, so design faults should be obvious. This will take years, but right now it’s looking like there aren’t fundamental problems with the proposal. There are fundamental problems with your proposal, namely: 1) it relies on some undefined magic 2) it changes HTML to something entirely different. 3) you assume that those not willing to learn Javascript will somehow know how to use the features you propose without learning. How? 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. And fashion designer will be able to use it without learning? Also it is not clear, how are you going to separate M from V from C if it is all HTML. You’ll find that the kind of proposal I’m putting out there is the only viable solution. Your proposal is just a bit of magical thinking, not any solution. I am not sure what problem are you trying to solve. Is that ‘allow non-technical people to build web-sites’? Then you are solving it at the wrong level. Best regards, Rimantas
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
Hi Bobby - I’m going to keep my response brief as I don’t want to get sucked into this one too deep: all Tumblr kids pretty much know the basics of HTML What you’ve proposed is not simple HTML, they won’t learn it. Javascript people are going to be happy with their existing selection of MVC frameworks, so why would they want anything new like this? Most of the JS devs I work with would love a new framework which works differently to the existing range of frameworks because everyone’s got their own idea of the best approach. The beauty of the world today is that none of these are so deeply embedded that you’re stuck with them. This will take years, but right now it’s looking like there aren’t fundamental problems with the proposal My fundamental problem with this proposal is that it doesn’t blend well with the HTML we have - this group puts a lot of effort into backward compatibility because the web needs it. If you really think this structure is what devs want then write a polyfill script that any noob can copy paste (e.g. script src=“www.//futurcrlaw.com/mvc-pollyfil.js”/script) to add all these features to any browser currently in the wild. Then work hard to persuade the Tumblr kids” to care about things like performance teach them all to use MVC using your polyfill. If you really think it needs to be implemented in the browser write a browser plugin which makes it more efficient, then you’ve got some kind of case for this being a useful feature. Even if everyone loved it this feature could not go into HTML spec and be adopted by developers without a polyfill. If you really think that all browser vendors represented in this group are wrong then the answer’s simple - write your own browser which contains this feature and repeat the browser wars “hey, use my browser because it supports this feature no other browsers want”. All the best. Mat Carey P.S. While you’re at it could you add a feature so I can forget any CSS I’ve ever known … something like font color=“red” size=“3” would be really simple for the Tumblr kids to learn. :) On 2 Apr 2015, at 03:59, Bobby Mozumder mozum...@futureclaw.com 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. 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 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. We need to be
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
On Apr 2, 2015, at 12:11 PM, Martin Janecke whatwg@prlbr.com wrote: On 02.04.15 04:59, Bobby Mozumder wrote: The best experience should be on by default, and you need a built-in MVC framework in HTML for that to happen. That's something you take for granted, but other people don't. Apparently, people want to see the claim substantiated. I understood that the motivation for your proposal is a shorter loading time for content on webpages. Your proposal might be one way to achieve this, but to me it's not obvious that we *need* a built-in MVC framework in HTML to make content load quicker, or that it is the best way to do it. Your proposal is a pretty huge, much encompassing thing for a very particular problem. I’m open to other solutions, and looked at several other proposed solutions as previously mentioned. For my solution I gave: 1. Allows high-speed dynamically loaded webpages via JSON APIs. Makes the web as fast as native apps. 2. Doesn’t require initial loading of an external Javascript framework (or multiple frameworks) 3. HTML only - broadening usability. Doesn’t require the web developer to code in Javascript. 4. Allows advanced Javascript developers to tinker with model data directly via its own model-access API if needed 5. Stateful model object. Browsers can manage this model data if needed. (save it for offline use, etc..) I get that my proposal is a huge change, but I don’t see any other path to hitting these goals other than putting in MVC in HTML. You have any other ideas or other frameworks? Are you going to create a working demonstration/polyfill for your proposal, so that people can try it, as has been suggested? I would recommend Angular with some of its directives as probably the closest polyfill to this in terms of the view layer. On Mar 31, 2015, at 12:43 PM, Joshua Cranmer pidgeo...@verizon.net wrote: […] Serious question: why? What benefit does it bring? That JS is bad is not a self-evident proposition. 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. Bobby, you are the one who suggests that people should learn an MVC framework, aren't you? Also, I think we have to remind ourselves that when you say a basic user experience problem with the web you mean long loading time. I think naming the problem you're trying to solve is important so that people can help solving it. Or else we're just talking about a concept of yours and nobody really knows why anymore. Yes indeed. This solution is specifically targeted towards that problem. This interaction lag is something noticeable when you deal with native apps vs. the web. When using a regular web page, people know you’re dealing with a web page, instead of something native. Another undesirable characteristic of the web compared to native apps is layout reflows, but this can be addressed separately. 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. Imagine you or someone else indeed made that polyfill some people asked you to provide. Tumblr could easily include that script on every Tumblr blog or make this a one-click option for authors, right? So with that polyfill all authors of the 200 million Tumblr sites could make use of your idea without knowing any JavaScript and before your proposal has made it into HTML. Sounds like making that polyfill would be a good idea, doesn't it? And if it proofs useful indeed and more popular than alternatives, it could be included in the HTML standard. You know what would be better than a polyfill? If the browser vendors tackled the issue directly. But I suspect that when all is said and done, they’ll eventually converge on this solution anyways, where they implement an MVC framework in the browser based on declarative HTML model definitions. -bobby --- 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
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
There are fundamental problems with your proposal, namely: 1) it relies on some undefined magic I believe that’s called “programming”. So that poor fashion designer will have to learn to program after all… 2) it changes HTML to something entirely different. To what? HTML already has things like SCRIPT and other features not related to hypertext markup. I don’t know to what, I never saw any examples how your MVC would look like. Would you care to show how something like http://backbonejs.org/docs/todos.html would look if done your way? 3) you assume that those not willing to learn Javascript will somehow know how to use the features you propose without learning. How? They use HTML, which is far more widespread than Javascript. But they don’t do MVC with pure HTML. There’s a reason this proposal has gone viral outside of this list. Good luck. Best regards, Rimantas
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
On Apr 2, 2015, at 3:22 PM, Rimantas Liubertas riman...@gmail.com wrote: There are fundamental problems with your proposal, namely: 1) it relies on some undefined magic I believe that’s called “programming”. So that poor fashion designer will have to learn to program after all… The browser vendors are the ones doing the programming. They’ll ultimately decide if they want to implement this or not. 2) it changes HTML to something entirely different. To what? HTML already has things like SCRIPT and other features not related to hypertext markup. I don’t know to what, I never saw any examples how your MVC would look like. Would you care to show how something like http://backbonejs.org/docs/todos.html would look if done your way? I have examples in the original message, as well as in: http:///www.github.com/mozumder/HTML6 -bobby --- 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
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
Some years ago there were also Internet Explorer 6, proprietary tags,
frameset web pages and the project for DHTML. There also was the idea of
simple JS expressions to be evaluated in CSS. Why does anybody not propose
to restore {expression()}?
Never been a fan of the new is good motto, but saying that things were
better in the past just because they were that way seems odd.
Delfin, you also cite the times (2002) when CSS could be effectively
disabled. Can you imagine a Web without CSS nowadays?
I don't think that Bobby's proposal focuses on ease of use. His model, as
it it planned now, seems quite complicated now. It is a different kind of
difficulty, but still difficult.
And planning to give the coding power to the people by means of
inventing easier things is wrong in its very merit. Javascript itself is
not a difficult programming language. In fact, Mr Mozumder's proposal seems
to lack uniformity because it does not make clear whether the author wants
to oppose the JS concept or the multiplication of frameworks.
Let's put it in 2 separate points:
1. fighting against frameworks is contrary to the very same logic you are
citing as support for Web as it was. It is true that different frameworks
solve the same problem in different ways. Thus authors can choose the tools
which best fit to the project - or no tools at all, but this is the second
point. Yes, there could be a sort of native framework and it will have
its strong points as well as its liabilities, and if it doesn't cover a
specific document structure it must be switched in favor of another. I take
it for granted that Bobby has no ambition to write the ultimate framework,
and I'm also sure that he couldn't do it by himself, were he going to.
But it is also true that frameworks add weight to the page. A weight which
is only partially reduced by e.g. using Google CMS to serve frameworks like
jQuery, considering that if several websites use the same files, then once
a user visits one, the script files are cached. I think that the only, REAL
good point in Bobby's project is this: reducing weight, and thus reducing
loading lag (reduced to 0 when you have nothing to download); and reducing
execution time, as some frameworks have a long time being executed (but
then Mr Mozumder has to prove that UA native implementation will be faster
- it's a joke, of course. Mr Mozumder cannot prove anything about that)
2. fighting against JS itself is a completely different case. I have
discussed it in depth above and I guess nobody likes to re-read things.
JS has been part of making web pages for a long time now. It is the
necessary integration to HTML and CSS because neither HTML nor CSS are
meant for content manipulation. HTML exposes an API, the DOM, and that API
can be used for a lot of things. This is the good point of JS. It allows
authors to work on elements and attributes, as well as interface
attributes, methods and properties using a much more fine-grained structure
than simple HTML. To make an example, when loading an external content you
can access different properties allowing you to easily find out origin,
HTTP call response code, loading status and so on. You have nothing to test
it in native HTML, unless you say that calling, e.g.,
model.data.status property or model.data.parse() method is HTML. It
isn't, it's JS.
The majority of frameworks were born to provide a solution for a different
problem: object standardisation across platforms. Think about AJAX
standardisation made by jQuery and other frameworks: it was necessary when
there were at least 3 different ways to do a simple XmlHttpRequest.
It's simple as that. If there were a deep wish to find a common platform
for features implementation (this wish is increasing, though), you wouldn't
even need frameworks. You'd still need JS, though, in order to execute XHR,
in a standard, 360°-wide scenario. That standardisation is still unachieved
for JS. So does anybody want to say that JS is not Web for this? Fine, then
get rid of CSS too, as its implementation is far from being uniform.
If you want to lower the barrier to entry in Web design, the right solution
is not to remove complex things. Do you lower grammar standards because it
is too difficult to speak correctly? Do you lower any of your expectations
towards any aspect of life when that aspect becomes too tough? I respect
anybody's effort to make web pages, and I myself am quite new to this. But
each one must do what s/he can do, or learn more things. What is needed for
a better Web is standard. It is a ruleset that can be studied and applied
without thinking Is this solution compatible with that specific version of
that specific browser?.
A final consideration: as JS is a scripting language, it has to be parsed
and compiled. If it presents errors, it cannot be executed and it stops.
With HTML6 you are going to deliver a powerful tool to, say, fashion
bloggers and Tumblr users. Is it meant to have an error handling as HTML
has to do
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
Hi all: I see some interesting things and a correc t approach of the MVC model -- speaking in terms of theory -- in the original proposal of Bobby. Let me tell you something funny: * I do not see any unconvenient working with tags, as bones, because for, as far as I remember, my firsts experiences in the web were using tag , a programming language named _Coldfusion_. 1995. Anyone've heard of it? * To me , the proposal of Bobby for the HMTL6 spec reminds me subtly that way of work, perfectly defined then and now as MVC. No kidding. * Later, years later it came ECMAScript, I guess. For this the success of ActionSCript/flash, ECMaScript based in C and Perl, with a clear advantage over the Java plugins and the non-permitted Javascript ( in the banking sphere, for example ) * We might have in mind that The websites , since few years ago, were no made by developers, just few developers/programmers. It was the need of communication and self-publishing what spread the web. Developers were not then neither in its inception. Have a look at the forums and silos from 1006 till 2004 and you will agree with me. A professional coder is a professional coder.As far as I remember, developers were focused on something that in our days days is not really well paid, if it still exist, and if it is even get paid (joke). That was Middelware. Now the money is in the web. Making grammar for the web to produce hipertext. A simple TCP/Ip protocol. * But HTML goes far from this, as we old cows knew. HTML is useful in the MAIL/SMTP protocol, in the GOPHER protocol as well as in a lot of scenarios aside from the HTTP/S/S2 we visit everyday. * With all those protocols in mind, back then, designers ( like the future ones Bobby is referring to ) , without being trained developers, and coming from a background in the use of Hypercard and Graphical computers start to learn to code for the web. The Mosaic (Netscape) now dissapeared. After this, it came the need of standards and the oblivion of VBScript, JScript, and Tables. As far as I remember, you might buy a PowerPC station and you still were recommended to disable the CSS for ( a lovely declarative-imperative language, that inherits directly from C, considered by then an afficionado and non-coder language ) for a better navigation. That was in 2002, I guess. * When I see people coding in a Terminal , I have a flashback as if I were at secondary school. Of course there is the need to know to code, as there is a need to know grammar. The need for this is simple: To use properly a language. In our case, the language of the web. Etcetera. Sorry for the verbose. I see all arguments right , and I perceive both side of the positions explained in this mailing list. But I do consider realy interesting the approach Bobby has made. Far more interesting ( appreciating the good use of JSON he explains ) that keeping alive a lovely language that some of us we have been using for more than 15 years. I look and wait after the ECMAScript6 proposal, but I still have in mind there was a web, once where no javascruipt was needed. And it worked pretty well. My apologies for the verbose. Have all a good day. Regards --- Delfi Ramirez My digital signature [1] +34 633 589231 del...@segonquart.net [2] twitter: delfinramirez IRC: segonquart Skype: segonquart [3] http://segonquart.net [4] http://delfiramirez.info [5] On 2015-04-02 21:22, Rimantas Liubertas wrote: There are fundamental problems with your proposal, namely: 1) it relies on some undefined magic I believe that's called programming. So that poor fashion designer will have to learn to program after all... 2) it changes HTML to something entirely different. To what? HTML already has things like SCRIPT and other features not related to hypertext markup. I don't know to what, I never saw any examples how your MVC would look like. Would you care to show how something like http://backbonejs.org/docs/todos.html [6] would look if done your way? 3) you assume that those not willing to learn Javascript will somehow know how to use the features you propose without learning. How? They use HTML, which is far more widespread than Javascript. But they don't do MVC with pure HTML. There's a reason this proposal has gone viral outside of this list. Good luck. Best regards, Rimantas Links: -- [1] http://delfiramirez.info/public/dr_public_key.asc [2] mail:%20del...@segonquart.net [3] skype:segonquart [4] http://segonquart.net [5] http://delfiramirez.info [6] http://backbonejs.org/docs/todos.html
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
Bobby, stop talking about comfort zone and scared programmers and start acting like a person who considers anybody else worth discussing with, instead of a bunch of stupid people acting for their own interest. What you propose is as complex and impractical as a JS framework is. Moreover, an author should either learn very well SQL or learn your variant of the language which is translated into SQL statements, something you seem not to consider. Not ad hominem. I’ve literally had developers tell me everyone should learn Javascript. Example: https://twitter.com/yoavweiss/status/582490158496419840 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. I strongly hope you are joking. If the fashion blogger does not know how to work with JS, s/he will either stick with ready-made sites or blogs, or ask to someone capable to build the site for him/her. It's not just because anyone can be a fashion blogger, that anyone can build a website too. The former activity needs no skills (apart from some taste, while the definition of taste is quite non-uniform), while the latter needs technical skills, And your proposal will need technical skills as well - not on the JS side, but in HTML. 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. sarcasmWell, this means that we must also simplify CSS, don't you think so? all that stuff about media queries, about animation and transitions, pseudo-elements, pseudo-classes, how can poor Tumblr users learn that?/sarcasm sarcasm type=hardIt's a real luck that Tumblr kids, who obviously constitute the bulk of modern authorship, know HTML well enough to also learn your complex two-way control/view model (I still find it complex somehow, I'm not as smart as they are of course. Evidence: I'm stuck in my JS comfort zone)./sarcasm I repeat the assumption I did in my private message, that you haven't probably had the time to read. You seem to swing freely between saying no to JS frameworks and saying no to JS as a whole. When and why you did elaborate the idea that JS is not part of Website building? When did you decide that web pages have to be HTML and CSS and SQL, while half the HTML we have now is also defined in terms of objects with properties and methods? Want to say no to frameworks? Stick to basic properties for objects. Keep on fighting against JS, and you will look like someone who is trying to abandon CSS in favor of font tags and @width/@height attributes because they're simpler. 2015-04-02 10:23 GMT+02:00 Rimantas Liubertas riman...@gmail.com: I gave a limited one-page idea for now, so design faults should be obvious. This will take years, but right now it’s looking like there aren’t fundamental problems with the proposal. There are fundamental problems with your proposal, namely: 1) it relies on some undefined magic 2) it changes HTML to something entirely different. 3) you assume that those not willing to learn Javascript will somehow know how to use the features you propose without learning. How? 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. And fashion designer will be able to use it without learning? Also it is not clear, how are you going to separate M from V from C if it is all HTML. You’ll find that the kind of proposal I’m putting out there is the only viable solution. Your proposal is just a bit of magical thinking, not any solution. I am not sure what problem are you trying to solve. Is that ‘allow non-technical people to build web-sites’? Then you are solving it at the wrong level. Best regards, Rimantas
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
On Apr 2, 2015, at 1:16 PM, Brian Kardell bkard...@gmail.com wrote: Many of simple cases that I see that you could potentially do with your approach as described, at least my understanding of what I've seen so far, can in fact be done today with several frameworks declaratively.. There is competition in the space of how to express it and that is fundamentally no different than if we discussed it on a mailing list, there would be different ideas. The difference is that one involves speculation, no testing and is useless to people in the meantime (and the meantime means years) - very frequently only at the end of that do you find out that 'whoops, that isn't actually what developers need for 70% of real cases' and that scenario is a fundamental loss at almost every level. The issue is that that those simple cases are, in fact, not the norm, you exceed them very quickly and the question immediately becomes 'then what?’. You adapt and change things as needed. But for now you work with the information you have. Again, I’m not trying to create a large comp-sci project with all sorts of theoretical options. I just see a basic user experience problem and figuring out a solution designed to fix that. I hope you agree that there is full-page reload is a problem with the web? If you agree that it’s a problem then we can fix it. Ideally the solution would work with all parameters I previously mentioned (JSON API interfacing, no loading additional JS files, high-school kids can understand it, etc..) Other solutions don’t meet these parameters. Angular/React/etc. requires loading in an extra Javascript file, as well as JS programming, which is why they’re not widely adopted except for JS developers. XSLT doesn’t have a statefully persistent model object operates around weird XML. MDV also needs JS and the models seem tied too close to the DOM, and so on.. The fact that so many people are trying to solve this problem isn’t a good thing. It means there’s a problem with HTML itself that needs to be addressed. HTML really needs to just go ahead and fix it. There's a lot of competition and collaboration figuring out how you create a well reasoned system that allows users the proper balances of power and simplicity and ability to adapt. To answer the same sorts of questions that they answer every day, your solution will involve JavaScript too - as well as SQL and some server-side specifications which will require their own languages and probably frameworks. Those are optional features. The basic proposal offers dynamic pages without Javascript, using pure HTML. I'm honestly not trying to dissuade you here or perpetuate an argument, I'm just saying that your insistence on drawing this line to say 'it's so simple' is, surely you can appreciate, a 'big' statement and it doesn't seem unreasonable for people to ask you to actually show them. Believe it or not, participants in standards bodies have limits to the amount of time and monetary investment they can make into something and there's a lot to do. Getting something started often requires first-movers to show something, even browser makers usually don't just throw an idea out there, they work out a proof of concept with the proposal and show people what they are talking about. It's not unreasonable to think that people ask you to do a little more leg-work before they commit to ...well... even reading more if you see what I mean... we've all got limited time. Right now I’m trying to figure out advanced scenarios or use models where this proposal would be a bad idea. You have any ideas on that? Polyfills aren’t going to cover all possible scenarios, either, since they’re going to be limited by test coverage. -bobby --- 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
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
On Apr 2, 2015, at 4:23 AM, Rimantas Liubertas riman...@gmail.com wrote: I gave a limited one-page idea for now, so design faults should be obvious. This will take years, but right now it’s looking like there aren’t fundamental problems with the proposal. There are fundamental problems with your proposal, namely: 1) it relies on some undefined magic I believe that’s called “programming”. 2) it changes HTML to something entirely different. To what? HTML already has things like SCRIPT and other features not related to hypertext markup. Besides, where’s the rule that say “HTML needs to only be this..” ? Artificial constraints are unnecessary. 3) you assume that those not willing to learn Javascript will somehow know how to use the features you propose without learning. How? They use HTML, which is far more widespread than Javascript. There’s a reason this proposal has gone viral outside of this list. -bobby --- 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
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
On Apr 2, 2015, at 3:22 AM, Mat Carey m...@matcarey.co.uk wrote: This will take years, but right now it’s looking like there aren’t fundamental problems with the proposal My fundamental problem with this proposal is that it doesn’t blend well with the HTML we have - this group puts a lot of effort into backward compatibility because the web needs it. Explain why you feel it’s not backwards compatible. I made sure the proposal is backwards compatible with the “MREF” attributes. You could take the same page and load it into an older browser, and it would work perfectly fine. Older browsers would just ignore the MODEL elements and other attributes. Even if everyone loved it this feature could not go into HTML spec and be adopted by developers without a polyfill. Where did you get that idea? Polyfills are unnecessary to advance HTML. Browser vendors don’t need them. Where is the polyfill for CSS Exclusions, for example? -bobby --- 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
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
https://www.youtube.com/watch?v=ulNSlES1Fds On Thu, Apr 2, 2015 at 1:08 PM, Andrea Rendine master.skywalker...@gmail.com wrote: Bobby, stop talking about comfort zone and scared programmers and start acting like a person who considers anybody else worth discussing with, instead of a bunch of stupid people acting for their own interest. What you propose is as complex and impractical as a JS framework is. Moreover, an author should either learn very well SQL or learn your variant of the language which is translated into SQL statements, something you seem not to consider. Not ad hominem. I’ve literally had developers tell me everyone should learn Javascript. Example: https://twitter.com/yoavweiss/status/582490158496419840 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. I strongly hope you are joking. If the fashion blogger does not know how to work with JS, s/he will either stick with ready-made sites or blogs, or ask to someone capable to build the site for him/her. It's not just because anyone can be a fashion blogger, that anyone can build a website too. The former activity needs no skills (apart from some taste, while the definition of taste is quite non-uniform), while the latter needs technical skills, And your proposal will need technical skills as well - not on the JS side, but in HTML. 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. sarcasmWell, this means that we must also simplify CSS, don't you think so? all that stuff about media queries, about animation and transitions, pseudo-elements, pseudo-classes, how can poor Tumblr users learn that?/sarcasm sarcasm type=hardIt's a real luck that Tumblr kids, who obviously constitute the bulk of modern authorship, know HTML well enough to also learn your complex two-way control/view model (I still find it complex somehow, I'm not as smart as they are of course. Evidence: I'm stuck in my JS comfort zone)./sarcasm I repeat the assumption I did in my private message, that you haven't probably had the time to read. You seem to swing freely between saying no to JS frameworks and saying no to JS as a whole. When and why you did elaborate the idea that JS is not part of Website building? When did you decide that web pages have to be HTML and CSS and SQL, while half the HTML we have now is also defined in terms of objects with properties and methods? Want to say no to frameworks? Stick to basic properties for objects. Keep on fighting against JS, and you will look like someone who is trying to abandon CSS in favor of font tags and @width/@height attributes because they're simpler. 2015-04-02 10:23 GMT+02:00 Rimantas Liubertas riman...@gmail.com: I gave a limited one-page idea for now, so design faults should be obvious. This will take years, but right now it’s looking like there aren’t fundamental problems with the proposal. There are fundamental problems with your proposal, namely: 1) it relies on some undefined magic 2) it changes HTML to something entirely different. 3) you assume that those not willing to learn Javascript will somehow know how to use the features you propose without learning. How? 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. And fashion designer will be able to use it without learning? Also it is not clear, how are you going to separate M from V from C if it is all HTML. You’ll find that the kind of proposal I’m putting out there is the only viable solution. Your proposal is just a bit of magical thinking, not any solution. I am not sure what problem are you trying to solve. Is that ‘allow non-technical people to build web-sites’? Then you are solving it at the wrong level. Best regards, Rimantas
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
On Wed, Apr 1, 2015 at 10:59 PM, Bobby Mozumder mozum...@futureclaw.com 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. 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. That is just a fundamentally false portrayal and while I read between the lines and understand your intent, you're misunderstanding the goals and pressures of an explainable platform that gets partially figured out via experimental implementations. Literally all of the major players here are working on how to build increasingly high level abstractions and working to compete or collaborate where appropriate. Many of simple cases that I see that you could potentially do with your approach as described, at least my understanding of what I've seen so far, can in fact be done today with several frameworks declaratively.. There is competition in the space of how to express it and that is fundamentally no different than if we discussed it on a mailing list, there would be different ideas. The difference is that one involves speculation, no testing and is useless to people in the meantime (and the meantime means years) - very frequently only at the end of that do you find out that 'whoops, that isn't actually what developers need for 70% of real cases' and that scenario is a fundamental loss at almost every level. The issue is that that those simple cases are, in fact, not the norm, you exceed them very quickly and the question immediately becomes 'then what?'. There's a lot of competition and collaboration figuring out how you create a well reasoned system that allows users the proper balances of power and simplicity and ability to adapt. To answer the same sorts of questions that they answer every day, your solution will involve JavaScript too - as well as SQL and some server-side specifications which will require their own languages and probably frameworks. I'm honestly not trying to dissuade you here or perpetuate an argument, I'm just saying that your insistence on drawing this line to say 'it's so simple' is, surely you can appreciate, a 'big' statement and it doesn't seem unreasonable for people to ask you to actually show them. Believe it or not, participants in standards bodies have limits to the amount of time and monetary investment they can make into something and there's a lot to do. Getting something started often requires first-movers to show something, even browser makers usually don't just throw an idea out there, they work out a proof of concept with the proposal and show people what they are talking about. It's not unreasonable to think that people ask you to do a little more leg-work before they commit to ...well... even reading more if you see what I mean... we've all got limited time. I'm not trying to discourage you here, not at all. If you have an idea, I encourage you to try to develop it - find some people who are interested, make compromises, flesh it out and come back to the list with yourself in a better position. I mean, it's not my list, so you can do what you want - I just think that that's how you will see the best results. -- Brian Kardell :: @briankardell :: hitchjs.com
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
On 02.04.15 04:59, Bobby Mozumder wrote: The best experience should be on by default, and you need a built-in MVC framework in HTML for that to happen. That's something you take for granted, but other people don't. Apparently, people want to see the claim substantiated. I understood that the motivation for your proposal is a shorter loading time for content on webpages. Your proposal might be one way to achieve this, but to me it's not obvious that we *need* a built-in MVC framework in HTML to make content load quicker, or that it is the best way to do it. Your proposal is a pretty huge, much encompassing thing for a very particular problem. Are you going to create a working demonstration/polyfill for your proposal, so that people can try it, as has been suggested? On Mar 31, 2015, at 12:43 PM, Joshua Cranmer pidgeo...@verizon.net wrote: […] Serious question: why? What benefit does it bring? That JS is bad is not a self-evident proposition. 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. Bobby, you are the one who suggests that people should learn an MVC framework, aren't you? Also, I think we have to remind ourselves that when you say a basic user experience problem with the web you mean long loading time. I think naming the problem you're trying to solve is important so that people can help solving it. Or else we're just talking about a concept of yours and nobody really knows why anymore. 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. Imagine you or someone else indeed made that polyfill some people asked you to provide. Tumblr could easily include that script on every Tumblr blog or make this a one-click option for authors, right? So with that polyfill all authors of the 200 million Tumblr sites could make use of your idea without knowing any JavaScript and before your proposal has made it into HTML. Sounds like making that polyfill would be a good idea, doesn't it? And if it proofs useful indeed and more popular than alternatives, it could be included in the HTML standard. Martin
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
On 04/02/2015 04:08 AM, Andrea Rendine wrote: sarcasmWell, this means that we must also simplify CSS, don't you think so? all that stuff about media queries, about animation and transitions, pseudo-elements, pseudo-classes, how can poor Tumblr users learn that?/sarcasm Oh god yes, I like CSS selectors but the rest of CSS I personally have a hard time wrapping my head around - I'm guessing CSS was designed by people who have a completely different thinking style than I do. I have no problem getting LaTeX to do what I want but CSS - I have struggled with it for literally 15 years. I want to see CSS re-written from the ground up. But that's going off topic ;)
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
You don't have to show any magnificent markup example with pages of description. You have to show authors how this framework WORKS in real life. With comprehensive use cases. This is a polyfill. As you can find for any other HTML magic you see around. CSS is a different case. Without proper tools, you can only replicate your desired layout with graphical tools (and this is always done). You can't expect that UA vendors build a new product based on your words. Do you have ideas about several use cases and not just one? Build a JS surrogate (you said you know JS) mimicking what future user agents are expected to do. And test it for security and robustness and flexibility. Markup is just words. Tagged words, but simply words. Of course browser vendors will have to do a lot of programming to reproduce your ideas. But first show how your ideas work. And keep in mind that something is not simple just because it starts with and ends with , and for this reason you can call it markup or XML or SGML or HTML and say it's simple. Ok, it's you on the right side and the whole world gone wrong. I'm sure your proposal has gone viral, and the fact you have no contributors, no forks or no answers on Github (apart from Taylor Swift spam) is just red herring. But with a demo, everything will be clearer. And stop criticizing everybody else's work just because it's different from yours. Cheers. 2015-04-02 21:27 GMT+02:00 Bobby Mozumder mozum...@futureclaw.com: On Apr 2, 2015, at 3:22 PM, Rimantas Liubertas riman...@gmail.com wrote: There are fundamental problems with your proposal, namely: 1) it relies on some undefined magic I believe that’s called “programming”. So that poor fashion designer will have to learn to program after all… The browser vendors are the ones doing the programming. They’ll ultimately decide if they want to implement this or not. 2) it changes HTML to something entirely different. To what? HTML already has things like SCRIPT and other features not related to hypertext markup. I don’t know to what, I never saw any examples how your MVC would look like. Would you care to show how something like http://backbonejs.org/docs/todos.html would look if done your way? I have examples in the original message, as well as in: http:/// www.github.com/mozumder/HTML6 -bobby --- 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
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
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. 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 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. We need to be able to advance the web without going through Javascript. It’s a mistake to assume that JS is a fundamental part of the web. The web is optimized for hypertext document processing, and most people use it to read content online. This proposal fixes a remaining issue with that. Serious question: why? What benefit does it bring? That JS is bad is not a self-evident proposition. 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. 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. You’ll find that the kind of proposal I’m putting out there is the only viable solution. -bobby --- 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
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
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. 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. We need to be able to advance the web without going through Javascript. It’s a mistake to assume that JS is a fundamental part of the web. The web is optimized for hypertext document processing, and most people use it to read content online. This proposal fixes a remaining issue with that. Serious question: why? What benefit does it bring? That JS is bad is not a self-evident proposition. -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
Bobby, the major criticism you have received about your proposal is that you aren't considering at all any other party involved in this subject. Correct me if I'm wrong, you cite no user agent responsible for support, nor working groups or anything loosely resembling to that. You are providing a very useful insight on how *you* see the web. And you also provide a feedback based on the experience of high-school Tumblr girls (why should she learn how to use Angular? However, there's nothing bad if she learns something new). The fact is, your proposal cannot be labeled as HTML6 Web needs something new. And however your last messages do show that the proposal itself is not strictly related to read/write Web as you claim. In fact, the main reasons you cite behind your proposal are responsiveness and full-page reload latency. Which are real problems, for sure, but not in the sense of read/write, they're rather a matter of UX. A relative matter which does not make the Web largely unusable, and if you have doubt about it just have a look at ChromeExperiments and see what can be done with current poor methods. If what you need is localised content load, you have some features you can use as of now. For example, you can use nested browsing contexts, which also offer a layer of protection in the form of CORS restrictions, sandboxing and MIME type declaration. You want to get rid of these things? Use XHR, its support is native. As you said, you are not against JS itself, but against writing more Javascript than necessary. If you have the means, push towards a more pervasive standardisation of current JS implementation, so that there will be decreasing need for polyfills and syntax standardisers (with your proposal, there'd be a need for a polyfill as well until it doesn't become supported on new UA versions *and* new UA versions completely or substantially replace legacy versions). You still want more? Don't focus on changing a web page content. HTML is still a declarative language after all, and there's nothing bad with it. It's the purpose which originated it. Of course there's more now, but the examples of websites or web apps you cited don't generally change the content of a page, they integrate it, adding more items to the page as time passes and events happen. So, as I said some messages ago, why not focusing on template? It can add new elements to the existing document, it's HTML5 so you will have no chance of proposing your language, but you can still work fairly well with it and with its margins for improvement. Current spec suggests how to use it with a JS framework, why don't you elaborate a proposal where template is able to load and parse its own content-to-be? (Of course you can even imagine loading a page which is initially empty, with just a declaration for a template, which adds content at runtime. But it is different from altering current content, a kind of operation that no web designer would desire to be natively executed). And finally, consider that JS complexity and JS memory load are 2 different aspects you will have to face with a brand-new language or featureset: - complexity deals with richness of use cases. When dealing with external content load you have to consider its origin, format, language, connection delay time (you focus on mobile experience, so you know what I mean), its parsing. You have your mind standards, but you can't think things go always ideally, nor you can consider that everybody uses the same structure you have in mind. JS is flexible in this, as it manipulates current DOM structure. Would your native implementation be flexible as well? (side note: if you look at template, its content is really flexible, as it allows as content model lists, tables, subsets of tables, menus and definitely all flow content subsets you can imagine.) It also deals with security. HTML cannot be stretched to execute direct SQL commands (what if those commands are maliciously altered? Do you guarantee instructions integrity? Or perhaps you provide a level of abstraction between HTML6 instruction and DB instruction? This only translates complexity from one language to another, you see), nor to directly respond to server-triggered events (you can imagine the issues of maintaining an open channel with the server in order for it to fire content loading events, both on the side of performance and security). - memory load is a completely different case. Yes, in order for a framework to work, you have to deal with downloading and compiling it, then it has to be executed. A native feature doesn't need downloads, but it makes UAs heavier when they have to deal with all the subtleties of content handling. You are suggesting that a UA behaves as a client for a specific server of your web app, in a 2-way interaction (you can talk about page and all, but the actor in a MVC as view and controller is the browser itself). Can you guarantee that the additional work managed by the user agent does not
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
You’re making this more complicated than it needs to be. Simplify the problem domain. I think we can all agree, we don't want another App Cache on our hands for a standard. Sorry you feel an idea can be thrown out, immediately accepted and pushed through simply because it seems obvious. In the real world, things aren't always boiled down to the simplest solutions. Sometimes, we need to have a bit of complexity and extra overhead in setting something up to make sure it is robust and effective in as many situations as possible. As has been said before, build a polyfill to show off your idea. I don't think many vendors want to spend time building this out in-browser to test when it is easily done in existing JS to get the idea down. We also need to stop thinking purely about how things were built two years ago. ES6 and Web Components introduce a lot of ground-breaking changes in this area, we should see how they play out with framework vendors before jumping into throwing it all into HTML and hoping it works well. So saying this is a “hard problem” just reeks of Javascript developer laziness This sounds very disrespectful. You're telling the people who are, writing the standards, paying attention to give input to new standards and modifying existing ones that they are lazy. They do this for a reason, most have been bitten by some poorly thought out standard. This could end up just another one. This kind of response does not encourage people to continue to have a conversation on the proposal with you. On Mon, Mar 30, 2015 at 9:08 AM, Andrea Rendine master.skywalker...@gmail.com wrote: Bobby, the major criticism you have received about your proposal is that you aren't considering at all any other party involved in this subject. Correct me if I'm wrong, you cite no user agent responsible for support, nor working groups or anything loosely resembling to that. You are providing a very useful insight on how *you* see the web. And you also provide a feedback based on the experience of high-school Tumblr girls (why should she learn how to use Angular? However, there's nothing bad if she learns something new). The fact is, your proposal cannot be labeled as HTML6 Web needs something new. And however your last messages do show that the proposal itself is not strictly related to read/write Web as you claim. In fact, the main reasons you cite behind your proposal are responsiveness and full-page reload latency. Which are real problems, for sure, but not in the sense of read/write, they're rather a matter of UX. A relative matter which does not make the Web largely unusable, and if you have doubt about it just have a look at ChromeExperiments and see what can be done with current poor methods. If what you need is localised content load, you have some features you can use as of now. For example, you can use nested browsing contexts, which also offer a layer of protection in the form of CORS restrictions, sandboxing and MIME type declaration. You want to get rid of these things? Use XHR, its support is native. As you said, you are not against JS itself, but against writing more Javascript than necessary. If you have the means, push towards a more pervasive standardisation of current JS implementation, so that there will be decreasing need for polyfills and syntax standardisers (with your proposal, there'd be a need for a polyfill as well until it doesn't become supported on new UA versions *and* new UA versions completely or substantially replace legacy versions). You still want more? Don't focus on changing a web page content. HTML is still a declarative language after all, and there's nothing bad with it. It's the purpose which originated it. Of course there's more now, but the examples of websites or web apps you cited don't generally change the content of a page, they integrate it, adding more items to the page as time passes and events happen. So, as I said some messages ago, why not focusing on template? It can add new elements to the existing document, it's HTML5 so you will have no chance of proposing your language, but you can still work fairly well with it and with its margins for improvement. Current spec suggests how to use it with a JS framework, why don't you elaborate a proposal where template is able to load and parse its own content-to-be? (Of course you can even imagine loading a page which is initially empty, with just a declaration for a template, which adds content at runtime. But it is different from altering current content, a kind of operation that no web designer would desire to be natively executed). And finally, consider that JS complexity and JS memory load are 2 different aspects you will have to face with a brand-new language or featureset: - complexity deals with richness of use cases. When dealing with external content load you have to consider its origin, format, language, connection delay time (you focus on mobile experience,
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, 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
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
On Mar 30, 2015, at 2:06 PM, Nathan White n...@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 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 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, n...@nwhite.net wrote: Bobby, I think your enthusiasm to question and challenge the status quo is great. Many
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
On Mar 30, 2015, at 9:23 AM, Jonathan Garbee jonat...@garbee.me wrote: You’re making this more complicated than it needs to be. Simplify the problem domain. I think we can all agree, we don't want another App Cache on our hands for a standard. Sorry you feel an idea can be thrown out, immediately accepted and pushed through simply because it seems obvious. In the real world, things aren't always boiled down to the simplest solutions. Sometimes, we need to have a bit of complexity and extra overhead in setting something up to make sure it is robust and effective in as many situations as possible. I expect this process to take years. Not sure where anyone thought that it was going to be immediately accepted? 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.) 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) We need to be able to advance the web without going through Javascript. It’s a mistake to assume that JS is a fundamental part of the web. The web is optimized for hypertext document processing, and most people use it to read content online. This proposal fixes a remaining issue with that. -bobby --- 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
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
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/
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
I'm going to say something not nice. Blame me freely. Back in the earliest days, it was pretty easy to publish a page of text... Easy enough for the average writer ... The fact that writing a simple document has become a programming job - between a lot more HTML functionality, CSS, and JavaScript - is (IMHO) a HUGE barrier to the basic concept of a read/write web. Yes. It has.For a long time everybody could write Web pages that, though inaccurate, reached their goal somehow. Which is why current HTML spec is full of - attempts to stop non-semantic use for elements (the edge case of layout tables should teach something), - error-handling rules, - complex paragraphs describing legacy compatibility with previous versions, - rules for correctly handling non-standard features, or existing features badly used (see object@classid et al.) - a huge list of non-conforming elements derived from presentational HTML or from browsers war era - and much more. Indeed, leaving some degree of freedom to authors allows a broad field test for what's good and what's missing in features. Sometimes it also allows that features are *invented* on field, only to become standard afterward. But IMHO publishing a web page is not an easy task. Nor it is required to be such. A web page isn't a Word document, even if Word can create web pages. Or, which is better, everything in content publishing is fun and games... until publisher and public are the same. When writing for other users, for interoperability, for potentially unknown or custom or *evolving* platforms, the it works for me approach is no longer applicable. Everybody can write content for a web page, of course, but publishing it in increasingly complex, visually attractive, accessible, semantic ways requires programming skills as well as any publishing sector requires its own skills.
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
Am .03.2015, 02:51 Uhr, schrieb Miles Fidelman mfidel...@meetinghouse.net: […] It seems like: - It's getting harder and harder to do simple things. Too many JavaScript frameworks and libraries. Too much complexity. Authoring should not require extensive programming skills. (Whatever happened to the read/write web?). I think that simple things are still simple to achieve. A few use cases became a little more verbose when presentational HTML parts were deprecated in favor of CSS (like now you have to write style=width:50% instead of width=50%), but other things have become easier than they were in the past, for example providing the document encoding (meta charset=… instead of meta http-equiv=Content-type content=text/html;charset=…). Does authoring as in writing articles on the web really require programming skills? I don't think so. Of course, if someone wants to have all the newest and shiniest interactive stuff, it may require some programming skills. But those are things that weren't easier in the past, are they? I think that they were hard too or not even possible. So things didn't become harder, but you can now do additional stuff that's hard. Too many JavaScript frameworks and libraries? We're not forced to use any, are we? So I don't understand. Well, I'm annoyed myself when people use JavaScript stuff instead of simpler things, for example span onclick=javascript:window.location.href='http://example.org/' instead of a href=http://example.org/;. But the point is that a link with an a-element still works as it always did; nobody asked people to use JavaScript instead. I think that web pages don't need to be complex; people make them complex. I don't consider that human characteristic to be solvable by adding more syntax options. Martin
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
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. On Mar 23, 2015, at 9:44 PM, Bobby Mozumder mozum...@futureclaw.com wrote: On Mar 23, 2015, at 2:18 PM, Brian Kardell bkard...@gmail.com wrote: At some level, you can safely say that you will tend to like your own design and find others a bit harder to understand.. Having experience with a whole lot of previous attempts, but not yours, for example, I can't say that I find yours to be especially simple or intuitive, but I won't claim to represent the norm any more than I ask you not to - so I agree, actual data is required. The data I have is the outside virality of this. We could probably even quantify this. I have to rely on outside feedback as well, and do take into considerations people's comments and iterate on the proposal as needed. Obviously Javascript developer are against it, but regular web developers look like they’re into it. This really should be part of the out-of-the-box HTML default use model. I will say that the XML nature is problematic, as is SQL for reasons we can actually point to. I’ll change the example to JSON. The SQL section could come later as well. Additionally, I will say that your list is pretty short, you'd also have to include things like XBL and MDV (http://mdv.googlecode.com/svn/trunk/docs/design_intro.html) and a whole bunch of other stuff that had powerful support and lots of investment, and give them some serious consideration as to why they failed to get agreement, implementation, adoption and staying power - then think about how your proposal would not fall victim to the same pressures. For me, personally at least, I think there are existing proposals which I already prefer more. I'm not seeing how an element is a 'controller' for example or how you make a controller non-imperative - even models generally have a data layer in a lot of frameworks which would currently confound me as to how to accomplish relation/request management declaratively.. I know we can get there, I want to get there - I just haven't seen the right proposal yet that answers all of those things. It definitely seems like for now you'd need a pretty rich JS API which you haven't even hinted at here. For this proposal, the controller isn’t an element. It’s the browser itself. The user interacts with the document View layer. He clicks on a link: A href=“http://api.mywebsite.com/data-endpoint” The view layer notifies the
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
Hello, I try to read every one of these mailing list emails,,, even though I don't respond. However, I think it is crying shame that the new details and other Interactive elements are not supported across all browsers. The details and the dialog elements are a great way to bypass some javascript. As a note to all browser vendors; Get with the program Thanks, Barry Smith Growing Web Developer -- From: Andrea Rendine master.skywalker...@gmail.com Sent: Friday, March 27, 2015 11:50 PM To: WHATWG whatwg@lists.whatwg.org Subject: Re: [whatwg] HTML6 proposal for single-page apps without Javascript It's sad indeed, as it seems that best practices are seldomly followed and poor coding is the way. However, some functionality ordinarily provided by JavaScript that now can be done by HTML5, e.g. the details tag and progress tag Actually progress is native only in its attribute definition and default rendering. It still requires JS in order to access its @value in write mode. On the other hand, I suppose that complete implementation of details is delayed by the fact that it's defined in terms of shadow DOM, and no real DOM adjusting is expected for it. Not every browser is ready for this further level of interface, probably. 2015-03-28 3:45 GMT+01:00 Michael A. Peters mpet...@domblogger.net: On 03/27/2015 06:51 PM, Miles Fidelman wrote: I've been reading through the discussion thread, all of which seems to jump immediately into the weeds of specific details of the proposal. I'm amazed that nobody has yet commented on the implicit premise, which I read as: - JavaScript is a processing pig - with the addition of a few, well-defined constructs to HTML, with support from browsers, we could do a lot of what we want (or what people are doing) - without the overhead imposed by JavaScript To me, this seems like a very good thing. It seems like: - It's getting harder and harder to do simple things. Too many JavaScript frameworks and libraries. Too much complexity. Authoring should not require extensive programming skills. (Whatever happened to the read/write web?). - JavaScript seems to encourage poor programming style, or at least resource-intensive programming. It seems like 2/3 of the web pages I visit either freeze up, or just take incredibly long to load. Granted, that a lot of this is this stems from all the little click monitoring apps, and widgets, and who knows what else people put on their pages - and waiting for those various sites to respond - but it's the proliferation of more and more JavaScript that enables this. In HTML5 some functionality ordinarily provided by JavaScript that now can be done by HTML5, e.g. the details tag and progress tag, is still not universally supported by modern browsers requiring JavaScript fallback. I don't know why it takes the browsers so long to implement, but it does. The problem with JavaScript is that fewer and fewer web devs care. Rather than picking a framework (like jQuery) and sticking with it, they copypasta JS they find around the web (often in violation of the license) and add whatever framework that snippet depends upon. Few people care about passing their JS through tools like JSLint, and many pages still have dozens of external JS references as well as numerous inline scripts. They just don't care. And that is hard to fix with standards because they don't care.
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
It's sad indeed, as it seems that best practices are seldomly followed and poor coding is the way. However, some functionality ordinarily provided by JavaScript that now can be done by HTML5, e.g. the details tag and progress tag Actually progress is native only in its attribute definition and default rendering. It still requires JS in order to access its @value in write mode. On the other hand, I suppose that complete implementation of details is delayed by the fact that it's defined in terms of shadow DOM, and no real DOM adjusting is expected for it. Not every browser is ready for this further level of interface, probably. 2015-03-28 3:45 GMT+01:00 Michael A. Peters mpet...@domblogger.net: On 03/27/2015 06:51 PM, Miles Fidelman wrote: I've been reading through the discussion thread, all of which seems to jump immediately into the weeds of specific details of the proposal. I'm amazed that nobody has yet commented on the implicit premise, which I read as: - JavaScript is a processing pig - with the addition of a few, well-defined constructs to HTML, with support from browsers, we could do a lot of what we want (or what people are doing) - without the overhead imposed by JavaScript To me, this seems like a very good thing. It seems like: - It's getting harder and harder to do simple things. Too many JavaScript frameworks and libraries. Too much complexity. Authoring should not require extensive programming skills. (Whatever happened to the read/write web?). - JavaScript seems to encourage poor programming style, or at least resource-intensive programming. It seems like 2/3 of the web pages I visit either freeze up, or just take incredibly long to load. Granted, that a lot of this is this stems from all the little click monitoring apps, and widgets, and who knows what else people put on their pages - and waiting for those various sites to respond - but it's the proliferation of more and more JavaScript that enables this. In HTML5 some functionality ordinarily provided by JavaScript that now can be done by HTML5, e.g. the details tag and progress tag, is still not universally supported by modern browsers requiring JavaScript fallback. I don't know why it takes the browsers so long to implement, but it does. The problem with JavaScript is that fewer and fewer web devs care. Rather than picking a framework (like jQuery) and sticking with it, they copypasta JS they find around the web (often in violation of the license) and add whatever framework that snippet depends upon. Few people care about passing their JS through tools like JSLint, and many pages still have dozens of external JS references as well as numerous inline scripts. They just don't care. And that is hard to fix with standards because they don't care.
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
On 03/27/2015 06:51 PM, Miles Fidelman wrote: I've been reading through the discussion thread, all of which seems to jump immediately into the weeds of specific details of the proposal. I'm amazed that nobody has yet commented on the implicit premise, which I read as: - JavaScript is a processing pig - with the addition of a few, well-defined constructs to HTML, with support from browsers, we could do a lot of what we want (or what people are doing) - without the overhead imposed by JavaScript To me, this seems like a very good thing. It seems like: - It's getting harder and harder to do simple things. Too many JavaScript frameworks and libraries. Too much complexity. Authoring should not require extensive programming skills. (Whatever happened to the read/write web?). - JavaScript seems to encourage poor programming style, or at least resource-intensive programming. It seems like 2/3 of the web pages I visit either freeze up, or just take incredibly long to load. Granted, that a lot of this is this stems from all the little click monitoring apps, and widgets, and who knows what else people put on their pages - and waiting for those various sites to respond - but it's the proliferation of more and more JavaScript that enables this. In HTML5 some functionality ordinarily provided by JavaScript that now can be done by HTML5, e.g. the details tag and progress tag, is still not universally supported by modern browsers requiring JavaScript fallback. I don't know why it takes the browsers so long to implement, but it does. The problem with JavaScript is that fewer and fewer web devs care. Rather than picking a framework (like jQuery) and sticking with it, they copypasta JS they find around the web (often in violation of the license) and add whatever framework that snippet depends upon. Few people care about passing their JS through tools like JSLint, and many pages still have dozens of external JS references as well as numerous inline scripts. They just don't care. And that is hard to fix with standards because they don't care.
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
I've been reading through the discussion thread, all of which seems to jump immediately into the weeds of specific details of the proposal. I'm amazed that nobody has yet commented on the implicit premise, which I read as: - JavaScript is a processing pig - with the addition of a few, well-defined constructs to HTML, with support from browsers, we could do a lot of what we want (or what people are doing) - without the overhead imposed by JavaScript To me, this seems like a very good thing. It seems like: - It's getting harder and harder to do simple things. Too many JavaScript frameworks and libraries. Too much complexity. Authoring should not require extensive programming skills. (Whatever happened to the read/write web?). - JavaScript seems to encourage poor programming style, or at least resource-intensive programming. It seems like 2/3 of the web pages I visit either freeze up, or just take incredibly long to load. Granted, that a lot of this is this stems from all the little click monitoring apps, and widgets, and who knows what else people put on their pages - and waiting for those various sites to respond - but it's the proliferation of more and more JavaScript that enables this. (Which is not to say that some folks write well behaving pages, nor that JavaScript isn't useful - just that it seems to be leading to more and more problems). One would think that commercial developers would know better than to release pages that drive users away, but no. As to the specifics, it sounds like the proposal is to move some XML processing functions into the browser. To me, Xpath, XSLT and XQuery, maybe a basic XML database - all in a browser, instead of server-side - sounds like a viable alternative to JavaScript for a lot of applications. Implement first as a JavaScript library, as a test and transition path. Could be kind of cool. Might also end up being just as much of a processing pig as JavaScript. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
Let's just leave the sharing out of this. There is no data as to *why* it is being shared. All that is is a red-herring to the technical discussion. Web Components are what you are looking for. Problem is, JS required. However that isn't a deal-breaker in most projects. You make a custom element that contains within it the standard paragraphs, headers, asides, etc. and you can feed data into that. No problem. It is *exactly* what you are describing except it takes an extra step of making a custom component. 75 million Wordpress sites and 200 million Tumblr blogs out there that treat web pages as basic documents. There is nothing restricting these sites from implementing web components under the hood. And besides, there’s still the problem of having to download huge power inefficient Javascript libraries. No problem with web components, they are *built into the browser.* ... break semantics with custom elements ... Semantics are only broken if you implement custom elements in a bad way. Making your own custom element just to put data into an h1 is doing it incorrectly. On Mon, Mar 23, 2015 at 8:57 AM, Bobby Mozumder mozum...@futureclaw.com wrote: On Mar 23, 2015, at 7:04 AM, Jonathan Garbee jonat...@garbee.me wrote: The buzz mostly comes from throwing of HTML6 into the title. HTML5 is a buzzword and this creates new buzz for the next version to act as click-bait for ad views. It also went viral from the mention since people were mocking the idea of HTML6 (and the single-page app system proposed.) As far as I know, HTML6 won't ever be an actual thing for any foreseeable time to come. HTML5 is now the Living Standard of HTML and will continue on indefinitely until it dies. Also, you’ll find that people share things that they like. Editors might, but readers have no vested interest in click-bait. -bobby --- Bobby Mozumder *Editor-in-Chief* FutureClaw Magazine mozum...@futureclaw.com +1-240-745-5287 www.futureclaw.com twitter.com/futureclaw https://www.twitter.com/futureclaw www.linkedin.com/in/mozumder
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
On Mon, Mar 23, 2015 at 12:31 PM, Bobby Mozumder mozum...@futureclaw.com wrote: On Mar 23, 2015, at 7:04 AM, Jonathan Garbee jonat...@garbee.me wrote: The buzz mostly comes from throwing of HTML6 into the title. HTML5 is a buzzword and this creates new buzz for the next version to act as click-bait for ad views. It also went viral from the mention since people were mocking the idea of HTML6 (and the single-page app system proposed.) As far as I know, HTML6 won't ever be an actual thing for any foreseeable time to come. HTML5 is now the Living Standard of HTML and will continue on indefinitely until it dies. My understanding was that WHATWG defines the living standard, and W3C creates versioned snapshots of it? I see there's an editors' draft of HTM5.1 being discussed on W3C. The idea is interesting yes, however it currently ends up in a sticky situation. You are recreating custom elements using HTML only and they aren't as expansive. Most of the conversation I have seen around this topic (while it is little) boils down to this as to why it isn't worth having. Your thoughts on JS Frameworks all trying to do this and failing, is why new standards are being made to address it. These are the pieces of web components [1]. Once full browser support exists for these JS will have direct power over what the frameworks are doing under the hood. With the bonus of any frameworks using the standards creating inter-compatible components with other technologies if they do things well enough. For right now, the proper move isn't to get rid of JS for these actions but let browser vendors know that developers what the web component features. -Garbee [1] http://webcomponents.org/ http://webcomponents.org/ I see Web Components as targeted more towards advanced GUI widgets. If you look at the examples that's what they all are. They're not enhancing very basic HTML elements. This proposal is meant to enhance existing HTML elements. Dynamically updating ARTICLE and P and H1 elements would be extremely useful for the 75 million Wordpress sites and 200 million Tumblr blogs out there that treat web pages as basic documents. Do we really need to break semantics by creating custom PAPER-ARTICLE and NG-P and B-H1 elements? Web components will continue to exist, but existing HTML elements should still be enhanced for modern use models. People already know the basic HTML elements, they should be able to use them. And besides, there's still the problem of having to download huge power inefficient Javascript libraries. -bobby To me it sounds a quite elegant solution to use web components to extend the existing elements, for example by using the is attribute, to allow them to actually fetch a specific resource from web as you suggested. Using this technique would also allow other developers to extend the new behaviour in order to embrace various specific use cases. -sandro --- 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
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
On Mar 23, 2015, at 7:04 AM, Jonathan Garbee jonat...@garbee.me wrote: The buzz mostly comes from throwing of HTML6 into the title. HTML5 is a buzzword and this creates new buzz for the next version to act as click-bait for ad views. It also went viral from the mention since people were mocking the idea of HTML6 (and the single-page app system proposed.) As far as I know, HTML6 won't ever be an actual thing for any foreseeable time to come. HTML5 is now the Living Standard of HTML and will continue on indefinitely until it dies. Also, you’ll find that people share things that they like. Editors might, but readers have no vested interest in click-bait. -bobby --- 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
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
On Mar 23, 2015, at 7:04 AM, Jonathan Garbee jonat...@garbee.me wrote: The buzz mostly comes from throwing of HTML6 into the title. HTML5 is a buzzword and this creates new buzz for the next version to act as click-bait for ad views. It also went viral from the mention since people were mocking the idea of HTML6 (and the single-page app system proposed.) As far as I know, HTML6 won't ever be an actual thing for any foreseeable time to come. HTML5 is now the Living Standard of HTML and will continue on indefinitely until it dies. My understanding was that WHATWG defines the living standard, and W3C creates versioned snapshots of it? I see there’s an editors’ draft of HTM5.1 being discussed on W3C. The idea is interesting yes, however it currently ends up in a sticky situation. You are recreating custom elements using HTML only and they aren't as expansive. Most of the conversation I have seen around this topic (while it is little) boils down to this as to why it isn't worth having. Your thoughts on JS Frameworks all trying to do this and failing, is why new standards are being made to address it. These are the pieces of web components [1]. Once full browser support exists for these JS will have direct power over what the frameworks are doing under the hood. With the bonus of any frameworks using the standards creating inter-compatible components with other technologies if they do things well enough. For right now, the proper move isn't to get rid of JS for these actions but let browser vendors know that developers what the web component features. -Garbee [1] http://webcomponents.org/ http://webcomponents.org/ I see Web Components as targeted more towards advanced GUI widgets. If you look at the examples that’s what they all are. They’re not enhancing very basic HTML elements. This proposal is meant to enhance existing HTML elements. Dynamically updating ARTICLE and P and H1 elements would be extremely useful for the 75 million Wordpress sites and 200 million Tumblr blogs out there that treat web pages as basic documents. Do we really need to break semantics by creating custom PAPER-ARTICLE and NG-P and B-H1 elements? Web components will continue to exist, but existing HTML elements should still be enhanced for modern use models. People already know the basic HTML elements, they should be able to use them. And besides, there’s still the problem of having to download huge power inefficient Javascript libraries. -bobby --- 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
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
The buzz mostly comes from throwing of HTML6 into the title. HTML5 is a buzzword and this creates new buzz for the next version to act as click-bait for ad views. It also went viral from the mention since people were mocking the idea of HTML6 (and the single-page app system proposed.) As far as I know, HTML6 won't ever be an actual thing for any foreseeable time to come. HTML5 is now the Living Standard of HTML and will continue on indefinitely until it dies. The idea is interesting yes, however it currently ends up in a sticky situation. You are recreating custom elements using HTML only and they aren't as expansive. Most of the conversation I have seen around this topic (while it is little) boils down to this as to why it isn't worth having. Your thoughts on JS Frameworks all trying to do this and failing, is why new standards are being made to address it. These are the pieces of web components [1]. Once full browser support exists for these JS will have direct power over what the frameworks are doing under the hood. With the bonus of any frameworks using the standards creating inter-compatible components with other technologies if they do things well enough. For right now, the proper move isn't to get rid of JS for these actions but let browser vendors know that developers what the web component features. -Garbee [1] http://webcomponents.org/ On Mon, Mar 23, 2015 at 6:11 AM, Bobby Mozumder mozum...@futureclaw.com wrote: On Mar 23, 2015, at 5:33 AM, Nils Dagsson Moskopp n...@dieweltistgarnichtso.net wrote: XForms, Microdata and XSLT all do different things. Note that no widely used browser supports XForms in its default configuration; while Chrome, Firefox, Internet Explorer, Safari and Opera all support XSLT. Can you explain the “clear usability design issues” you have seen in XSLT? If so, please do. There’s no locally persistent model object. It’s not an MVC framework. It’s a view layer. And it’s not just me. There’s a reason Angular, React, Ember, and so on don't use XSLT in trying to solve the single-page app problem, probably because it doesn’t have a locally persistent model object. I certainly did not. I would like to see an implementation of your proposal and several demonstrations. Do you have something on hand? Are you familiar with MVC design patterns? This would be what it is. Sorry, don’t have an implementation on me. What’s the process going forward? Do people need to write a web browser for every proposal? I agree in that buzz does not necessarily mean your proposal has merit. Did you ask the people talking about it? What were their opinions? -bobby --- 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
[whatwg] HTML6 proposal for single-page apps without Javascript pt.3
People are freaking out about the proposal idea of using SQL statements directly to populate the browser’s internal model data store, when I mentioned using A href=sql:select from *” a few things about this: 1. The security issues aren’t as big when operating on local data for a local app, like a single-player game on a mobile device. 2. There are millions of non-interactive websites with static content that also don't need to worry about complex security. You still have the same level of table read permissions, just disallow writes by default. 3. This was designed with a front-end sandbox perspective, not a back-end server perspective. For more complex authorization requirements, I expect a use model where the server transforms SQL statements. For example: SELECT first_name, last_name FROM users; would be transformed into: SELECT first_name, last_name FROM users WHERE manager=“Boss Man”; The back-end web/app server does this type of transform before hitting the database. The server basically offers the client a subset of the database schema. The client might not even see nor be aware of the “manager” column, for example. The front-end user just sees this limited sub-schema, and happily operates only that data. Since it’s up the the server to do this type of transform, the server might not even be using an SQL RDBMS, and it might transform/interface into something else entirely. 4. This SQL interface would be an optional spec. On the internet, you would most likely be using JSON APIs at first anyways. But I would recommend something like this because this was designed to eliminate a layer of back-end when using a local database app, as well as eliminating the need to use Javascript for such local database accesses. Anyways thanks for listening. If you vote for this, you can use me as a reference for 4 years of HTML6 experience. -bobby --- 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
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
On Mon, Mar 23, 2015 at 2:25 PM, Bobby Mozumder mozum...@futureclaw.com wrote: On Mar 23, 2015, at 10:15 AM, Sandro Paganotti sandro.pagano...@gmail.com wrote: well, yes; but once it's done accordingly to the behaviour required it could be released and then used by everybody. So it is just a matter of creating a new catalog of components that anyone can import using the html import. In my view it would be something really close to your initial implementation proposal: article is='json-enhanced' remote-node= http://apiname/endpoint.json:propertyname;/article -sandro. I think that's what being done right now, where everybody defines expected behavior of elements and create a catalog of components that anyone can import. We call that the web browser and that's why we're here. =^D +1; my point is: in this case I don't think it's necessary to move this solution into a native browser implementation. In my opinion the browser should provide tools developers can use to built web experiences. If I have to try to imagine a solution complex enough even only to handle some uses cases (eg: dealing with network problems, missing properties, etc..) it would look much like a small framework than a simple tool and, in my opinion, frameworks should be kept in a JS domain, so everyone can pick the one he like without having to deal with something already into the browser. -sandro. -bobby --- Bobby Mozumder *Editor-in-Chief* FutureClaw Magazine mozum...@futureclaw.com +1-240-745-5287 www.futureclaw.com twitter.com/futureclaw https://www.twitter.com/futureclaw www.linkedin.com/in/mozumder
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
On Mar 23, 2015, at 8:46 AM, Sandro Paganotti sandro.pagano...@gmail.com
wrote:
To me it sounds a quite elegant solution to use web components to extend
the existing elements, for example by using the is attribute, to allow them
to actually fetch a specific resource from web as you suggested. Using this
technique would also allow other developers to extend the new behaviour in
order to embrace various specific use cases.
-sandro
I don’t see that as a clean solution at all. Web developers still have to
learn the inherited model class
So, instead of:
ARTICLE model=“myArticleData”
You’re asking web developers to do something like:
var proto = Object.create(HTMLArticleElement.prototype, { // some
type of initial element definition
model: {
get: function() { … },
set: function() { … },
});
proto.createdCallback = function(model) { // now we have to
attach an event listener to the model
model.addEventListener(‘change’, function(e) {
e.target.model.set( model )
});
}
var xArticle = document.registerElement(‘x-article', { // now
register the element
prototype: proto,
extends: ‘article'
});
ARTICLE is=“X-ARTICLE” model=“myArticleData // and then use a
different name
(And this is the simplified version...)
-bobby
---
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
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
On Mon, Mar 23, 2015 at 2:05 PM, Bobby Mozumder mozum...@futureclaw.com
wrote:
On Mar 23, 2015, at 8:46 AM, Sandro Paganotti sandro.pagano...@gmail.com
wrote:
To me it sounds a quite elegant solution to use web components to extend
the existing elements, for example by using the is attribute, to allow them
to actually fetch a specific resource from web as you suggested. Using this
technique would also allow other developers to extend the new behaviour in
order to embrace various specific use cases.
-sandro
I don't see that as a clean solution at all. Web developers still have to
learn the inherited model class
So, instead of:
ARTICLE model=myArticleData
You're asking web developers to do something like:
var proto = Object.create(HTMLArticleElement.prototype, { // some type
of initial element definition
model: {
get: function() { ... },
set: function() { ... },
});
proto.createdCallback = function(model) { // now we have to attach an
event listener to the model
model.addEventListener('change', function(e) {
e.target.model.set( model )
});
}
var xArticle = document.registerElement('x-article', { // now register
the element
prototype: proto,
extends: 'article'
});
ARTICLE is=X-ARTICLE model=myArticleData // and then use a
different name
(And this is the simplified version...)
well, yes; but once it's done accordingly to the behaviour required it
could be released and then used by everybody. So it is just a matter of
creating a new catalog of components that anyone can import using the html
import. In my view it would be something really close to your initial
implementation proposal:
article is='json-enhanced' remote-node=
http://apiname/endpoint.json:propertyname;/article
-sandro.
-bobby
---
Bobby Mozumder
*Editor-in-Chief*
FutureClaw Magazine
mozum...@futureclaw.com
+1-240-745-5287
www.futureclaw.com
twitter.com/futureclaw https://www.twitter.com/futureclaw
www.linkedin.com/in/mozumder
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
On Mar 23, 2015, at 9:35 AM, Jonathan Garbee jonat...@garbee.me wrote: Let's just leave the sharing out of this. There is no data as to *why* it is being shared. All that is is a red-herring to the technical discussion. Web Components are what you are looking for. Problem is, JS required. However that isn't a deal-breaker in most projects. You make a custom element that contains within it the standard paragraphs, headers, asides, etc. and you can feed data into that. No problem. It is *exactly* what you are describing except it takes an extra step of making a custom component. How many lines of Javascript code do you need to write to do the following: ARTICLE model=“myArticleData” I tried to give a quick dirty one in my last msg and it didn’t look pretty. 75 million Wordpress sites and 200 million Tumblr blogs out there that treat web pages as basic documents. There is nothing restricting these sites from implementing web components under the hood. Of course there is a restriction: they don’t know Javascript. And besides, there’s still the problem of having to download huge power inefficient Javascript libraries. No problem with web components, they are *built into the browser.* You still have to write JS, and they’re not going to do that all the time. If they use Web components it will be in libraries. Web components are only going to be created for extremely complex widgets, not for H1, ARTICLE, etc.. -bobby --- 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
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
On Mar 23, 2015, at 10:15 AM, Sandro Paganotti sandro.pagano...@gmail.com wrote: well, yes; but once it's done accordingly to the behaviour required it could be released and then used by everybody. So it is just a matter of creating a new catalog of components that anyone can import using the html import. In my view it would be something really close to your initial implementation proposal: article is='json-enhanced' remote-node=http://apiname/endpoint.json:propertyname http://apiname/endpoint.json:propertyname/article -sandro. I think that’s what being done right now, where everybody defines expected behavior of elements and create a catalog of components that anyone can import. We call that the web browser and that’s why we’re here. =^D -bobby --- 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
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
Bobby Mozumder mozum...@futureclaw.com writes: On Mar 20, 2015, at 12:10 PM, Brian Kardell bkard...@gmail.com wrote: A few things worth noting: First, we've actually tried a bunch of this before, and you're not using it now so I think we can say that at some level it was unsuccessful. Thanks for the feedback here. I just had a quick look at some of the past proposals (XForms, Microdata, XSLT), and they all had clear usability design issues to me. XForms, Microdata and XSLT all do different things. Note that no widely used browser supports XForms in its default configuration; while Chrome, Firefox, Internet Explorer, Safari and Opera all support XSLT. Can you explain the “clear usability design issues” you have seen in XSLT? If so, please do. I suspect that many developers hate to be “forced” by language structure to think about clean abstractions and rather write maintenance-intensive spaghetti code. A friend of mine started learning how to make web pages recently – she was annoyed by the amount of “just use jQuery” (instead of CSS) that came up when she wanted to solve simple layout problems. For this, I focused on presenting the most obvious, usable solution, while trying to be very simple intuitive to a web developer. A usability test would be to see if people understand what I’m proposing. I certainly did not. I would like to see an implementation of your proposal and several demonstrations. Do you have something on hand? […] Already, though, for some reason this proposal went viral. Search Twitter for HTML6 to see what I mean. There are lots of discussions around it out there now, including blog posts and news articles. (It’s already big in Japan.) Here’s an example blog post that discusses this proposal: http://blog.smartbear.com/news/html6-apis-as-natural-friends/ With hundreds or thousands of shares, retweets, upvotes, etc.. it looks like a lot of people want a solution like this. I don’t know how it happened but I believe this represents peoples wide dissatisfaction with having to use Javascript frameworks. I agree in that buzz does not necessarily mean your proposal has merit. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
On Mar 20, 2015, at 12:10 PM, Brian Kardell bkard...@gmail.com wrote: A few things worth noting: First, we've actually tried a bunch of this before, and you're not using it now so I think we can say that at some level it was unsuccessful. Thanks for the feedback here. I just had a quick look at some of the past proposals (XForms, Microdata, XSLT), and they all had clear usability design issues to me. For this, I focused on presenting the most obvious, usable solution, while trying to be very simple intuitive to a web developer. A usability test would be to see if people understand what I’m proposing. Second, I am going to submit for comment that there are a couple of significant reasons why it failed and why I don't expect we'd have much more success with it if we were to take it up right now and you can kind of sum them up like this: There isn't something close enough to actually emerging that remotely looks ready and standards bodies are historically terrible at that class of problem. You’re looking at it from bottom-up. They’re all trying to implement the missing MVC framework in browsers, and are just working on implementation issues. Javascript implementation have no real relevance to HTML. For example, would you implement React’s framework or API design in the browsers if they solved everything? What would be the next step in your statement? I think we really need a top-down focus on a separate HTML-based solution: find the problem, and solve for that. Not, find a solution, and fit that into another problem domain. It's a really, really, really hard problem to abstract something at such a high level which meets all of the use cases people actually have which plays into why there are so many ever-changing solutions in the ecosystem - they're actually trying to figure it out and that's a good thing. It's rarely as simple as it appears at first blush and good ideas breed new possibilities of even better realizations. As the number of people using these tools increases, we gain additional input and data - Along the way they are helping to identify where there _are_ commonalities and suggest lower level additions that can be standardized as well as providing necessary failed experiments that go into finding a good solution. A lot of the work appears to be focused on Javascript issues and optimizations at this point. These frameworks were originally designed to solve the same missing MVC framework problem, but now they’re working through details of Javascript implementation, like Angular’s design issues and React’s virtual DOM optimization technique. Their current work would have little relevance to something outside Javascript. Also, something like React.js is 400kb, and that’s without data modeling, and people are saying we should mix multiple frameworks. Do we really want to attach 400kb or more of Javascript to every web page? Can we not? There’s a latency power costs associated with it. If we let the browser handle the MVC framework, then it can manage power and memory on its own, while reducing initial latency. In general, see http://extensiblewebmanifesto.org or search for articles/posts related for the thoughts of a lot of us in the community on topics like this and, if you have an idea for what would be better - find some people to help you build it, give people an opportunity to try it and see... Where you can't, raise interesting questions about why and lets build up a platform where we can make reasonable explanations to build up higher-level proposals. I do expect this idea will take years to work through, and will try to gain some support while taking other past/present/future attempts into account, in both HTML and Javascript. Already, though, for some reason this proposal went viral. Search Twitter for HTML6 to see what I mean. There are lots of discussions around it out there now, including blog posts and news articles. (It’s already big in Japan.) Here’s an example blog post that discusses this proposal: http://blog.smartbear.com/news/html6-apis-as-natural-friends/ With hundreds or thousands of shares, retweets, upvotes, etc.. it looks like a lot of people want a solution like this. I don’t know how it happened but I believe this represents peoples wide dissatisfaction with having to use Javascript frameworks. -bobby --- Bobby Mozumder Editor-in-Chief FutureClaw Magazine mozum...@futureclaw.com +1-240-745-5287 www.futureclaw.com twitter.com/futureclaw www.linkedin.com/in/mozumder
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
On Mar 23, 2015, at 5:33 AM, Nils Dagsson Moskopp n...@dieweltistgarnichtso.net wrote: XForms, Microdata and XSLT all do different things. Note that no widely used browser supports XForms in its default configuration; while Chrome, Firefox, Internet Explorer, Safari and Opera all support XSLT. Can you explain the “clear usability design issues” you have seen in XSLT? If so, please do. There’s no locally persistent model object. It’s not an MVC framework. It’s a view layer. And it’s not just me. There’s a reason Angular, React, Ember, and so on don't use XSLT in trying to solve the single-page app problem, probably because it doesn’t have a locally persistent model object. I certainly did not. I would like to see an implementation of your proposal and several demonstrations. Do you have something on hand? Are you familiar with MVC design patterns? This would be what it is. Sorry, don’t have an implementation on me. What’s the process going forward? Do people need to write a web browser for every proposal? I agree in that buzz does not necessarily mean your proposal has merit. Did you ask the people talking about it? What were their opinions? -bobby --- 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
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
On Mon, Mar 23, 2015 at 4:44 AM, Bobby Mozumder mozum...@futureclaw.com wrote: [snip] Thanks for the feedback here. I just had a quick look at some of the past proposals (XForms, Microdata, XSLT), and they all had clear usability design issues to me. For this, I focused on presenting the most obvious, usable solution, while trying to be very simple intuitive to a web developer. A usability test would be to see if people understand what I’m proposing. At some level, you can safely say that you will tend to like your own design and find others a bit harder to understand.. Having experience with a whole lot of previous attempts, but not yours, for example, I can't say that I find yours to be especially simple or intuitive, but I won't claim to represent the norm any more than I ask you not to - so I agree, actual data is required. I will say that the XML nature is problematic, as is SQL for reasons we can actually point to. Additionally, I will say that your list is pretty short, you'd also have to include things like XBL and MDV (http://mdv.googlecode.com/svn/trunk/docs/design_intro.html) and a whole bunch of other stuff that had powerful support and lots of investment, and give them some serious consideration as to why they failed to get agreement, implementation, adoption and staying power - then think about how your proposal would not fall victim to the same pressures. For me, personally at least, I think there are existing proposals which I already prefer more. I'm not seeing how an element is a 'controller' for example or how you make a controller non-imperative - even models generally have a data layer in a lot of frameworks which would currently confound me as to how to accomplish relation/request management declaratively.. I know we can get there, I want to get there - I just haven't seen the right proposal yet that answers all of those things. It definitely seems like for now you'd need a pretty rich JS API which you haven't even hinted at here. [snip] You’re looking at it from bottom-up. They’re all trying to implement the missing MVC framework in browsers, and are just working on implementation issues. Javascript implementation have no real relevance to HTML. For example, would you implement React’s framework or API design in the browsers if they solved everything? What would be the next step in your statement? ...[snip] I think we really need a top-down focus on a separate HTML-based solution: find the problem, and solve for that. Not, find a solution, and fit that into another problem domain. It's certainly not the case that there is a this is the agreed upon standard concept - there is MVVM, MDV, MVP and so on - angular, for example, was model view whatever. Routing is also a concept in most of these and a lot of the design that's come out is a lot closer as a piece and contains useful paradigms for promoting recommendations about URLs. So there are some cow paths being tred, and their competition and collaboration is actually a good thing in my mind - all of them are getting better for it. Note, I don't implement anything natively in browsers, that's implementers and I am not employed by one. React is not a proposal, it's a framework - there's a pretty big difference. If Facebook (or ember or angular or anyone else) actually solved everything, worked with others and developers were adopting it and it had some stability and they submitted a proposal that captured a layered explanation of a really useful paradigm, absolutely I'd support it. The last effort I saw at this was linked above (MDV) and that's being experimented with in polymer, but I think it's currently withdrawn - but polymer is working with angular and ember devs, and all of those are learning things from React. That's good in the long run, how many long, hypothetical emails on a list like this would we have to have to arrive there? All of these frameworks have a lot of code, as you've noted, and a lot of abstractions and hooks - therefore, they generally make for a pretty complex proposal. My own goal, however, is _absolutely_ that wherever possible a proposal would come with a prollyfill which allows users to try it, gain some experience and help improve it before it becomes a standard and ultimately can serve as a polyfill for browsers that don't support it yet. High level things are great, I love them. I have some, I'd like to have more. They're also hard to agree on and very closed-ended - the potential to get it wrong is great - all the more so when the design happens in a committee before anyone has implemented or tried to use anything for real work. There are definitely pieces of your proposal or frameworks that could be broken down and useful outside a whole MVC proposal and stand a better chance of entering the collective DNA of a possible larger solution and allowing us to create an adaptable platform, and there are definitely inroads where we can be moving the whole idea
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
On Mar 23, 2015, at 2:18 PM, Brian Kardell bkard...@gmail.com wrote: At some level, you can safely say that you will tend to like your own design and find others a bit harder to understand.. Having experience with a whole lot of previous attempts, but not yours, for example, I can't say that I find yours to be especially simple or intuitive, but I won't claim to represent the norm any more than I ask you not to - so I agree, actual data is required. The data I have is the outside virality of this. We could probably even quantify this. I have to rely on outside feedback as well, and do take into considerations people's comments and iterate on the proposal as needed. Obviously Javascript developer are against it, but regular web developers look like they’re into it. This really should be part of the out-of-the-box HTML default use model. I will say that the XML nature is problematic, as is SQL for reasons we can actually point to. I’ll change the example to JSON. The SQL section could come later as well. Additionally, I will say that your list is pretty short, you'd also have to include things like XBL and MDV (http://mdv.googlecode.com/svn/trunk/docs/design_intro.html) and a whole bunch of other stuff that had powerful support and lots of investment, and give them some serious consideration as to why they failed to get agreement, implementation, adoption and staying power - then think about how your proposal would not fall victim to the same pressures. For me, personally at least, I think there are existing proposals which I already prefer more. I'm not seeing how an element is a 'controller' for example or how you make a controller non-imperative - even models generally have a data layer in a lot of frameworks which would currently confound me as to how to accomplish relation/request management declaratively.. I know we can get there, I want to get there - I just haven't seen the right proposal yet that answers all of those things. It definitely seems like for now you'd need a pretty rich JS API which you haven't even hinted at here. For this proposal, the controller isn’t an element. It’s the browser itself. The user interacts with the document View layer. He clicks on a link: A href=“http://api.mywebsite.com/data-endpoint” The view layer notifies the browser of a click. The browser fetches http://api.mywebsite.com/data-endpoint and loads data into the model objects. The model objects update the document View layer. So, when you consider the browser to be the controller, this design and use model makes sense, and follows the same use model as now. Instead of loading a new page, you load data objects now. All the logic to do that is in the browser. Plus, the browser already has a whole Javascript framework that can be used to enhance its behaviour. If I want to do some processing on the models, just write some Javascript callback code to do so. Bam. Done and done. People are freaking out about the idea of separation of concerns with the HTML acting as logic, but it isn’t doing logic here. The browser is still responsible for logic, and it has default behaviors for these models (Clicking on this link loads external data into this model) which you can extend (convert the Markdown model data into HTML, or load API data at a scroll point”) -bobby --- 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
Re: [whatwg] HTML6 proposal for single-page apps without Javascript pt.2
Hi, the part 2 of this message is awaiting moderation due to message size, but it already went through at: https://lists.w3.org/Archives/Public/public-html/2015Mar/0075.html Moderator, please allow it to continue. I tried to cancel it for WHATWG but the lists.whatwg.org server is offline and the message already went through on w3.org. thank you! -bobby --- 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
[whatwg] HTML6 proposal for single-page apps without Javascript
There’s a standard design pattern emerging via all the front-end javascript frameworks where content is loaded dynamically via JSON APIs. This is the single-page app web design pattern. Everyone’s into it because the responsiveness is so much better than loading a full page - 10-50ms with a clean API load vs. 300-1500ms for a full HTML page load. Since this is so common now, can we implement this directly in the browsers via HTML so users can dynamically run single-page apps without Javascript? My goal would be a high-speed responsive web experience without having to load Javascript. This could probably be done by linking anchor elements to JSON/XML (or a new definition) api endpoints, having the browser internally load the data into a new data structure, and the browser then replaces DOM elements with whatever data that was loaded as needed. The initial data (as well as standard error responses) could be in header fixtures, which could be replaced later if desired. The HTML body thus becomes a tempting language, with all the content residing in the fixtures that can be dynamically reloaded without Javascript. Example web page: DOCTYPE html HTML LANG=“en” HEAD FIXTURES lang=“xml” model class=“MyArticleData” rsp stat=“ok article label=“one” id=“1 headlineBig News!”/headline bodypThis is the first article intro./ppThis is the second paragraph./p/body /article article label=“two” id=“2 headlineNot so big news/headline bodypThis is the emsecond/em article./p/body /article /rsp /model model class=“MyImageData” rsp stat=“ok image label=Square width=75 height=75 source=https://mycontentserver.com/image_s.jpg; id=“3/ image label=“Tall width=“300 height=“200 source=https://mycontentserver.com/image_l.jpg; id=“4/ /rsp rsp stat=“loading image label=Square width=75 height=75 source=https://mycontentserver.com/loading_image_s.jpg; id=“1/ /rsp rsp stat=“some_error image label=Square width=75 height=75 source=https://mycontentserver.com/error_image_s.jpg; id=“2/ message /rsp /model /FIXTURES /HEAD BODY MENU class=“controller” A href=“http://api.mywebsite.com/api/load-new-article” model=“MyArticleDataClick here to replace the articles with different articles./A A href=“http://api.mywebsite.com/api/load-new-image” model=“MyImageDataClick here to replace the picture with a different picture./A /MENU MAIN class=“viewer” ARTICLE class=“center H1 model=“MyArticleData.rsp.article(label=‘one’).headline” / SPAN model=MyArticleData.rsp.article(label=’one’).body” / /ARTICLE ARTICLE class=“sidebar H1 model=“MyArticleData.rsp.article(label=’two’).headline” / SPAN model=“MyArticleData.rsp.article(label=’two’).body” / /ARTICLE IMG src=“model:MyImageData.rsp.image(label=‘Square’)#source” width=“model:MyImageData.rsp.image(label=‘Square’)#width” height=“model:MyImageData.rsp.image(label=’Square’)#height” /MAIN /BODY /HTML Hope this makes it clear. Clicking on a link loads JSON/XML data into a new internal data structure. This is separate from the DOM. I have the initial XML fixtures in the HEAD section here, but these fixtures can be in an external link, or implicitly defined by default within the BODY elements that contain references to models. The data structure can be defined implicitly like in this example via XML/JSON fixtures, or perhaps explicitly by SQL statements. The text sections have H1 and SPAN tags with a new MODEL attribute that defines the content in it based on the loaded data. This format is declarative, but can approach SQL statement complexity. You don’t need to have defined controller/view structures, but I did in this example. There is also a “model:” URI that old attributes and the rest of the page can use to references the loaded data. Anything in the DOM should be replaceable, including the URL bar and style sheets. This internal data can be modified by Javascript if needed, separate from modifying the DOM - you could export this data for form processing if you wish. This internal data can also be push updated by a server or connected directly to a local database for caching or persistence - the browser manages this now, instead of the web developer/Javascript. Model references are defined so that it can
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
On 03/20/2015 02:10 AM, Bobby Mozumder wrote: There’s a standard design pattern emerging via all the front-end javascript frameworks where content is loaded dynamically via JSON APIs. This is the single-page app web design pattern. Everyone’s into it because the responsiveness is so much better than loading a full page - 10-50ms with a clean API load vs. 300-1500ms for a full HTML page load. *snip* Not everyone is into it. I hate it. For many reasons. Only place I like it is for feeds, like Tumblr, and even there is can be really problematic sometimes. Web devs can keep using it, free world, but calling it HTML6 would be absurd. HTML should not embrace particular design choices. My two cents.
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
There’s a standard design pattern emerging via all the front-end javascript frameworks where content is loaded dynamically via JSON APIs. So it’s already possible, right? :) Even if HTML would accommodate, how would we know we’re not just moving complexity from one end to the other? Would we want that? Why? * * From my point of view we’ve made this mistakes a few times, and I deem the most prominent one CSS variables/custom properties. (See e.g. http://www.w3.org/People/Bos/CSS-variables.) -- Jens Oliver Meiert http://meiert.com/en/ ✎ The Little Book of HTML/CSS Frameworks: http://meiert.com/frameworks
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
Going to liberally snip the bits I'm responding to... On Fri, Mar 20, 2015 at 5:10 AM, Bobby Mozumder mozum...@futureclaw.com wrote: There’s a standard design pattern emerging via all the front-end javascript frameworks where content is loaded dynamically via JSON APIs. This is the single-page app web design pattern. [snip] Since this is so common now, can we implement this directly in the browsers via HTML so users can dynamically run single-page apps without Javascript? [snip] Anyways, what do you think about this? I think something like this could eliminate a lot of Javascript. These javascript frameworks are all trying to do this, but none of them do it easily and they’re always being redesigned. Something should be done to standardize on it at a higher level. There’s a tremendous speed advantage in this, and we shouldn’t have to program in Javascript for such a common design pattern. Web pages should be loadable with 60fps speeds and should be as responsive as native apps. -bobby --- 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 A few things worth noting: First, we've actually tried a bunch of this before, and you're not using it now so I think we can say that at some level it was unsuccessful. Second, I am going to submit for comment that there are a couple of significant reasons why it failed and why I don't expect we'd have much more success with it if we were to take it up right now and you can kind of sum them up like this: There isn't something close enough to actually emerging that remotely looks ready and standards bodies are historically terrible at that class of problem. It's a really, really, really hard problem to abstract something at such a high level which meets all of the use cases people actually have which plays into why there are so many ever-changing solutions in the ecosystem - they're actually trying to figure it out and that's a good thing. It's rarely as simple as it appears at first blush and good ideas breed new possibilities of even better realizations. As the number of people using these tools increases, we gain additional input and data - Along the way they are helping to identify where there _are_ commonalities and suggest lower level additions that can be standardized as well as providing necessary failed experiments that go into finding a good solution. In general, see http://extensiblewebmanifesto.org or search for articles/posts related for the thoughts of a lot of us in the community on topics like this and, if you have an idea for what would be better - find some people to help you build it, give people an opportunity to try it and see... Where you can't, raise interesting questions about why and lets build up a platform where we can make reasonable explanations to build up higher-level proposals. Anyway, that's my 2 cents, as they say. -- Brian Kardell :: @briankardell :: hitchjs.com
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
On 2015-03-20 21:13, Bobby Mozumder wrote: On Mar 20, 2015, at 7:12 AM, Jens Oliver Meiert j...@meiert.com wrote: So it's already possible, right? :) Maybe, with a lot of expensive Javascript coding. Of course, anything is possible with a lot of expensive coding. The goal should be to make it simple. That's why Facebook has 1.5 billion users while there are only a few hundred thousand front-end Javascript framework developers. Even if HTML would accommodate, how would we know we're not just moving complexity from one end to the other? Would we want that? Why? * The goal should be to make things simpler, not more complex. People should pick up on it quickly. Were you able to pick up on my example quickly? How long would it take to learn a Javascript framework? At the very least, the entire goal is to have browsers, by default out-of-the-box, be able to serve pages as fast as possible. You're competing against native apps that already do so, and you're losing. Those 10s of milliseconds are important to the user. -bobby --- I do not catch the simil between an app (Facebook) vs. the future of HTML6, my excuses. I do not remember neither hold the notion that the needs of HTML5 were build due to the highest succes of the MySpace platform, during those early days. I do no think that account number of users may define any standard, mainly because of the audience (user) are just this, audience. I like the idea and the schema to simplify and avoid unnecessary frameworks, but this should be implemented in a higher level, i.e the DOM. Time to render apps or pages does not depend only on the ability of the developer, but on the will of the companies that provide access to the net. So the simpler, the better, for we cannot presume of the values of lenght and latence by the services provided by this companies, when we are connecting through an external service. For Intranets, the present model works quite good. And your proposal soounds brilliant to me. I am thinking now on the SMTP/Mail protocol scenario, not yet abbandoned, and I guess that will be a good start to decide means for future goals. Best --- [1] Delfi Ramirez My digital signature [2] +34 633 589231 del...@segonquart.net [3] twitter: delfinramirez IRC: segonquart Skype: segonquart [4] http://segonquart.net [5] http://delfiramirez.info [6] /in/mozumder [1] Links: -- [1] http://www.linkedin.com/in/mozumder [2] http://delfiramirez.info/public/dr_public_key.asc [3] mail:%20del...@segonquart.net [4] skype:segonquart [5] http://segonquart.net [6] http://delfiramirez.info
Re: [whatwg] HTML6 proposal for single-page apps without Javascript
The HTML body thus becomes a tempting language, with all the content residing in the fixtures that can be dynamically reloaded without Javascript. Sorry I just noticed an autocorrect typo. The above statement should be: The HTML body thus becomes a templating language, with all the content residing in the fixtures that can be dynamically reloaded without Javascript. --- 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
