Python Requests: HTTP for Humans - <AUTHOR> http://python-requests.org/ Requests is an ISC Licensed HTTP library, written in Python, for human beings.<p>Requests allow you to send HEAD, GET, POST, PUT, PATCH, and DELETE HTTP requests. You can add headers, form data, multipart files, and parameters with simple Python dictionaries, and access the response data in the same way. It's powered by urllib2, but it does all the hard work and crazy hacks for you. <comment> old-gregg Absolutely my favourite recent development in the Python world. I won't be mistaken if I say that many of us have built half-arse versions of this on top of urllib(2) multiple times in the past. :-)

The support for keep-alive is particularly welcome, huge kudos to the author.

Question to users of other languages: do equivalents exist for PHP, Perl, C# or Java? Ruby folks rave about restclient, but is there anything else?

<comment><USER3> For Ruby there's httparty, <https://github.com/jnunemaker/httparty>, curb, and a couple of others that escape me right now.

<comment><USER4> Here's the new one I'm working on:

<https://github.com/tarcieri/http>

httparty does a few of the same tricks, but I still find its API a bit obtrusive. At least it automatically parses JSON! (my library does this too, if an appropriate library is loaded)

In addition to a humane interface, it will soon be backed by a Ragel-generated HTTP parser:

<https://github.com/tarcieri/http/tree/master/parser>

<comment><USER5> Looks very promising. I see it currently uses Net::HTTP under the hood - <USER2> you plan to keep it that way, like Httparty and Faraday, or are you going to do away with Net::HTTP altogether? (The comment saying "this is temporary" next to requiring 'net/https' is encouraging... :))

<comment><USER4> I plan on eliminating Net::HTTP entirely and writing my own client using Carl Lerche's parser for his Picard library which is written in Ragel:

<https://github.com/tarcieri/http/tree/master/parser>

</comment></comment></comment></comment></comment><comment><USER6> Discussion from the two month old submission: <http://news.ycombinator.com/item?id=2882301>

</comment><comment><USER7> This looks so nice. Is there any upcoming support for HTTP caching? I know it is not the easiest thing to do because you will probably need to make several cache backends (file, db, memcached, redis, etc.) to keep everyone happy.

Also I couldn't tell if there is keep-alive support, is there?

<comment><USER8> Keep-alive is 100% supported in the upcoming v0.7.0 release, along with async i/o :)

Caching: I think that will be best be served by a hook/helper module, but we'll see.

<comment><USER9> Cool! Is there anything I can look at to see how async I/O will work? Does all the async support depend on gevent monkey patching (as requests/async.py would suggest)?

<comment><USER8> It's unreleased, and therefore completely undocumented at the moment. But here's the API: <https://github.com/kennethreitz/requests/issues/98>

<comment><USER10> Mmm async.

Does that also mean that it will have better support for timeouts? I'm not interested in socket timeouts, more in a 'finish this in N seconds or just give up' thing.

For that reason I am using pycurl now for some stuff where I had previously used the requests library. Which has a really really horrible API :-/

</comment></comment></comment></comment></comment><comment><USER11> What is the timeline for v0.7? Desperately need the asynchronous stuff!

<comment><USER8> As soon as I can push it out. Aiming for Friday (if not sooner)!

<comment><USER11> That is great news! I really appreciate your work, thanks!

</comment></comment></comment><comment><USER4> I just started working on a similar library for Ruby:

<https://github.com/tarcieri/http>

</comment><comment><USER12> Looks like Python got something similar to Perl's LWP <https://metacpan.org/module/LWP>

<comment><USER13> I think LWP is more equivalent to Python's urllib2 (ie. both big beasts!). So this i believe is closer to what LWP::UserAgent (<https://metacpan.org/module/LWP::UserAgent>) does.

