Earlier quoted context omitted.
https://shibukawa.github.io/curl_as_dsl/
So many languages supported, but no plain C?
As someone else mentioned, this is actually built into Curl with the "--libcurl file.c" option.
Curl, 17 years old today
81–90 of 100 posts
Re: Curl, 17 years old today
#82Earlier quoted context omitted.
On a serious note, “progressive enhancement – still the right way”. I don't think client-side rendering is going away but everyone who's relied on it exclusively has learned the hard way that it's just too unreliable and slow to have a failure mode which is an empty page unless a lot of complex code works perfectly. Just think about how many engineer-hours Twitter flushed with that silly #! kludge – and then when the…
> Just think about how many engineer-hours Twitter flushed with that silly #! kludge – and then when they switched back, saw an 80% improvement in page load time. No hours were wasted, and they didn't really switch back. They're just using HTML5's History API on browsers that support it now. Essentially the same mechanism under the hood, just prettier URLs for it.
I think he was making reference to the DOM rendering in the twitter website which used to be on client side until recently when they have switched back to server side rendering. But, it's very similar to pre-rendering React components on the server then mounting it so it might not be a total waste, that was a fad that didn't make a lot of sense for the time though.
Re: Curl, 17 years old today
#83I love curl so much. I just learned that you can 'copy to curl command' from the chrome inspector's network panel by right clicking on any request!! I want to make a library that reads the curl command (and maybe request syntax?) and outputs a function that will do that command.
Wow—that's incredibly useful. I didn't know about it either. Thanks for the tip!
Re: Curl, 17 years old today
#84Earlier quoted context omitted.
Anything that requires JavaScript to fetch and display content.
Yeah, building web apps this way is a fad. I predict everyone will go back to full page reloads and server-rendered content. /s
Your server should just be providing data that's displayed by the JS App. The JS app can handle a bunch of requests, but each request should provide something useful and be accessible from curl.
bonus, it makes it easier to write your app in other languages or for other platforms since the web server really is a server and the front-end is just a client.
Re: Curl, 17 years old today
#85Earlier quoted context omitted.
Yeah, building web apps this way is a fad. I predict everyone will go back to full page reloads and server-rendered content. /s
On a serious note, “progressive enhancement – still the right way”. I don't think client-side rendering is going away but everyone who's relied on it exclusively has learned the hard way that it's just too unreliable and slow to have a failure mode which is an empty page unless a lot of complex code works perfectly. Just think about how many engineer-hours Twitter flushed with that silly #! kludge – and then when the…
>but everyone who's relied on it exclusively has learned the hard way that it's just too unreliable and slow to have a failure mode which is an empty page unless a lot of complex code works perfectly.
FUD. I develop HTML5 gambling for a living and this anti-javascript sentiment on HN is getting really tiresome. You honestly sound like a bunch of old people, complaining that a PC isn't a typewriter or a fountain pen.
Yeah your fountain pen doesn't require power and it writes your name really well, but that doesn't mean that the PC isn't better.
Client side rendering means you will have to test in all browsers, writing android apps means you have to test on a lot of units.
Re: Curl, 17 years old today
#86Earlier quoted context omitted.
Anything that requires JavaScript to fetch and display content.
Yeah, building web apps this way is a fad. I predict everyone will go back to full page reloads and server-rendered content. /s
I really wish building single-page apps was better supported by browsers. The current setup is to try to kludge over the fact that DOM is for documents, not apps, and use the awfulness that is CSS and current layout paradigms (note, no CSS is strictly worse than yes CSS, but that doesn't make CSS good).
Breaking away from the DOM but keeping the ability to remotely load code and static assets would be the best of both worlds. Something like Google Maps is an application, not a document. Why are we rendering it with a document renderer? Why are we styling it with CSS, which is again, document-oriented? The good part about single page apps is that they deliver a package of code, then are able to keep local state and communicate with the server over a stateless protocol. Oh, and the current breed runs on a platform (browsers) that is installed on every PC and mobile device. Browsers just need a better format for delivering packages of code and better support for these than "manipulate the DOM".
Re: Curl, 17 years old today
#87I donated!
Re: Curl, 17 years old today
#88Earlier quoted context omitted.
I would figure that by 1997 most people stopped using gopher/archive/veronica. I think I stopped by 1995 or so. now days we use curl/wget for web dev it seems? probably used it for the same thing back then but I also image that lots of people just used their own ad-hoc scripts or whatever; i wish i had firsthand knowledge of that. i used wget to download copies of websites when i found one that was mostly documents/i…
I use wget for plain, old regular downloads a lot. If I need to save a file to a specific place (e.g. datasheets to a doc/ directory in my project) and I have a terminal already open there (which I usually do), doing wget and middle-click is far more convenient than dealing with the browsers' "Save to..." dialog. Especially ever since they started considering a sane download manager to be one of those confusing featu…
> I use wget for plain, old regular downloads a lot.
I loved wget for that. what are your options? Mine was always -r -p -k -nH --cut-dirs=2 -np
Re: Curl, 17 years old today
#89Earlier quoted context omitted.
On a serious note, “progressive enhancement – still the right way”. I don't think client-side rendering is going away but everyone who's relied on it exclusively has learned the hard way that it's just too unreliable and slow to have a failure mode which is an empty page unless a lot of complex code works perfectly. Just think about how many engineer-hours Twitter flushed with that silly #! kludge – and then when the…
> Just think about how many engineer-hours Twitter flushed with that silly #! kludge – and then when they switched back, saw an 80% improvement in page load time. No hours were wasted, and they didn't really switch back. They're just using HTML5's History API on browsers that support it now. Essentially the same mechanism under the hood, just prettier URLs for it.
They did more than just switch to the history API. During that period, if anything went wrong, you saw a blank page and, of course, robots saw only the generic launcher HTML instead of any content.
Now, here's what a tweet looks like without JavaScript enabled:
https://www.dropbox.com/s/me7kinvje7ly781/Screenshot%202015-...
Here's what it looks with JavaScript enabled:
https://www.dropbox.com/s/04pjdlkuht6t2ja/Screenshot%202015-...
(The main difference would be that things like the search & menus are either interactive controls or simple links to basic HTML forms depending whether JavaScript loads)
During the hashbang era you couldn't use a page without a full rendering ending. Now, however, all of the content is available with fairly rich markup:
https://redbot.org/?uri=https%3A%2F%2Ftwitter.com%2Facdha%2F...
Re: Curl, 17 years old today
#90I'm surprised it's so new. And wget is only a year older... what did people use before then?
I used netcat - and still do for interacting with protocols in ways that curl doesn't support. AFAIK it was released in 1995, so it's only three years older than curl.