[HN Gopher] Paw is joining Rapid API, Paw for the Web, Windows, ...
___________________________________________________________________
Paw is joining Rapid API, Paw for the Web, Windows, and Linux is
available
Author : blacktulip
Score : 111 points
Date : 2021-02-10 14:22 UTC (8 hours ago)
(HTM) web link (blog.paw.cloud)
(TXT) w3m dump (blog.paw.cloud)
| Nextgrid wrote:
| The only reason I use Paw instead of the countless alternatives
| is _because_ it's not web-based. Sad to see this new development,
| though thankfully I can still hold onto the last native version.
|
| Edit: was looking at the article on my phone and missed the part
| where they claim they'll maintain the native version. However I
| still have concerns they would eventually discontinue it given
| that Rapid API's main business model is around API marketplaces,
| gateways and billing and the revenue from selling tooling is
| likely to be a drop in the bucket in comparison.
| dionian wrote:
| >The only reason I use Paw instead of the countless
| alternatives is because it's not web-based.
|
| Same.
| folkrav wrote:
| > While we'll keep building the native macOS application as a
| first-class citizen, we're introducing today Paw for the Web,
| Paw for Windows and Paw for Linux!
|
| Straight from their announcement.
| dewey wrote:
| That would be great but I have a hard time believing it'll
| stay like that. Maintaining two code bases instead of making
| the "native macOS application" a Electron wrapper around
| their other code base doesn't seem scalable in the long run.
| folkrav wrote:
| That's moving the goalposts. The concern was for the native
| UI to get abandoned, it isn't. It may, or may not. The
| existence of the cross-platform version is hardly an
| indicator. If anything, having only the macOS version
| limited their reach and future expansion.
| dewey wrote:
| Not necessarily. The concern was "because it's not web-
| based", which could mean that they don't like the web UI
| or the web based technology stack behind it.
|
| For me a native app has to both look and feel native. An
| app that looks like a native app (Like an Electron app
| can) isn't fully native for me because it still runs a
| web browser under the hood.
| folkrav wrote:
| I dislike Electron as much as the next guy, but that
| description of what's "native" is IMHO quite arbitrary.
| Anything using a cross-platform UI toolkit doesn't fit
| that description, e.g. Qt apps definitely don't look like
| they are native outside KDE, GTK outside GTK based
| DEs/WMs, Java apps don't look native anywhere, nor does
| Tk, etc. while an Electron app that used native-like UI
| elements could.
| realityking wrote:
| I think on macOS the definition of native is most often
| "Cocoa" and not the absence of web technologies.
| Wowfunhappy wrote:
| It's a spectrum. My hierarchy for Mac apps goes something
| like: Cocoa > Java > QT >>> Marzipan > Electron.
|
| On old OS's, Carbon would be between Cocoa and Java. And
| individual apps can vary a bit. But Electron apps
| generally feel less foreign than QT apps, which at least
| makes some attempt to use native Mac elements.
| rhencke wrote:
| I think that's exactly what 'keep[ing] building the
| native macOS application as a first-class citizen' means.
| coldtea wrote:
| Sounds like every announcement of "nothing will change" of
| any recently acquired company, before the product is shut
| down and tranformed to something completely different...
| folkrav wrote:
| Again, this is extrapolation. Until they do it, they
| didn't.
| [deleted]
| Cthulhu_ wrote:
| Same, although an additional reason is that it stores the
| requests as a plain file that can be yote into version control,
| instead of an awkward file import / export or (what this
| version seems to do, as well as Postman) push you to a
| subscription just to share files.
|
| I'm afraid I'll be sticking to .http files or swagger-ui for
| now.
| donatj wrote:
| I would argue the UI is a vast improvement over Postman.
| dionian wrote:
| I forked over like 50$ or something for this reason alone.
| blacktulip wrote:
| The development of native version will continue, according to
| the article.
| haskellandchill wrote:
| I've recently been using Optic (https://useoptic.com/) which does
| some cool things in the API tools space, there's potential there
| to have a CLI UI and they have the history part already but
| similar to what people are saying here about the web UIs, I don't
| like theirs much.
| atarian wrote:
| Isn't Rapid API owned by Kong, which also owns Insomnia?
| johns wrote:
| Rapid API bought Kong's marketplace and Kong now focuses on
| their API management product. They are separate companies.
| AlexandrB wrote:
| I only recently found out about Paw and was very impressed with
| its svelte 12MB size and responsive UI. Hope they manage to
| maintain that experience in the cross-platform versions.
| cepp wrote:
| Is it just me or is there no way to import prior `.paw` files to
| the new UI? I've looked in both the web and Linux version (both
| the same) to no avail.
| 015a wrote:
| I feel like this is a positive for Paw. While I dislike the
| electronification of everything, I will admit that MacOS is
| roughly the only desktop operating system with a native UI
| framework where I prefer applications be written in it; native
| Windows apps are almost universally horrible, and native Linux
| (GTK?) apps can be pretty good, but generally aren't (which may
| be less due to GTK/KDE and more due to the lack of investment on
| the developer, but the product is the same).
|
| Paw has been a dead project for about three years now. Just as
| one example, the community has been begging for some kind of
| structured GraphQL support in the entire timeframe GraphQL went
| from a "new thing" (when its reasonable to wait and see) to today
| when its everywhere (when its now insane that an API prototyping
| client wouldn't have first-class support). They keep it working
| and going, looks like M1 support came out today as well, but
| feature-wise its far from a "done" product, yet the developers
| have treated it like one.
|
| Hopefully this acquisition helps funnel resources into actually
| building it out rather than letting it languish while still
| collecting those $50 purchase fees.
| ericlewis wrote:
| M1 support coming out is great! I have been fighting with it
| after starting a new job last week.
| jacurtis wrote:
| > the community has been begging for some kind of structured
| GraphQL support
|
| They added GraphQL support a few weeks ago:
| https://blog.paw.cloud/paw-3-2-graphql-macos-big-sur/
|
| I didn't know about the M1 support. Funny enough I looked
| yesterday randomly when I noticed that Paw was still running
| under Rosetta. And I saw no word about M1 support yet. I
| wondered how long it would take. I guess I just needed to wait
| 12 hours. Glad to see M1 support today.
| newmac wrote:
| Has anyone used the parent company's product (RapidAPI)? It seems
| like a proxy in front of APIs, most of which aren't actually
| integrated and need to be configured separately. I feel like I am
| missing something.
|
| I hope Paw doesn't end up as poorly designed as this.
| jmann99999 wrote:
| I absolutely love Paw. It rapidly allows me both to test APIs
| and, more importantly sometimes, create examples for specs. The
| ability for me to mock up the output one of our in-development
| APIs in JSON is amazing.
|
| I wish it had some of the scripting of Postman, but that may take
| away from its simplicity.
| maxnoe wrote:
| Not to be confused with
| https://en.m.wikipedia.org/wiki/Physics_Analysis_Workstation
| agloeregrets wrote:
| I spent years at war with others at the company I work with
| keeping my own copy of paw test APIs up to date while many others
| used other tools for testing. Paw was just so incredibly killer,
| notably in the 'make one api call inform another' space. Using
| Paw always felt like I was almost a developer building my test
| cases rather than a person using an app. It was pricy, but damn.
| Good on you people, congrats.
| wildermuthn wrote:
| I absolutely loved Paw.
|
| Before GraphQL, Paw was a necessary and often daily part of my FE
| team's toolset. Since GraphQL and tools like Graphiql, I haven't
| found myself using Paw. Its killer-feature for me was chaining
| together long sequences of REST requests that dynamically
| depended upon one another's results.
|
| I'm curious if others are using Paw in a GraphQL context?
| greenpizza13 wrote:
| I use Paw for GraphQL every day, including variables, schemas,
| and docs. The autocomplete works well enough, and when plugging
| into the larger Paw project things work very well.
|
| My only big gripe is I can't write JSON to modify variables, I
| have to interact with a JSON tree UI and add items one at a
| time.
| ccakes wrote:
| 3.2 added some rudimentary GraphQL support but it's not
| comparable to Insomnia so I went back to that
|
| Just loading it now and there's an update (3.2.1) - it mentions
| some GQL documentation improvements in the change log but
| unsure if it's tangibly better
| kall wrote:
| The GQL features have nothing on GraphiQL+Explorer. Depending
| on how much you value the native UI, dynamic features etc it
| may still be worth it. It is for me, but I use it alongside
| GraphiQL all the time.
| atonse wrote:
| I've used Postman since it was one dude working on it, and have
| probably created 100+ collections but now I'm about to abandon it
| since it's getting way too complicated for my use.
|
| It took me almost 10 minutes to just copy an environment
| yesterday. It was very frustrating to be totally lost in the UI
| after using Postman for nearly 7 years.
| steve_adams_86 wrote:
| We moved to Paw from Postman specifically because it has less
| (but higher quality) features. Postman is a mess of a UI, in my
| opinion. It's so much work to do very trivial things (like copy
| an environment). We had the feeling that it's hardly a
| productive solution, but almost makes work in and of itself.
| pkulak wrote:
| I've bounced around from Postman, to Paw, to Insomnia, and back
| again for years. I finally dumped a bunch of HTTPie scripts in a
| folder, made a small runner script in my path, and added
| autocomplete hooks that just read the filesystem structure.
|
| Now I can run anything from any terminal with history searching.
| Plus, it's all committed to a repo for anyone else in my org to
| look at and/or contribute too. I know other tools have
| collaboration, but can you beat text files + git that you can
| link to from Slack?
|
| Need to pull an ID out of the third item? Just pipe it to gron
| and grep. Watch for changes? Put "watch" in front of it. Need to
| chain three things together? Write a short glue script. It's
| wonderful.
| e12e wrote:
| Interesting. I never really got Postman - always felt like it
| was worse than Swagger (when available) and more convoluted
| than curl. I do use SoapUI a bit; mostly for SOAP services,
| occasionally for REST services.
|
| But I recently found[1] a rust reimplentation of httpie, and
| some early testing indicates it might be better than curl+jq -
| bit early to tell.
|
| [1] https://news.ycombinator.com/item?id=26042463
| anamexis wrote:
| That sounds really nice. Any chance you could share the runner
| script and other glue you use?
|
| Right now I'm mostly using restclient.el[1] which I like, but
| it's not quite as universally sharable as it could be.
|
| [1] https://github.com/pashky/restclient.el
| pkulak wrote:
| Yeah, it was actually a good day of work to get stood up,
| mostly around writing a bash script to get and refresh an
| oauth token (I never use Bash for anything...). I'll see
| about generalizing and sanitizing it and posting it
| somewhere.
| unhammer wrote:
| Well, you have `M-x restclient-copy-curl-command` (`C-c C-u`
| by default) to share a single command.
|
| There is also Verb mode (org-mode extension) which seems like
| a nice alternative to restclient.el. Learnt about via
| Impostman[2] which imports Postman collections to both
| restclient.el and verb.el
|
| [1] https://github.com/federicotdn/verb
|
| [2] https://github.com/flashcode/impostman/
| wdb wrote:
| I am worried if this will change the user experience of Paw for
| the Mac. I really appreciated it over Postman but the blo g post
| makes it sound like it will become a second Postman
| jacurtis wrote:
| Yeah this is always my fear too. I hope it doesn't become the
| next Postman.
|
| Paw had that feel like it was made by Panic. It was a Mac app
| that was built with love, funded by a handful of dedicated
| users who love the app too and want to support the developer.
| The developer was building it out of passion. They know they
| aren't going to be on everyone's computers, but the computers
| they were installed on will have users that love the app above
| all else. Passion over download numbers.
|
| Now it feels like Paw is going to go the route where they get
| as many users as possible, across as many Operating Systems.
| Individual user care is sacrificed in favor of mass adoption.
| Let's build a web version, lets build a version that your
| Grandma can use, why not a Kindle version while we are at it?
| Forget new features, let's build a better marketing site and
| start making commercials. I hear the superbowl is starting to
| sell commercials for next year, let's get in on that.
___________________________________________________________________
(page generated 2021-02-10 23:01 UTC)