Also check out Mojo::UserAgent (<https://metacpan.org/module/Mojo::UserAgent>) for a nice(er) alternative. And don't forget that Perl now comes a nice lightweight alternative as standard: <https://metacpan.org/module/HTTP::Tiny>

<comment><USER12> Yes gp, LWP::UserAgent specifically. Never knew about HTTP::Tiny thanks.. I'll check it out.

</comment></comment></comment><comment><USER14> I don't mean to badmouth Requests or Python in general, it certainly looks like an improvement, but can anyone enlighten me as to why an API that wraps an HTTP request with concise methods is #1 on HN, twice? This looks more like a good answer to SO question than "news".

This looks like all the other wrapper methods you spend 5 minutes doing, once, when you start a new codebase?

<comment><USER15> The philosophy of Python is that those wrapper methods shouldn't be necessary.

I'm glad when language quirks and libraries get linked, it's good for discussion. (And more informative than a good third of the stuff that gets linked.)

<comment><USER16> I came here with the same question. Considering I come from PHP & JavaScript where the native APIs are awful, wrapping is a necessary step for sanity. Interesting that Python didn't have this until now.

<comment><USER15> Python has always had it to some degree, but merging these sorts of things into the core language is what major releases are for. No language is perfect. I think the reason you see this upvoted so much is there are so many Python programmers who want to see this on the roadmap for future versions of Python (and it probably will be.)

</comment></comment></comment></comment><comment><USER17> Link to previous discussion on HN:

<http://news.ycombinator.com/item?id=2882301>

</comment><comment><USER18> Unfortunately, no Python 3 support

<comment><USER19> Why is that unfortunate? Why would anyone run python > 2.7?

<comment><USER20> Do you have a good reason why they shouldn't?

Apparently 113,798 people found a reason to download the 3.2.2 Windows installers (32 and 64 bit) from python.org through only the first 10 days of the month of October. <http://www.python.org/webstats/usage_201110.html>

(doesn't include mention of the 3.2 source tarball downloads, which are under 5,000, most likely since people get that from their distro anyway)

</comment></comment></comment><comment><USER21> Finally, an easy way to make POST requests from Python

</comment><comment><USER22> Forgive me if I've missed this, but does this library have support for multipart/form-data POSTing? That's a capability in the python library that's sorely missing - especially in 2.X.

<comment><USER23> yes, it does

</comment></comment><comment><USER24> I'm using it in a project I'm working on. It's really easy to use!

</comment><comment><USER25> Although Requests looks very nice, I've wondered why most people wouldn't simply use pycurl - <http://pycurl.sourceforge.net/> ? It's stable and you get all the power that cURL has (which is a lot), and the API is fairly simple - although maybe not as pythonic as the Requests API is.

On a side note: last time I checked urllib2 (which actually drives Requests) could not do SSL requests over a proxy, which gave me the feeling that this implementation still isn't very mature.

<comment><USER8> I'm moving off of urllib2 as we speak, to sit directly on top of httplib.

One thing at a time :)

</comment></comment><comment><USER26> I love Requests, but it would be really nice to have some Python libraries with cert-verified SSL support. I've hacked SSL support on top of urllib2 for my projects at work (<https://github.com/josephturnerjr/urllib2.VerifiedHTTPS>), but it'd be really nice if libraries started prioritizing secure communications as a first-order requirement.

<comment><USER8> This will be in requests _very_ soon. :)

<comment><USER26> Then I will be porting my projects over to Requests very soon :)

It's pretty easy to implement, as it already works at the lower (socket) level with the ssl module, it just hasn't made it up the stack into urllib2 (or Requests..yet!).

</comment></comment></comment><comment><USER27> I note that you call gevent.monkey.patch_all() in async.

I'm still fairly new to gevent and I'm curious if others consider this good style for a library?

<comment><USER28> If you're using Twisted (or Tornado, ugh) then there are builtin HTTP clients which are async in all the right ways and provide similar high-level APIs for making requests. If you're using gevent, then this is what you want. If you're using eventlet, you should switch to gevent or learn Twisted.

So yeah, this is suboptimal, but not the worst thing in the world. It should really be documented though.

</comment></comment><comment><USER29> Trying to use the requests module yields:

      File "/usr/lib/python2.6/cookielib.py", line 38, in <module>
        from calendar import timegm

ImportError: cannot import name timegm

for me.

On two different machines, one OSX SL with Python 2.6 from MacPorts and the other Ubuntu 10.04.3 LTS with Python 2.6 via aptitude.

Can not find any solution for this via Google and its siblings.

I'm stuck :(

-jsl

</comment><comment><USER30> I love this API, and it looks like the dev version is getting even better. r.iter_content is exactly what I needed! :D

</comment><comment><USER31> Excellent library but they need to fix this piece of misinformation: "A project that is released as GPL cannot be used in any commercial product without the product itself also being offered as open source."

This is false. A project released as GPL can also be released on another (commercial) license.

<comment><USER8> Yes, it has to also be offered as open source.

</comment></comment><comment><USER32> If Python is going to include urllib or urllib2 in the standard distro, why not make it good? Http is foundational to (web) programming. I am shocked at how poor the standard httpclient implementations are in most environments.

</comment><comment><USER33> Oh, what I would give for a "mechanize for humans" built on this! I love mechanize, but I dream of not having to go back to its one page documentation and the source code every time I want to do something.

</comment><comment><USER34> There is also an addon for Requests that lets you make OAuth requests: <https://github.com/maraujop/requests-oauth-hook>

