Earlier quoted context omitted.
Cool, since you are here , is there any flash editor clone? That was the stuff, animations, games, apps, all so intuitive.
Try https://tumult.com/hype/
Looks cool! But I don't own nor plan to own a mac.
A clean start for the web (2020)
151–160 of 200 posts
Re: A clean start for the web (2020)
#152What we need is for HTML to get going as a hypermedia again, to make the hypermedia architecture viable for a larger set of web applications. It's been stalled at anchors and forms (with only GET and POST!) for decades now. It's astounding how much we got built with just that. I'm trying to show where it could go with htmx: https://htmx.org Hypermedia (in particular the uniform interface) is what made the web special…
HTMX is fantastic. Today I built a proof of concept in Django+HTMX+D3.js. Fully reactive, interactive, HTML-first widgets with no npm nor "build" stage. Do anything with good ole HTML templates and just HTMX and D3!
I’d love to see the demo! I’m in the process of building something similar
Re: A clean start for the web (2020)
#153Earlier quoted context omitted.
> My servers should do as little as possible. Why? It’s not like they wear and tear?
One advantage of pushing the computing on the user-side is that it reduces the load on the server: less requests, less processing and smaller request sizes. Thus it reduces the bill for the developers/companies :)
>One advantage of pushing the computing on the user-side is that it reduces the load on the server:
But we don't need complicated frameworks on the server, keeping track of changes in a shadow DOM and updating the real DOM afterwards.
The server will likely just use some html templates in which it will replace some variables with strings and numbers. Easy peasy, both for the server and for the developer.
Re: A clean start for the web (2020)
#154What we need is for HTML to get going as a hypermedia again, to make the hypermedia architecture viable for a larger set of web applications. It's been stalled at anchors and forms (with only GET and POST!) for decades now. It's astounding how much we got built with just that. I'm trying to show where it could go with htmx: https://htmx.org Hypermedia (in particular the uniform interface) is what made the web special…
I've always been shocked that HTML forms only support GET and POST and there's zero interest in supporting more HTTP methods in forms even in 2022. If forms supported the whole range of HTTP methods we could have a user facing web that's identical to a REST API, with different Accept and Content-type headers. Imagine how much development time we could save if forms supported DELETE and PUT!
You know you can update or delete a resource by using GET or POST?
Re: A clean start for the web (2020)
#155One thing I don't get. We use Web for apps because desktop and mobile apps aren't portable. But why don't we use instead Java or .NET apps, which can be portable?
It would also simpler for the app developers who would program against a simpler model than that of web apps.
And we can use the Web to deliver information i.e. documents.
Re: A clean start for the web (2020)
#156What we need is for HTML to get going as a hypermedia again, to make the hypermedia architecture viable for a larger set of web applications. It's been stalled at anchors and forms (with only GET and POST!) for decades now. It's astounding how much we got built with just that. I'm trying to show where it could go with htmx: https://htmx.org Hypermedia (in particular the uniform interface) is what made the web special…
I've always been shocked that HTML forms only support GET and POST and there's zero interest in supporting more HTTP methods in forms even in 2022. If forms supported the whole range of HTTP methods we could have a user facing web that's identical to a REST API, with different Accept and Content-type headers. Imagine how much development time we could save if forms supported DELETE and PUT!
> Imagine how much development time we could save if forms supported DELETE and PUT!
not much; while you need a little (easily reusable) JS code to use and handle responses to other methods, it's such a tiny fraction of the dev effort that goes into web apps that it makes no meaningful difference.
It would be nice if HTML forms supported other methods for completeness, but it wouldn't save all that much real-world development effort.
Re: A clean start for the web (2020)
#157Earlier quoted context omitted.
> SvelteKit/NuxtJS/NextJS are literally reinventing server side rendering for the client to then call the actual server to get data ... to render HTML. It's all done in one call - at least in Svelte. You can even render all this into a fully static site. Meanwhile htmx and the like is the same idea that was popular 15-ish years ago, which died for good reasons.
the reason it, that is the idea of hypermedia, died was because you weren't able to achieve the same level of interactivity as you could with javascript-based applications, even back in 2005 this was due to the fact that HTML stopped advancing as a hypermedia, as I say in my original comment htmx and other libraries are attempting to address that by pushing HTML forward as a hypermedia, which allows you to implement…
>the reason it, that is the idea of hypermedia, died was because you weren't able to achieve the same level of interactivity as you could with javascript-based applications, even back in 2005
But I neither want nor need much interactivity in Web sites. Interactivity is for applications and applications are much better on desktop or mobile than on the Web.
Re: A clean start for the web (2020)
#158One thing I don't get. We use Web for apps because desktop and mobile apps aren't portable. But why don't we use instead Java or .NET apps, which can be portable? It would also simpler for the app developers who would program against a simpler model than that of web apps. And we can use the Web to deliver information i.e. documents.
If you want a web only capable of delivering static documents, you may be interested in Geminispace.
As far as why we use the web for "apps" (which seems to mean any site with any non-trivial interactivity provided by javascript, as opposed to any site emulating the function of a native application, which there are few of,) we do so simply for the reason that the web as a platform already exists, and is ubiquitous, and provides a single development distribution model for text and interactivity, and that is more convenient than forcing text to be in one place and everything else to run in separate application spaces.
Running code on the web was conceived of as a possibility from the beginning, the premise that it was only ever supposed to support static documents, but then got 'corrupted' into supporting "applications," is kind of a modern retrofiction.
Also, the premise that only static documents contain information, whereas applications don't, isn't correct. The vast majority of what are considered "web apps" are, functionally, just dynamic multimedia documents.
For everything else - actual web applications - WASM will probably be the solution.
Re: A clean start for the web (2020)
#159Earlier quoted context omitted.
Why does it have to be so siloed? What if I want documents with a slight bit of inactivity? Why must I go through two different protocols? What if I want to read a paper next to the Juyter notebook that made it? I think it should be the clients job to take whatever slice of a richer universe it wants. This also stops duplication of effort, why maintain separate protocols and clients etc. It’s just a search issue, the…
> What if I want documents with a slight bit of inactivity? Then you use Adobe Flash. See, we used to have a decent technology for when you want "a document with a slight bit of interactivity". It worked very well for this exact purpose. More than 10 years later, browsers' native capabilities, that are supposed to be a replacement for what Flash offered, have still not quite caught up. Moreover, Flash defined a clear…
Why not just use Java and .NET? They have pretty capable VMs which support lots of languages: Java, Python, Clojure, C#, F#, Visual Basic, Python, C++ and others.
Re: A clean start for the web (2020)
#160Earlier quoted context omitted.
Your rant is focused so much on the actual implementation details of Flash that it misses the point that the abstract concept of a VM based application container/sandbox could have been a great thing. In fact, it was such a great idea that browser developers were forced into a pretty tough struggle to actually kill it in order to stay relevant themselves. Adobe's poor stewardship sealed the deal, not conceptual short…
Isn't that what we have? JavaScript is a VM-based sandbox. The difference is that JavaScript has more ready access to the DOM, but Flash was also able to do that, it just used JavaScript as a bridge.
>Isn't that what we have? JavaScript is a VM-based sandbox.
JS is unfit for the task. It is a dynamic scripting language introduced by Netscape for the only purpose of adding a bit of interactivity to web pages, not to create large apps.
.NET and Java are much better for the task. The VMs support better languages with better libraries and more sane ecosystems. And the performance would be much better than that of JS.
And is easier to write an application using Xamarin or MAUI then using React.
When you write Java or .NET apps you write to target a computer which is a much better model for the apps then Web.
With "app languages" you can write apps better, faster while having better performance and more capabilities than using dynamic scripting languages like Javascript, Lua or Python.
Operating systems and browsers are apps too. And we don't use Javascript to write them.
You can write anything in any Turing complete language. But you'll be a fool if you attempt it for anything but fun.