none
Web Development - Speed Thrills: Could Managed AJAX Put Your Web Apps in the Fast Lane? RRS feed

  • General discussion

  • Speed is king when it comes to Web sites and Web apps. Now Thomas Hansen says he’s developed a scheme to sharply reduce bandwidth consumption and make it possible for Web apps to be much mire responsive than before.

    Read this article in the October 2017 issue of MSDN Magazine

    Monday, October 2, 2017 6:19 PM
    Owner

All replies

  • You can create also your cloud server with Just few clicks here :

    https://gaiasoul.com/2017/10/02/get-a-private-phosphorus-five-server-for-e49/

    Nice work.

    George Cyprus

    Tuesday, October 3, 2017 4:46 PM
  • If you want to try out a small little app I created with this, you can check it out here - https://samples.gaiasoul.com/harvester

    You'll find its code here - https://github.com/polterguy/harvester

    And it relies upon Camphora Five at its back-end, which you can find here - https://github.com/polterguy/camphora-five

    I've written some about my motives for creating it here, and what purpose it serves - https://gaiasoul.com/2017/10/03/harvest-love-from-your-customers/

    Thx for reading :)

    Thomas

    Tuesday, October 3, 2017 8:17 PM
  • Thomas,

    Saw your name again in MSDN and I really liked the article. I didn't get too far into the HyperLambda, though.  *wink*

    The example worked great and seems very straightforward. I know I can look at the code, but what exactly is the magic that let's this pack so much into 5K? Is this another example of a newer framework simply not having the same bloat that these other frameworks have accumulated? I'm a firm believe in TAANSTAAFL, so what is the trade off on this? Is the server needing to do more work to generate the ultimately-displayed HTML?

    Oh, and when I try to view my default page in split mode, the WYSIWYG pane has some error panes displayed that say, "Oops, make sure you inherit your page from AjaxPage somehow." My page is inherited from "p5.ajax.core.AjaxPage" as your example indicates. Everything builds and runs fine, so not sure what I am doing wrong to not have the designer quite work right... (don't really need the designer, of course, was just wondering why it was displaying that p5 error...).

    Thanks for the nifty and lightweight toolkit!

    Thanks,

    sutekh137

    Friday, October 13, 2017 8:35 PM
  • Thomas,

    Saw your name again in MSDN and I really liked the article. I didn't get too far into the HyperLambda, though.  *wink*

    The example worked great and seems very straightforward. I know I can look at the code, but what exactly is the magic that let's this pack so much into 5K? Is this another example of a newer framework simply not having the same bloat that these other frameworks have accumulated? I'm a firm believe in TAANSTAAFL, so what is the trade off on this? Is the server needing to do more work to generate the ultimately-displayed HTML?

    Oh, and when I try to view my default page in split mode, the WYSIWYG pane has some error panes displayed that say, "Oops, make sure you inherit your page from AjaxPage somehow." My page is inherited from "p5.ajax.core.AjaxPage" as your example indicates. Everything builds and runs fine, so not sure what I am doing wrong to not have the designer quite work right... (don't really need the designer, of course, was just wondering why it was displaying that p5 error...).

    Thanks for the nifty and lightweight toolkit!

    Thanks,

    sutekh137

    Thanks mate :)

    Unfortunately the p5.ajax library doesn't have design time support, since it among other things relies upon the HttpContext to render its controls. I could have created it easily if I wanted to, but to be honest with you, I haven't even prioritised this, since it would create additional code, to accommodate for a feature, which I don't see having any real long time purpose. Besides, although tiny, it would create additional runtime overhead (checking for IsDesignTime, and adding code to the assembly, etc)

    The Ajax library is built around a simple trick, which is the dynamic nature of JavaScript. If you check out the code for the actual JavaScript parts, you will see at line 223 that it "exploits" the subscript operator of JavaScript, allowing me to rely upon the default behaviour of most DOM properties, and then override those with "special needs". Check out its code here - https://github.com/polterguy/phosphorusfive/blob/master/core/p5.ajax/javascript/manager.js#L223

    However, basically, 98% of all DOM attributes, will automatically hit line 240, and only those with special needs, such as "class" and "style", will be handled by their "specific override function". See line 139 in the above code file for instance.

    So as the server returns the JSON after having added the changes back from the server, most of the property setters are handled generically, allowing me to get away with only a handful of actual functions on the client side. This of course, results in a tiny JavaScript library to do the actual mappings on the client side, since it allows me to reference properties and attributes that doesn't exist in my library, but are a part of the DOM specifications. Hence, 98% of all the getters and setters I use, I don't have to create myself.

    Regarding server resources, yes. It does add to the resources consumed on the server side of things, but probably no more than old style ASP.NET WebForms does. It do come with some other disadvantages, such as for instance having to physically remove the state of pages, if the same client requests more than "x" pages, and the Ajax engine should function on all of these pages simultaneously.

    If I hadn't done this, it would mean that a single client could overflow the memory of the server, by utilising a single Session object, and refresh the same page hundreds of thousands of times, resulting in an "out of memory exception" after some 10K-500K refresh operations, with the same session key.

    The main disadvantage of the above, for all practical purposes, is that if you have more than 5 tabs open, sharing the same session key, one of them will stop working, and throw a "Session key invalidated" exception.

    There are trade offs, like always. Anybody telling you they've got a magic bullet, is probably not telling you the (whole) truth. However, I believe firmly that these tradeoffs are worth it, since it makes me possible to literally barf out enterprise apps, at a speed, often 3-5 orders of magnitudes faster, than anything else I've seen out there.

    However, I probably wouldn't have created an app such as StackOverflow with the model, or some other site demanding millions of hits, each second, due to the above reasons. Simply due to the fact that state needs to be conserved on the server for the controls you create.

    In total, analysing the framework as a whole, it arguably hence becomes "the FoxPro for web" ...

    Making it dead simple to create enterprise apps, but impossible to create super-massively, ultra scalable websites, such as Twitter, Facebook or Stack Overflow ...

    Sunday, October 15, 2017 12:41 PM
  • Foxpro for web... You know I like that!  *smile*

    Thanks for the details about some limitations and how the speed increase is achieved. I assumed it was some sort of "passthrough" motif where you just let the native HTML controls do their thing. I think jQuery is cool, but it is a fair amount of complexity that for a lot of its functionality seems to come down to being able to type less as opposed to going through the full DOM property tree. For a lot of what needs doing (like just changing the content), it is overkill.

    And thanks for explaining the design time issue -- just wanted to make sure I didn't have something configured incorrectly. You are right in that you shouldn't prioritize that. I don't think much of anyone depends on that sort of design time capability, especially with more naturally flowing layouts and CSS in play for any "modern" web site.

    The ease with which p5 does things has me looking to get back to some web developing now... Well, when the desktop workload slows down a bit, maybe in 2019 or so...

    Thanks,

    sutekh137

    Monday, October 16, 2017 6:45 PM
  • Foxpro for web... You know I like that!  *smile*

    Thanks for the details about some limitations and how the speed increase is achieved. I assumed it was some sort of "passthrough" motif where you just let the native HTML controls do their thing. I think jQuery is cool, but it is a fair amount of complexity that for a lot of its functionality seems to come down to being able to type less as opposed to going through the full DOM property tree. For a lot of what needs doing (like just changing the content), it is overkill.

    And thanks for explaining the design time issue -- just wanted to make sure I didn't have something configured incorrectly. You are right in that you shouldn't prioritize that. I don't think much of anyone depends on that sort of design time capability, especially with more naturally flowing layouts and CSS in play for any "modern" web site.

    The ease with which p5 does things has me looking to get back to some web developing now... Well, when the desktop workload slows down a bit, maybe in 2019 or so...

    Thanks,

    sutekh137

    FoxPro is underrated. In fact a lot of these 4th generation languages are seriously underrated. I sometimes for the fun of it, refer to Hyperlambda as "5th generation programming language". I remember working with FoxPro back in the early 2000s, and it's impressive what you can do, and how fast you can do it. Once you grow a little older, and realise not everybody can create StackOverflow and Facebook, you start getting more "pragmatic" towards problem solving. In fact, most of the things that have inspired me are supposedly "ancient" technologies.

    * Lisp (1950s)
    * FoxPro (1980s, somewhere)
    * ASP.NET WebForms (2000 somewhere)

    These are all considered ancient and dated technologies, yet still they're among my top inspirations for how I solved the problems I solved. Most projects I have worked with in my life, are enterprise apps and "long tail solutions". P5 solves my problems, and in doing so, hopefully a lot of other people's problems too ... :)

    However, once some of the industry "shakers and movers" look at the technical implementation details of P5, they tend to dismiss it, since it's "not created with MVC", or "not built on top of the CLR 2.0", or "put in your choice of latest technology here" ...

    Lisp was invented in the 1950s, and is still today arguably the best programming language ever invented!

    jQuery had value some 10 years ago, but today a lot of people, including me, would argue that its most important trait is obsolete, since if you're gonna code in JavaScript, you no longer needs the abstraction that jQuery brings to the table. Most browser are very well at conforming towards most ECMA/JS standards today anyways, and hence the main USP of jQuery is simply not relevant anymore. jQuery was created to make it easy to write portable JS. Today writing portable JS is a commodity.

    jQuery creates a beautiful code model for JS, which you hint at, and I agree with - But I can solve most of the things jQuery used to solve, without even creating as much as a single JS line of code today. For instance, most of the animations, are simply done with a few lines of CSS. At which point the price to pay in bandwidth and other client side resources, simply isn't worth it. Besides, it doesn't solve the problem of how to do the mapping on the server, at which point I end up with two codebases, one on the server, and another on the client, which must stay compatible as I create features, inevitably doubling my work. jQuery, by the very definition of the term, makes it impossible to create good cohesion. Sorry, I'll choose P5 any day before jQuery, but then again, that might be just me ... ;)

    Regarding 2019.
    Hehe :)

    Have a nice one :)

    .t

    Tuesday, October 17, 2017 7:50 AM
  • Sorry, I couldn't hold myself, and had to write some words about the main idea behind P5 ... :)

    https://gaiasoul.com/2017/10/17/old-is-the-new-new/

    Is it too much ...? :)

    Tuesday, October 17, 2017 9:07 AM
  • Well, yeah, it is too much, but that's just you.  *smile*

    You might want to include some of the weaknesses in p5 in that expansive blog post (in the same way you were very honest about such shortcomings on this thread). People tend to buy into "miracles" more when you explain the TANSTAAFL trade-offs.

    And why can't I make an input Literal in p5? It says I can't do that... How do I get simple input? Do I just have to code that as normal HTML with more conventional code-behind logic? I am trying to expand upon your simple example and am not getting very far (but I know virtually nothing about coding ASP.NET web forms...).

    I agree with your assessment about jQuery, by the way. In that sense, the time is definitely now for introducing a different paradigm on managing AJAX stuff. But as I said, I am mostly a consumer of web services, etc., not a site builder.

    Thanks,

    sutekh137

    Tuesday, October 17, 2017 1:48 PM
  • Well, yeah, it is too much, but that's just you.  *smile*

    You might want to include some of the weaknesses in p5 in that expansive blog post (in the same way you were very honest about such shortcomings on this thread). People tend to buy into "miracles" more when you explain the TANSTAAFL trade-offs.

    And why can't I make an input Literal in p5? It says I can't do that... How do I get simple input? Do I just have to code that as normal HTML with more conventional code-behind logic? I am trying to expand upon your simple example and am not getting very far (but I know virtually nothing about coding ASP.NET web forms...).

    I agree with your assessment about jQuery, by the way. In that sense, the time is definitely now for introducing a different paradigm on managing AJAX stuff. But as I said, I am mostly a consumer of web services, etc., not a site builder.

    Thanks,

    sutekh137

    Hahahaha :D
    Thx mate :)

    To create an input element, you'll need to use the "void" widget, simply replace "Literal" with "Void", and it'll work. A literal is a control with text content, such as a "p" element, "span" element, "strong" element, or for that matter a "textarea" element. Input elements doesn't have content, and hence you should use a "Void" widget :)

    For the most parts Literal and Containers can be interchanged, implying you can create for instance a "div" as both a Literal and a Container, depending upon if you want it to have children controls or not - But for "input", "br", "hr", and other tags without content, the requirement is to use a "Void" widget ... :)

    Tuesday, October 17, 2017 6:00 PM
  • Thx mate :)

    To create an input element, you'll need to use the "void" widget, simply replace "Literal" with "Void", and it'll work. A literal is a control with text content, such as a "p" element, "span" element, "strong" element, or for that matter a "textarea" element. Input elements doesn't have content, and hence you should use a "Void" widget :)

    For the most parts Literal and Containers can be interchanged, implying you can create for instance a "div" as both a Literal and a Container, depending upon if you want it to have children controls or not - But for "input", "br", "hr", and other tags without content, the requirement is to use a "Void" widget ... :)

    I did see that textarea instantiated properly. And I just switched to use Void and now have everything in the p5 namespace instead of a mix of p5, asp, and "pure" HTML controls (though it is nice how you can mix and match all that...) I have my standard Fibonacci calculator screen built, something I usually do to create first apps in new toolsets.

    I guess I figured since an input can kinda sort have content in it (the "value" property), that I could create on as a Literal. It looks a little funny to me to use the ".innerValue" syntax for the Literal controls while the input field has to use the "["value"]" syntax... Hm, though I guess I could use the square-brackets for everything and be consistent if that was important...

    Thanks again for the follow-up responses and for sharing your code this way!

    Thanks,

    sutekh137

    Tuesday, October 17, 2017 7:07 PM
  • Thx mate :)

    To create an input element, you'll need to use the "void" widget, simply replace "Literal" with "Void", and it'll work. A literal is a control with text content, such as a "p" element, "span" element, "strong" element, or for that matter a "textarea" element. Input elements doesn't have content, and hence you should use a "Void" widget :)

    For the most parts Literal and Containers can be interchanged, implying you can create for instance a "div" as both a Literal and a Container, depending upon if you want it to have children controls or not - But for "input", "br", "hr", and other tags without content, the requirement is to use a "Void" widget ... :)

    I did see that textarea instantiated properly. And I just switched to use Void and now have everything in the p5 namespace instead of a mix of p5, asp, and "pure" HTML controls (though it is nice how you can mix and match all that...) I have my standard Fibonacci calculator screen built, something I usually do to create first apps in new toolsets.

    I guess I figured since an input can kinda sort have content in it (the "value" property), that I could create on as a Literal. It looks a little funny to me to use the ".innerValue" syntax for the Literal controls while the input field has to use the "["value"]" syntax... Hm, though I guess I could use the square-brackets for everything and be consistent if that was important...

    Thanks again for the follow-up responses and for sharing your code this way!

    Thanks,

    sutekh137

    The mismatch between "value" and "innerValue" is unfortunately something that's inherited from HTML. I try to keep everything as close to HTML syntax as possible, and since input elements have a "value" attribute, I feel it's less mismatch if I keep that as is. While the "innerValue" isn't actually an attribute, it's a mapping towards "innerHTML", which is the content between the starting tag and the ending tag, and not an attribute (even though technically you can set it through the subscript operator though). If I regret one thing, it is to use "innerValue" instead of "innerHTML" in fact, but it's kind of too late for changing these parts, since there's simply too much code out there relying upon its existing API. And since the textarea's "value" actually is its "innerHTML", arguably this keeps it closer to HTML, and makes it (I hope) easier to learn for people knowing HTML. However, I think you can actually use "value" for textarea, if you wish (read below).

    I do some few intelligent overrides some places, such as for instance allowing to set the "value" attribute for a "select" HTML dropdown, to keep it similar to how input elements are being used. If you set the "value" for a "select", it'll actually work, as long as there exists an "option" child having the "value" you're trying to set the "select" to. So there are some parts in there, where I try to add additional logic, to make the API more consistent, and hence arguably try to fix inconsistencies inherited from HTML. But I try to keep those to a minimum. If I hadn't done what I did with the "select" element for instance, you'd have to add a "selected" attribute to the "option" element you wanted to have as the "value" of your "select", which of course would require much more code.

    I also add up automatically a "name" attribute, which is another HTML inherited unintuitive feature, unless you explicitly add one yourself. At which point the "name" property automatically becomes the "id" of the control.

    Another place where HTML creates a mismatch, is for checkboxes and radiobuttons. These are "input" elements, but does not have a "value", but rather a "checked" attribute, which makes it confusing. However, if you know HTML, it should make sense, since unfortunately HTML doesn't always make sense ... ;)

    If you wish to use radiobuttons though, just make sure all radiobuttons in the same group have the same "name" attribute, at which point the "name" you supply will be used, instead of the autogenerated one.

    Back in the days of ASP.NET WebForms, the System.Web.UI.Controls classes would add overrides for literally everything, including stuff like "Margin" and "BackgroundColor". These properties would be possible to set with typed classes, such as System.Drawing.Color and Rectangle, etc. However, this created all sorts of problems, such as for instance having people overuse use these properties, instead of using the powers of CSS classes etc. In addition, it would make it difficult to control the end markup, for those wanting to create the markup exactly as they wanted it to be. So I didn't want to fall into that "trap", and hence chose to simply keep as close to HTML as possible, while adding as few "intelligent overrides" as I could. The main difference between p5.ajax and other Ajax libraries, is that you have (literally) 100% perfect control over the end markup, which I think is pretty awesome ...

    However, if you have suggestions for (intelligent) additions and overrides, feel free to come up with them, as long as I can add them without breaking existing code ... :)

    If you're stuck at something, it almost always helps to check out how HTML does it, and simply realise that "innerValue" on Literal widgets equals "innerHTML", while "Controls" on Container widgets is the controls collection, also mapping towards (arguably) "innerHTML", while all "subscript" values maps towards whatever attribute you want to set.

    In fact, the innerValue and Controls attribute on respectively Literal and Container widgets are the only difference between a Literal control, and a Container control - While the Void widget has neither of these.

    I hope this was more clarifying than confusing ...

    (HTML isn't always intuitive, but don't tell anybody I said so ...!! :P )

    Wednesday, October 18, 2017 7:53 AM
  • I agree that HTML is not necessarily intuitive -- it's a markup language, and folks have been intertwining presentation and programming logic since HTML 1.0 (and then more once more dynamic programming became available. I agree with you that CSS is the way to go, to normalize, if you will, the presentation as much as the data and logic.

    I don't think I will have any bright ideas about changes, because I think the way you do it is about as good as it gets. Heck, even in Visual Foxpro there are inconsistencies in how "values" are accessed, and then on top of that, Foxpro has no typing, so what is in the TextBox? A date, a number, or a string? Better check first. A lot of control is left up to the programmer to implement, which is a blessing and a curse.

    In summary, I think what you have developed is pretty clean, and obviously compact. You should reward yourself with a trip to the beach.  *smile*

    Have a good weekend!

    Thanks,

    sutekh137

    Wednesday, October 18, 2017 2:04 PM
  • Basically you reinvented what a library as Anthem.net did a lot of YEARS ago to provide "managed AJAX" to old (and bad) WebForm controls....

    Thursday, October 19, 2017 6:56 AM
  • Basically you reinvented what a library as Anthem.net did a lot of YEARS ago to provide "managed AJAX" to old (and bad) WebForm controls....

    When I first started using Anthem.NET (yes, I am very well aware of it), I loved it. However, Anthem.NET is based upon a construct often referred to as "Partial Rendering", which was re-iterated with "re-rendering triggers" when ASP.NET Ajax was released. It works by partially re-rendering parts of the page, in addition most Ajax libraries built upon partial rendering also suffers from the ViewState problem, further literally exploding bandwidth usage in your apps.

    p5.ajax is not built upon any partial rendering at all. If I have a "textarea" element for instance, with 10KB of text within it. With Antem.NET, simply changing a single attribute on that div, such as the "cols" attribute of a textarea, would require passing down 10KB of data in my Ajax requests, and the entire HTML element would have to be re-rendered, in addition to the ViewState of the page as a whole. With p5.ajax, it would require only sending down the attribute, and leaving its content intact, and there would be no ViewState. Reducing the size from more than 40,000 bytes, to 5-10 bytes - Making p5.ajax in the above scenario 8000 times more optimised on its Ajax requests.

    Implying if you were on a bad connection, and it would require one second to transfer a p5.ajax Ajax request, you could expect it to take more than 2 hours to return the equivalent request through Anthem.NET (or ASP.NET Ajax with triggers re-rendering your element) from your server.

    So from 1 second to more than 2 hours ...

    There are neither any WebControls in p5.ajax, in fact, I have created my own base class called "Widget", which inherits directly from Control, and replaces WebControls. In addition there is no state transferred between the client and the server (no ViewState is ever transferred, making it further ridiculously smaller in size, compared to Anthem.NET). Meaning, you can expect any Ajax request in Anthem.NET to be at least 1000 to sometimes 100,000 times the size, compared to p5.ajax.

    Jason Diamond (the inventor of Anthem.NET) did a brilliant thing with Anthem, and he was a brilliant coder, and it would be historically inaccurate to proclaim that I wasn't inspired from his works - Which was far better than ASP.NET Ajax' model and ideas, BTW - However, p5.ajax is not in any ways similar to Anthem.NET. However, arguably, it was *inspired* by Anthem, the same way it was *inspired* by ASP.NET WebForms. You could argue that p5.ajax is built upon "10% of WebForms", but it inherits so deep, and adds so much of its own logic, that it would be like proclaiming C# is a rip off from Java, since it features similar syntax, and has a garbage collector.

    It is inspired from many other technologies, that are far more dated than ASP.NET WebForms though. For instance, Hyperlambda (arguably), is simply a new syntax for Lisp. Lisp was invented in the 1950s. So if you'd really like to go that road, and proclaim that it's "old technology", you might as well proclaim it to belong to the 1950s, instead of the early 2000s, with WebForms ... ;)

    Besides, I assume what your choice of technology is, probably equates to Microsoft MVC, right ...?

    Microsoft MVC is built upon a design pattern from 1979. It took Microsoft roughly 30 years, and the success of Ruby on Rails, to realise its beauty. Creating your own Model, View, Controller logic for the record, with p5.ajax (using Hyperlambda for instance), is ridiculously easy. However, creating the following with Microsoft MVC, is literally impossible ...

    https://www.youtube.com/watch?v=I5TUykq2nnY

    When that's said, Microsoft MVC has its parts where it's better than p5.ajax, see my points above about Enterprise apps versus Facebook/Twitter type of apps in the above comments, where I even compare Phosphorus to FoxPro, which makes WebForms seem like "recent news".

    p5.ajax is inspired by "ancient and dated technologies", this is not something I have troubles admitting to. In fact, I'd like to bring it further for you, and would like to admit my main inspiration was in fact 5000 years old ... ;)

    https://gaiasoul.com/2017/10/17/old-is-the-new-new/

    Thursday, October 19, 2017 8:52 AM
  • Having an "informed debate" requires we both know what we're talking about. Why don't you check out Phosphorus Five before you make arguments you cannot possibly hold on to ...?
    Thursday, October 19, 2017 8:59 AM
  • When you have done, I would deeply appreciate your feedback, and comments :)
    Thursday, October 19, 2017 9:00 AM
  • Nice article :).

    Looks like GWT (http://www.gwtproject.org/) but for C#. Did you get your inspiration from that Java framework? It might be a little bit early for that but do you plan to do a feature and/or performance analysis with it?

    Thanks!

    Thursday, October 19, 2017 5:58 PM
  • Nice article :).

    Looks like GWT (http://www.gwtproject.org/) but for C#. Did you get your inspiration from that Java framework? It might be a little bit early for that but do you plan to do a feature and/or performance analysis with it?

    Thanks!

    Hehe, GWT was in fact one of few Ajax frameworks which I tend to refer to as "Managed Ajax". Though GWT is built around an entirely different axiom, where they compile ByteCode into JavaScript. Which makes it arguably very much different, since p5.ajax is built around a "static" JavaScript on the client, and rather using the dynamic features of JS, instead of relying on dynamically creating JS. But yes, the comparison definitely works for me ...

    Although, I tend to believe that my approach is superior, for obvious reasons ... ;)

    Thursday, October 19, 2017 8:11 PM
  • BTW, I actually made my first "Managed Ajax framework" back in 2006, at least 1-2 years before GWT. But for reasons which I'd not like to elaborate around in this forum, my first attempt failed (not due to technical reasons though). So arguably, one could ask the question if GWT were inspired from my work, if anything ... :)
    Thursday, October 19, 2017 8:14 PM
  • Well, yeah, it is too much, but that's just you.  *smile*

    You might want to include some of the weaknesses in p5 in that expansive blog post (in the same way you were very honest about such shortcomings on this thread). People tend to buy into "miracles" more when you explain the TANSTAAFL trade-offs.

    And why can't I make an input Literal in p5? It says I can't do that... How do I get simple input? Do I just have to code that as normal HTML with more conventional code-behind logic? I am trying to expand upon your simple example and am not getting very far (but I know virtually nothing about coding ASP.NET web forms...).

    I agree with your assessment about jQuery, by the way. In that sense, the time is definitely now for introducing a different paradigm on managing AJAX stuff. But as I said, I am mostly a consumer of web services, etc., not a site builder.

    Thanks,

    sutekh137

    Better ...? :)

    https://gaiasoul.com/2017/10/22/is-hyperlambda-a-free-lunch/

    Sunday, October 22, 2017 9:15 AM
  • FYI, I have always struggled with explaining the advantages of Hyperlambda, and how it facilitates for having the "computer understand Hyperlambda", and some people have dismissed my ideas as madness - So let me have my computer girlfriend explain it instead :D

    https://gaiasoul.com/2017/10/27/watch-me-discuss-my-code-with-my-computer/

    This little app took me about 2 days to create, my next project is to create a natural language (plain English) interface, for having the computer understand sentences, and create real and working code out of it :D

    Which implies you can say stuff such as:

    You: Create a widget
    Computer: Which type of widget?
    You: A literal widget
    Computer: OK, how do you want to parametrise your widget
    You: With a CSS class named foo, and an element of div
    ...

    Friday, October 27, 2017 9:45 PM
  • What do you think ...? :)

    https://gaiasoul.com/2017/11/06/hyperlanguage-a-human-to-computer-interface-based-upon-natural-language/

    Monday, November 6, 2017 8:29 AM