</comment><comment><USER35> How does this compare (feature wise) to the poster library? Are they about the same? I've used poster some, but not requests... I'll have to try it now. Just curious how it compares to poster.

<comment><USER8> The current stable release actually has poster inside (and has for a while), but it's being taken out soon.

</comment></comment><comment><USER36> Given that there are a great deal of service APIs in the wild this is going to lower the barrier of entry for many less experienced developers looking to prototype their ideas.

</comment><comment><USER37> What's with the "for human beings" phrase? Is that a way of saying the software is easy?

<comment><USER38> Some APIs are appropriate for programmers to target. Others are more appropriate for compilers or higher-abstraction libraries to target.

</comment></comment><comment><USER39> It would be nice with something similar for Twisted.</comment>


Say no to Electron: use JavaFX to write a fast, responsive desktop app - <AUTHOR> https://sites.google.com/a/athaydes.com/renato-athaydes/posts/saynotoelectronusingjavafxtowriteafastresponsivedesktopapplication <comment><USER2> Don't say no to Electron just yet. And if you do, jesus, there's better alternatives than JavaFX (use Qt).

You know what Electron has brought us? It's brought the Linux desktop reliable feature parity with other platforms. Fat chance Visual Studio Code (often hailed as "one of the best-optimized electron apps") would have existed on Linux without Electron.

Discord, another fantastic Electron app, is functionally identical on web and desktop (all platforms), feels fantastic on Linux, no issues at all. What are the odds I would have a functional Text/Voice/Video chat Linux desktop client for Discord if Electron didn't exist? How much time would have had to be spent reverse-engineering the protocol then implementing a decent UI for it all?

Obviously you shouldn't use Electron for certain things. If your app is tiny especially, you'll be better served with a leaner framework. But that's nothing new.

Electron has given desktop developers access to the web's fantastic tooling and iteration speed, and web developers access to the desktop market. It's given the ability and incentives to all those developers who might not have touched Linux before to make a Linux release alongside the rest.

If you don't like how Electron performs, your time would be better spent optimizing it than seeking out Java frameworks, which work atrociously bad on anything that isn't the author's platform (if even that).

<comment><USER3> > And if you do, jesus, there's better alternatives than JavaFX (use Qt).

Because "god forbid" anyone use technologies associated with java? FUD at its finest.

> Fat chance Visual Studio Code (often hailed as "one of the best-optimized > electron apps") would have existed on Linux without Electron.

I just use IntelliJ IDEA. It's ten times faster and ten times more powerful than Visual Studio Code. And it's written with java swing.

<comment><USER4> As someone who spends all day in IntelliJ there's no way it's 10x as fast, hell for me it's flipped the other direction.

VSCode is easily 10x faster than IntelliJ. If I'm writing Java I'll happily use IntelliJ but anything else it's VSCode or vim.

<comment><USER5> I use Eclipse with its native SWT UI and VSCode still blows it away in UI speed.

Actually, if Mozilla's Servo tech gets integrated into something like Electron, then we will have some serious performance capabilities surpassing pretty much anything else comparable.

<comment><USER6> I believe the VSCode team is indeed looking into using webassembly.

</comment></comment></comment></comment></comment><comment><USER7> "you can distribute it to any user on any OS and it will just work."

I had to check the date on this article to see if it was from 2007 or something. Under no circumstances does java "just work", its an insane mess of java shipped with the os, being updated, and people not updating due to oracle trying to force feed crapware as part of their installers/updaters. I, for one, do not live in a world that resembles anything like java jars "just working".

<comment><USER8> It does just work, at least compared to web apps. I have experience of both web dev and distributing a somewhat complex JavaFX app to consumers. I bundled the JRE with my app so the users did not need to have Java installed.

The leaks in the operating system abstraction Java gives you are really quite small. I wrote my entire app on macOS and tested on Linux/Windows only right at the end - after about 8 months of full time dev work I spent about a day addressing platform specific issues. That's pretty good.

Now compare that to the mess that web browsers were and still are. It's better than it once was, but you're going to have to check every single feature of HTML5 you use to figure out which browsers implement it, which don't, which use vendor prefixes still, which only half implement it, which don't but can be shimmed using big blobs of JavaScript and so on. The web absolutely doesn't "just work": you will spend more far time working around browser specific issues than you will spend dealing with OS specific issues in Java.

<comment><USER9> > I bundled the JRE with my app so the users did not need to have Java > installed.

Side note here: do you track security vulnerabilities of the shipped JRE and provide updates when it happens?

Too often, I've seen java applications shipping obsolete and vulnerable JRE. And in some cases, I've seen not consistent versions across a product line.

