Live data from Hacker News

AXR: A better(?) alternative to HTML+CSS

axr.vg

31–40 of 65 posts

Re: AXR: A better(?) alternative to HTML+CSS

#31

I don't understand why they are implementing the prototype in C++. If you built it in JavaScript, any modern browser could load their alternative markup and render it through some sort of fallback (I would expect HTML5+CSS+Canvas+SVG all put together provide enough functionality to render content expressed in their new language(s)). Building it in C++ basically guarantees that nobody will be able to use it, ever, bec…

It's a nice idea, but I doubt any JS+Canvas or JS+SVG implementations are fast and memory efficient enough to implement this. They probably don't have enough low level access to UI or network APIs either.

Re: AXR: A better(?) alternative to HTML+CSS

#32
post #9
post #3

I don't think XML is any better than HTML for presentation. In fact, HAML is way better, and much more powerful. In the same way I don't see why to use HSS when we have SASS/SCSS, Jade, Less...

These abstract metalanguages are still somewhat limited by the underlying base of HTML and CSS. Some things simply can't be accomplished with CSS, no matter how many SASS macros you write (e.g. reparent an element), or you'll just end up with lot of code to do tasks which would be simple with HSS. I believe that point of AXR is to replace this underlying base, with something more suitable for web applications. You co…

What do you mean by reparenting an element if not the nesting example given on the SASS homepage?

Re: AXR: A better(?) alternative to HTML+CSS

#33

Earlier quoted context omitted.

You're right: HTML is going to stay with us for a long, long time. This is not about eliminating it, but to try something new as an alternative. It's not XML with vector shapes, that's exactly what SVG is . Vector shapes would live all inside HSS, where you could reuse them, style them, give them flexible sizes, apply effects, etc... Once flexbox, grids and calc come out as official specs, you'll still have to wait u…

Once flexbox, grids and calc come out as official specs, you'll still have to wait until all browsers implements them, and then wait again until enough users update How would the situation be any different for AXR?

The plan is to make the rendering engine an auto-updateable library, that's independent of the browser's release schedule. Thus, users would stay current faster.

On the other hand, there will be a versioning system, so that authors can specify what version of the technology they are targeting. So if the spec changes, compatibility modules can be created akin to how Adobe apps open documents differently if they are CS3 or CS5 documents, interpreting them according to what version they are.

Usually, layers can be built with new features, where only the very basic aspects of your design require a certain feature set, while others can be optional. In some scenarios, the user will have an outdated system and the author has REQUIRED a higher version than what is installed. Then a built-in prompt to update could be displayed, maybe with an option to view anyways, with the knowledge that it may render incorrectly.

Long story short, there are many things that can be done, and we certainly will learn a lot along the way, but I think we should definitely try.

Re: AXR: A better(?) alternative to HTML+CSS

#35

Earlier quoted context omitted.

So can you do "myElement { alignY: 50% }" or something like that to automatically center vertically in your browser? Or can you do "100% - ref(width of sideColumns)" to create two fixed-width and one fluid column in the middle? Or can you rely on having exactly the same interpretation of your code across all browsers? ... I guess you are looking at just a limited subset of what AXR is, mainly the syntax features that…

Why do you think AXR would have the same interpretation across all browsers? Dont you think somone cough will make their own implementation that fucks up the rendering/layouting just for the heck of it? cough

As long as the reference implementation gets a decent head start, any re-implementers will practically be forced to maintain complete compatibility with it. This model works quite well for programming languages.

Re: AXR: A better(?) alternative to HTML+CSS

#36
I was expecting something different. I thought this was going to contain solutions for building web apps at scale, but it's basically a way to build plain old websites with a somewhat nicer and more maintainable syntax.

Some things that I want to see solutions for:

* Implementing richer controls that can behave as if they are native to the platform (e.g. building a better date picker that is fully encapsulated from the perspective of the developer)

* Dealing with styling at scale (tens of thousands of lines, up to a dozen levels of element nesting)

* Encapsulating application modules so they are incapable of conflicting with other application modules (in structure, behavior and styling), and can have a separate lifecycle from the page they are loaded into.

To me those are the real problems in building web apps at scale, and I was expecting to see solutions for these.

Re: AXR: A better(?) alternative to HTML+CSS

#37
post #3

I don't think XML is any better than HTML for presentation. In fact, HAML is way better, and much more powerful. In the same way I don't see why to use HSS when we have SASS/SCSS, Jade, Less...

The author hasn't suggested XML for presentation, but rather for content.

Re: AXR: A better(?) alternative to HTML+CSS

#38

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 s…

Performance doesn't matter if nobody can use it, and right now nobody can use it. By the time you have a working C++ implementation, for all you know v8 and SpiderMonkey's optimizers will be generating code just as fast as your C++. You're allowing an engineer's natural love of premature optimization to distract you from actually getting your product in front of people. C++ is also less cross-platform in this sense b…

By the time you have a working C++ implementation, for all you know v8 and SpiderMonkey's optimizers will be generating code just as fast as your C++.

I dont think that's going to happen anytime soon.

But I agree that JavaScript is the way to go with this. The prize is not that high to justify such a steep adoption curve. I mean "make A as wide as B is high" can be accomplished in javascript today.

Re: AXR: A better(?) alternative to HTML+CSS

#39
post #32
post #9

Earlier quoted context omitted.

These abstract metalanguages are still somewhat limited by the underlying base of HTML and CSS. Some things simply can't be accomplished with CSS, no matter how many SASS macros you write (e.g. reparent an element), or you'll just end up with lot of code to do tasks which would be simple with HSS. I believe that point of AXR is to replace this underlying base, with something more suitable for web applications. You co…

What do you mean by reparenting an element if not the nesting example given on the SASS homepage?

In presentation - http://www.slideshare.net/veosotano/axr-presentation-betabee... - slides 12 and 13, including new elements creation (http://axr.vg/spec/chapter/55). Didn't find anything on parent property in spec, though. Nesting is also planned (slide 15)

Re: AXR: A better(?) alternative to HTML+CSS

#40
post #36

I was expecting something different. I thought this was going to contain solutions for building web apps at scale, but it's basically a way to build plain old websites with a somewhat nicer and more maintainable syntax. Some things that I want to see solutions for: * Implementing richer controls that can behave as if they are native to the platform (e.g. building a better date picker that is fully encapsulated from t…

You're rising some interesting questions. Mind posing them on the mailing list? That would be awesome :D Cheers.
Post reply on HN