|
Hi there! My name is Miro Keller, and I'm the founder of AXR, so I'll probably be the best person to answer any questions you guys may have. So feel free to ask me anything about this project :) I'll try to answer all questions posed here, step by step: @shimonamit:
The code is not the only part that's important here, it's just one piece of the puzzle. So how would you go about to determine what part of the code to show, and at the same time try to convey the general idea to the visitors, without overwhelming them with too much information at once? If you click on the "enter the site" button you'll see the spec, where there's plenty of code for you to read through :) @ahrens:
One of the most important points about the project it's that it would be the same library used by the browsers, they wouldn't reimplement it. And to account for syntax variations in future versions, there is a versioning system, where the author of the document declares which one it is targeting. Thus, the rendering engine will know what the author actually wanted to say and interpret it accordingly. What other ways of sharing data do you mean? We are open to suggestions about what technologies to use, we just want it to be great. Keep in mind that there are a couple of requirements, all of which are achieved with XML, such as: - It needs a way to be semantic, so that common things on the internet must be representable, such as products, events, flight reservations, etc. XML solves this with namespaces.
- It needs to be able to provide a way to show documents written in that language in current browsers using a plug-in. XML solves that with XSLT (there will be a standard .xls file for easy backwards compatibility).
- It should be able to be just uploaded on an FTP server by the average author, just as HTML, without installing server-side software or messing around with settings.
- It should be easy to write for authors. So, again, we are open for suggestions, but keep in mind those requirements. If any other one you know of fits the bill, we would love to hear about it! @drKarl
You're missing the point. XML is used to represent the structure of your data, not the presentation. That's what HSS is for. On the other hand, with all those other languages you mentioned you have the problem that you'll always end with plain old CSS. Therefore you may get an easier syntax, but you still have all the problems associated with CSS: browser fragmentation, static syntax (you can't do "100%-50px" or "ref(height of myOtherElement)" ), no vector shapes support in the language itself (SVG doesn't count), etc. @lovskogen
Well AXR tries to be an alternative platform to HTML+CSS, not to replace it. It would still face much competition from that and Flash, Silverlight, or any other RIA out there.... The proposed solution is that the implementation is provided by the project itself, so that the rendering engine would be always the same. They could still differentiate themselves by providing unique UI, history management, social media integration, developer tools, etc. The part that we want to be the same, and only that part, would be the same. Of course, there is more to it than this, such as auto updating the engine independently from the browser, versioning system for stylesheets, etc, but that would be too in depth to discuss it here :) @kevingadd
Basically the main reason we opted for C++ was performance and cross-platform compatibility. Doing it in JavaScript would make it slow as hell. But hey, we would love to see more ideas of how this could be done. At the end of the day this is just a prototype, it is meant to explore ideas and see if and how this can be done at all. You're wrong about nobody able to use it, since one of the main goals of this project is to support older browsers to increase chances of adoption. That's why there is a step-gap measure in the plan to create a wrapper that will use the library as a browser plug-in, so that it can be installed anywhere where there is a NPAPI or ActiveX interface (in IE). We already spotted a framework that will assist us in this (http://www.firebreath.org), so hopefully this won't be too difficult :) Cheers,
Miro |
C++ is also less cross-platform in this sense because to support multiple platforms, you will have to support compilation across target platforms and handle the variety of plugin APIs available for those platforms. And on iOS, your stuff won't work at all because it's Javascript or the highway if you want to run in Safari. (I guess you could ship your own browser on the App Store, but I suspect you'd run into rule hassles.) Maybe you could use Native Client, but in that case you will need to ship native client binaries for each CPU architecture and you'll only work inside Chrome.
Attempting to entirely supplant the browser's rendering engine with yours in a plugin is also a hopelessly shortsighted move. You'll be throwing out all the hardware acceleration and advanced layout logic provided by modern browsers. Just rendering text is complex enough to require multiple full-time salaried engineers, and you will have to bear that burden if you will ever be compatible with HTML/CSS, because international text is important.
Build a prototype using JavaScript, HTML, and Canvas/SVG where needed. Put it in front of people. Let web designers and programmers play with it. If they can play with it, they'll find reasons to love it. Once you have web designers and programmers who love your actual product, you have a path to success.