Also wasn't there some unknowns about the right to redistribute the Oracle JRE?

<comment><USER8> I do track those. I didn't need to update my app at any point for them because most vulnerabilities in the JRE are to do with sandbox escapes and my app did not run potentially malicious code.

</comment></comment></comment></comment><comment><USER10> > This is not as much a result of the superiority of the web stack for > building applications (far from that, I don't think anyone disagrees that > the web is a mess), as a failure of the current desktop UI frameworks. If > people are preferring to ship a full web browser with their apps just so > they can use great tools such as JavaScript (sarcasm) to build them, > something must have gone terribly wrong.

This article so thoroughly misses the point of Electron. Furthermore the author's snark and condescension just serve to antagonize and attack rather than making any semblance of a point.

People choose Electron because it's easy to work with for people who are already comfortable with JavaScript. JS devs get to use tools like React, TypeScript, Webpack, Babel, and other tools they already understand and like. You have the entire wealth of tools of npm at your disposal. And since it's JS, you can share code between Electron, your website, and your Node server.

In addition to that, HTML, CSS, and JavaScript writing UIs is something thousands of us do every day do for a living. Being able to do that for a desktop application unlocked a whole world of development that previously was closed to only those comfortable with Objective C, C++, Java, and the like.

The author does a woefully inadequate job of explaining that choosing Electron is a _tradeoff_. You're trading a larger memory footprint, bigger artifact to distribute, and some extra performance challenges for the ability to write your application like a website in CSS, HTML and JS and have it work on every OS that Electron supports. For many this tradeoff is unacceptable but it's either incompetence or idiocy to not see that this tradeoff works for many of us.

<comment><USER11> But the article demonstrates that with JavaFX, you can have FXML + CSS + JavaScript. Isn't that close enough that a web developer could be comfortable pretty quickly? You're just working with a differently flavored DOM, right?

I am not a web developer, so I may be way off base.

</comment></comment><comment><USER12> I wrote an IDE using JavaFX: [https://sekao.net/nightcode/](https://sekao.net/nightcode/) My experiences have been mostly great. As the author mentioned, the JDK comes with a nifty tool called javapackager that will generate a dmg, exe, deb, and other formats with the JRE built in. If you really do want to embed web content, it includes a WebView widget which is a fully-functional browser capable of loading local or remote content, and it even lets you communicate between the JVM and JS side using a little bridge object. So you get the benefits of both the JVM and JS ecosystem. This was particularly nice for me because I could write the some of the IDE in Clojure, and some of it in ClojureScript, and they can call each other's functions arbitrarily. Amazing stuff.

<comment><USER13> what kind of memory and performance footprint does the webview imply? is it similar to using electron, to some extent?

</comment></comment><comment><USER14> > That's a world of difference from an Electron app, which typically needs > 200MB just to open.

This is sort of an unfair comparison - the JavaFX one is mainly smaller because it doesn't include the distribution of Java and all the libraries, which is if I recall correctly about 200 MB, while Electron commonly includes all libraries and the renderer. I will give you that the Java distribution can at least be shared by many applications, but you can definitely get into some nasty versioning situations with that.

On the other hand, if you were to compare this with say a Qt application, it'd be about ~20MB all in, ~10MB if UPX'd, no external dependencies needed. Or just the size of your tiny executable if you're working on a Linux distro that ships those deps already.

<comment><USER15> Java 9 adds jlink, which lets you create a runtime image containing only the java modules you're using.

This means you can ship a considerably smaller built in JRE with your app, if you don't want to depend on a system JRE.

javapackager (uses jlink): [https://docs.oracle.com/javase/9/deploy/self- contained-appli...](https://docs.oracle.com/javase/9/deploy/self-contained- application-packaging.htm)

jlink: [https://docs.oracle.com/javase/9/tools/jlink.htm](https://docs.oracle.com/javase/9/tools/jlink.htm)

<comment><USER16> I was able to create standalone java9 modular application using jlink, but didn't succeed using javapackager. Which is a pity, because jlink creates a distribution, which you launch with a _.bat file, instead of_.exe.

</comment></comment></comment><comment><USER17> It's also tough to beat the developer experience that the modern JS ecosystem has brought to app development.

The Chrome dev tools alone are pretty incredible. Getting that much detail in your debug environment, paint cycles, render times, animation effects, and quick style experimentation is a huge deal.

The package ecosystem for JS is also an enormous advantage. Having access to data layer systems like Redux & the Redux dev tools, as well as any module designed to run on Node.js really helps ensure an actively developed ecosystem that abstracts more and more away from the end application developer.

Finally, I argue that performance bottlenecks are rarely an issue of the javascript. V8 is extremely fast and only getting faster. Most bottlenecks come from doing something dumb during rendering, or tying up a process reading from disk. These are issues that happen on all app platforms. The big difference is that Electron gives you to tools to effectively debug and optimize these, plus a HUGE wealth of online resources & tutorials to help new developers jankbust.

<comment><USER18> That is nothing new when comparing with something like Delphi or .NET tooling.

</comment></comment><comment><USER19> As much as I dislike the inherent complexity of Electron, VSCode and Discord are existence proofs that it can be used effectively.

VSCode is far faster than any other IDE I've used, and even beats VIM in terminal in terms of responsiveness (altough I suspect this is not VIM's fault).

Discord is overall a great application, and quite responsive.

Both are slightly bloated in terms of memory, from what I supect they could be. But not nearly as bloated as many of the competing Java and C++ applications.

<comment><USER20> >But not nearly as bloated as many of the competing Java and C++ applications.

I too like discord and VSCode, but VSCode uses far more resources than sublime, with the tradeoff being that it's more easily extensible and has a faster release cycle(which may or may not be related to team size). VIM locally is obviously also going to be much faster and capable of opening far larger files than VSCode.

<comment><USER19> I haven't tried using sublime as a full IDE, so I'm not comparing against sublime.

<comment><USER20> Ahh, that's fair. If you're looking for something quick, and don't need the bleeding edge stuff like the language server, then sublime is very nice.

</comment></comment></comment></comment><comment><USER21> This article seems to miss the point. There's a huge pool of web developers who can write HTML/CSS/JavaScript; Electron lets you have those people use their skills to build desktop apps. It also lets all the others not directly working on the product to write plugins using familiar technology.

<comment><USER22> Yeah you get your front end devs creating beautiful UIs which can be directly ported to desktop.

The other thing of course is that Electron apps start out as web applications. So they already work perfectly in a browser.

</comment></comment><comment><USER23> Suppose a startup has a runway of 6 months and a full stack web dev who can build the backend and web frontend.

Are they going to fragment the code-base with Java to introduce a desktop client? Are they going to hire another enterprise Java dev, who most likely isn't familiar with the rest of the stack?

The rise of Electron is fundamentally driven by the cost effectiveness of the wide availability of developers and community support.

</comment><comment><USER24> Well short of being tossed into a time portal and popping out in 2007 I wouldn't build a client app in Java...

But Qt has rust bindings, so that's good to learn!

</comment><comment><USER25> Yeah, you just have to have Java installed on whatever system you're running the app on. From a development perspective (or anyone who has done end-user support of a desktop app) this is an absolute non-starter.

"Install this runtime, then you can install this app. Oh and that auto updater that is atrocious? You can thank us for having it. Thanks for being a loyal customer!"

<comment><USER26> Or you could just bundle the runtime with the application, you know, like Electron does.

<comment><USER27> This is one of the many reasons I don't like electron (the apps become /massive/ and I can't update electron separately from the app), but I recognise I'm not the target market.

</comment></comment></comment><comment><USER28> There's not really an acceptable amount of arguments against Qt and Gtk+ to support the headline. It reads like, "I don't really know much about the alternatives other than JavaFX, but this is why I personally like it..."

<comment><USER29> To me, on a sliding scale of complexity, JavaFx is closer to Electron than Qt and GTK+ (especially since your options are C++, or using bindings that have varying quality and ease of use).

If I was trying to sell someone who uses Electron on an alternative it'd definitely be JavaFx, maybe Qt with QML if they knew C++.

<comment><USER30> C++ in itself is pretty complex comparing to other languages

<comment><USER29> Yeah, main reason I'd only recommend Qt/QML if they were already comfortable with C++ (although Qt does a lot to help with memory management)

</comment></comment></comment></comment><comment><USER31> How did this get upvoted? Author misses the point entirely of Electron. If people wanted to write Java, they already would be doing that. The selling point for Electron is: folks are comfortable with JavaScript/HTML/CSS and can be productive right away. I'll take the neatly packaged (although larger) installer over requiring someone to have the JDK installed any day

</comment><comment><USER32> I'm a little disappointed that the article doesnt mention the benefits of JavaFX and why exactly I should ditch electron over javafx.

<comment><USER14> The author touches on app size and performance - both of which are fairly valid I believe, but they don't go into why JavaFX over other desktop UI frameworks.

<comment><USER33> I don't see any mention of perf

<comment><USER34> His just complaining and electron eats memory (supposed 200MB on startup). Find it funny he brings Java as a better alternative to the table.

</comment></comment></comment></comment><comment><USER35> Isn't a main advantage of using the web stack to build desktop apps that you can share code with a web hosted version?

</comment><comment><USER36> >Hey look at this proprietary software that's so cool and old and established! >The web has only been around for 20 years! >Pfft not even kidding they're trying to make desktop apps with web tech! PFFFFFT

'nuff said.

</comment><comment><USER37> Author: "Electron is bad so let's use something even worse."

<comment><USER38> Why do you think it is worse? I am interested in hearing of your experiences on this.

<comment><USER31> Setting aside subjective reasons... how about the barrier for entry being lower for web development? Also, more people arguably have web development skills

Java isn't new or unpopular- if people wanted to use it, they would

<comment><USER39> The barrier for entry of web development is not necessarily lower, it's more that most people have already tinkered with web development informally.

Many IDEs have some sort of visual GUI layout tool, but the nature of HTML+CSS makes it a far leakier abstraction less suited to visual positioning.

</comment></comment></comment></comment><comment><USER40> Oracle has caused so much harm to java. javaFX does not work well when display is remote (90% of my use case).

</comment><comment><USER41> If JavaFX requires my customers to have Java installed on their system then this is some sort of joke.

<comment><USER38> You can package the JRE in with your app very easily using the tooling provided, customers don't need the JRE installed on their system.

</comment></comment><comment><USER42> A question - Does Jython (Python) get compiled to byte code for the JVM? Or does it run interpreted?

</comment><comment><USER43> I've recently written javafx with kotlin. It was a very pleasant experience.

</comment><comment><USER44> Having messed around with JavaFX in the last 3 months, I advocate against it.

<comment><USER45> Why? Is it just difficult to use or the app you wrote is not as good as your Electron app?

</comment></comment><comment><USER34> Look. I agree, that you shouldn't make desktop applications in Electron. The thing is, when you have a fresh grad student that was taught PHP as a web framework for most of the time and maybe Node, what do you think they will gravitate towards? I understand veterans feel like Qt, GTK and JavaFX are intuitive in their architecture and syntax but that is simply not true. Heck even XML can be jarring.

So here's what i've found people trip up with JavaFX mostly.

1) FXML. Why do you need so much information just to view "Hello world". You need to define a scene, then you need to define what's inside the scene (You'll need to go look up a reference guide on JavaFX to find what objects you can attach just to get started), then you need to describe that a text node is connected to the thing inside the scene. For HTML it's always gonna be . Inside the body it doesn't matter what structure you create, you'll be cutting off "sections" with plain html+css. HTML5 got it's canvas if you need more advanced functionality. Why would people who have been taught to use canvas and DOM revert to this?

2) Custom CSS. Fantastic, more syntactic sugar and another reference guide to search through... people get effects/animations with greensock or css nowadays, it's fairly competent stuff and frankly more intuitive. Just a gem from the reference: background: white; -fx-text-fill: ladder(background, white 49%, black 50%);

Without reading the reference I'm thinking it's filling the color. What does ladder and it's arguments mean I would have no idea. What does is this: "Use the following if you want the text color to be black or white depending upon the brightness of the background." – right, cool but there's filters and stuff made for this very thing in plain old CSS.

3) JVM hot code reload. The entire section is confusing to people using Node that learned to implement a watcher in Tutorial 1 of setting up package.json. Good luck explaining intricacies of JVM to grads that struggled to get bare bones Java application running in Eclipse. "I find it hard to believe that anyone would prefer the webstack to working with a sane environment like the JVM." – I profusely disagree. The fact you need to have a virtual machine for your code to execute is a lot for people outside the bubble to comprehend. The fact you have two types of dependencies, runtime and compile, already confuse new people coming into the field. Gradle which is supposed to make lives easier is still way more confusing than fiddling with package.json. It's perhaps not Gradle's fault, I think the blame is more with veteran developers that like to be 'clever' and manage to obfuscate something as simple as launching an application.

4) SceneBuilder. "It can be integrated into all Java IDEs, making it easy to create new views.". What the author has forgotten to mention, is that it can be a pain to use and integrate (Haven't tried this in IntelliJ and i'm sure it's better there but it's still more hassle than opening your flavor of browser inspection). You'll most likely end up ditching the GUI and do everything programmatically, at which point you'll ask yourself why are you doing css and js in Java. The example in the article is a simple "Hello World". Anything more complex and you'll find people falling into the habit of doing everything inside of Java.

5) ScenicView. "To start it with your application, just download the jar and pass the option -javaagent:/path-to/scenicView.jar to the JVM." – that line might as well be written in Chinese if you're a person coming from the Node scene.

6) JavaFX does not automatically refresh stylesheets. You need to build a whole seperate function and implementation just to refresh a stylesheet. "This works in Mac, Windows and Linux Mint. But this was one of the only two problems I had related to differences in OS's (the other one was the icon in the system tray on Mac does not work, but there is an ugly workaround for that). JavaFX abstracts that away pretty well, most of the time!". Well that's reassuring there is an iffy solution to a problem that shouldn't be there to begin with.

I also feel the author is quick to throw anyone using electron under the hipster title and then proceeds to call the webstack a mess yet ignoring the mess that Java is. Need I remind you why Node stuff was so popular? Because people required entire days to figure out how to get a simple ToDo Spring application working. And Spring is supposed to be easy. Think about that. You need to spend dev time on something as obscure as 'JVM tuning' at one point or another. Or fixing some bizarre leak/overflow because hurr-durr imperative programming. And the 20 years of patterns and best practices wasn't good enough. We have shit like JPerf to figure out why all those stern-toned articles still lead to shitty code and JRebel to sweep the problem under a rug.

"We've been writing desktop apps for decades. The web, on the other hand, only really got started less than 20 years ago, and most of that time it was only used for serving documents and animated gifs, not creating full-fledged applications, or even simple ones! To think that the web stack would be used to create desktop applications 10 years ago would be unthinkable." – And here we are with Java still remaining the clusterfuck that it is.

"If people are preferring to ship a full web browser with their apps just so they can use great tools such as JavaScript (sarcasm) to build them, something must have gone terribly wrong." – yeah, that something was the JVM. Kinda funny we now have all this compile-to-js stuff when there's still uppity aura revolving around JS. Heck I remember having trouble with just the JRE back when I hadn't learned any programming.

</comment><comment><USER46> Please just write native apps, and quit trying to cut corners. Geez.

</comment><comment><USER47> Ugh this just reads like an old Java developer pissed off at people not using his tool of choice. His snide remark about JavaScript just tells me that he has an outdated view of the language. JS is weird yes. JS has problems yes. But the author is promoting friggin JAVA as the alternative?? Phfft!

There are reasons to pick your tools. Sometimes speed of development and being able to use your pool of developers existing skill sets effectively is one of them. If you have a bunch of web developers and need a desktop app then electron is something you might want to seriously consider. ESPECIALLY if you don't have unlimited time to get the product out to market. Electron is not a one size fits all choice and conversely neither are the frameworks the author is proposing. Decide what you need and make your choice based upon those needs.

I am building an electron app as we speak. Its not without its challenges and there is no doubt that native approaches would trump it in some respects but it literally does everything I need it to do. Better yet, I can hand this off to my team who all have a development background and any one of them can jump in and be able to contribute in a meaningful manner within a day or two of groking the codebase.

I guess my point is, lets stop bagging on technologies for the sake of it. Every single one of them involves trade offs. Effective developers weigh those against the problem they are trying to solve and pull the trigger on the one that gets the job done best.

<comment><USER3> > JS is weird yes. JS has problems yes. But the author is promoting friggin > JAVA as the alternative?

As a language, I find java is much better designed than Java Script.

<comment><USER47> Thats a totally valid opinion but its just that: an opinion. Personally I find Java overly verbose and bloated. I'd use it if it was the right too for the job though. Just depends on what you are doing.

<comment><USER3> > Personally I find Java overly verbose and bloated

Not much more verbose than it needs to be explicit.

      "Explicit is better than implicit."
                           PEP 20, Zen of Python

<comment><USER47> I mean, I guess? Again we are talking about preferences here. I think being explicit has less to do with the language and more to do with the developer writing it. Poorly or well written code is universal and all offer you the tools to shoot yourself in the foot or vice versa.</comment></comment></comment></comment></comment>


Robotics Open letter to the European Commission - T-A http://www.robotics-openletter.eu/ <comment><AUTHOR> Your Honour, the courtroom is a crucible. In it we burn away irrelevancies until we are left with a pure product, the truth for all time. Now, sooner or later, this man or others like him will succeed in replicating Commander Data. And the decision you reach here today will determine how we will regard this creation of our genius. It will reveal the kind of a people we are, what he is destined to be. It will reach far beyond this courtroom and this one android. It could significantly redefine the boundaries of personal liberty and freedom, expanding them for some, savagely curtailing them for others. Are you prepared to condemn him and all who come after him to servitude and slavery? Your Honour, Starfleet was founded to seek out new life. Well, there it sits. Waiting. You wanted a chance to make law. Well, here it is. Make a good one.

</comment><comment><USER2> If I'm reading it right, this is about creating a legal equivalent of the "human error" defense for robotic equipment, such that the operating person or company can just say "whoops, the robot made a stupid mistake" and have that be the end of it, the same way they'd currently say "whoops, our employee made a stupid mistake."

<comment><USER3> That was my reading too.

It's still a machine, so treat it like any other machine and hold the designers liable.

The cynic in me says that this is what happens when the principles used in idealised software environments, where failure has limited consequences, meet the physical world. A better model would be that used in embedded software, an area where software has a long history of interacting with the physical world and the aim is intrinsic safety.

If a designer wants to use a pseudo-random AI system, then it should be encased in a deterministic wrapper which keeps it within a safe envelope.

<comment><USER4> > It's still a machine, so treat it like any other machine and hold the > designers liable.

I think you mean the operator. If I run someone over in a car, I'm responsible, not the manufacturer nor the vehicle itself. Sure, manufacturers can be liable for design flaws (steering wheel didn't work?) but it's appropriate that that not be the default.

(This rule should also apply to another great invention: the corporation. Sadly, however, the "drivers" never seem to be held accountable.)

<comment><USER5> How about setting up a new company to own each new machine, thus shielding the parent corporation from liability for that machine's mistakes (beyond the value of the individual machine)?

<comment><USER2> That's basically one of the approaches they discuss:

> The legal status for a robot can't derive from the Legal Entity model, since > it implies the existence of human persons behind the legal person to > represent and direct it. And this is not the case for a robot.

They also cover treating the robot as a trust fund:

> c. The legal status for a robot can't derive from the Anglo-Saxon Trust > model also called Fiducie or Treuhand in Germany. Indeed, this regime is > extremely complex, requires very specialized competences and would not solve > the liability issue. More importantly , it would still imply the existence > of a human being as a last resort – the trustee or fiduciary – responsible > for managing the robot granted with a Trust or a Fiducie.

Edit: The silly thing is that they want to ensure that robots have "the status of electronic persons responsible for making good any damage they may cause" while simultaneously holding that a robot can't be a Natural Person "since the robot would then hold human rights, such as [...] the right to remuneration".

So in their book a robot can't earn money but is personally financially liable for any damage it causes.

</comment></comment></comment></comment></comment><comment><USER6> So the EU Parliament (bunch of nobodies every ignores) have recommended to the EU Commission (EU civil service, bunch of generally experienced civil servants who get to pass rules from their in-country colleagues that their in-country civil servants and politicians find too unpalatable to do at home) asked the commission to (eventually) pass laws giving robots legal person-like status because you know, Asimov is cool.

And actual experts have written saying that's a bad idea.

But i had to read it twice to find that out - guys take a tip from newpapers "Who the hell reads the second paragraph?" Next time put the story in the first paragraph

Anyway, yeah. like nothing bad will come of making robots legal persons.

We can wait till Robin Williams asks

</comment><comment><USER7> Wow, are these clowns really that stupid or are they paid by industry? US- based thinktanks have to reveal their financial details (donations etc), in the EU they don't. This needs fixing ASAP.

I'm sure Google, Amazon, Uber, Tesla and Boston Dynamics would just _love_ to blame their AI products instead of themselves. "But it was the robot-person that run over the pedestrian your honor. Jail the car sir, not the manager." So very convenient eh?

</comment><comment><USER8> I work in the Danish public sector and we're slowly adopting robotics (which is really just macros) and machine learning, and I'm a bit split in the issue.

On one hand RPA software needs to be able to log on systems as though it was a real employee for it to function, because our systems are designed for people. I mean, if the systems were designed to be efficient, I would be using a rest API not a fucking macro.

On the other hand I think it would be dangerous if we start protecting machine learning like we protect our human workers. Right now our approach to machine learning is similar to how advertising companies predict your behavior based on previous data. It's build on determinism, and I think that is a flawed way to look at human beings. If we look at the science of history, determinism only works for so long, the more facts we have the harder it becomes to answer why something happened the way it did.

I view machine learning results, and I'm talking about machine learning used on unstructured data sets that make administrative legal recommendations, not the sort that suggest analytic graphs on datasets, is fundamentally flawed. We're shooting toward a society where people at high positions in the government actual,y believe we can predict behavior, we've done proof of concepts that are promising as well, as an example we're able to predict which shitty parents will need "interventions" (I don't know the English word, sorry) but only with a 70% accuracy. If we start acting in those data sets, we may make matters worse, because we already know that by expecting someone to fail we actually increase the chance of it happening.

I think machine learning is interesting, I also think you can use it to say a lot about what will happen, but we still can't use it to tell us why something is happening, and until we do (if ever) we should be careful how much we trust it in administrative law.</comment>