Ask HN: What's the best library for making cross-platform UIs? - <AUTHOR> <comment><USER2> It would help a lot to have the question elaborate on what you really need. What do you mean by "best", and do you actually need the best? Do you need easy to learn, or code that is easy to deliver, or most powerful features, or most number of platforms covered? Do you include mobile in cross platform, and do you have a performance or language requirement?

A web app is one of the most cross platform ways to go, is the easiest to deliver, and can be easy-ish to learn, but isn't the easiest. But, you are stuck with JavaScript. If a web app won't work for you, why not? Knowing that will allow people to help you more.

Qt is great, especially if you're using C++ or some other language. It's pleasant and very powerful, but a lot to learn, and deployment to users is harder than a web app.

What are your constraints & requirements?

<comment><USER3> I agree across the board with your assessment.

It is a shame that OP does not want to go HTML/CSS engine, because over the years, I have found that to be the easiest to update, the most reliable across platforms, and (most importantly) the easiest to support for multiple users.

I have tried (and used in production) most of the UI tookits mentioned here.

WxWindows (later WxWidgets), Tk, and FLTK are getting long in the tooth and show it.

Java (SWT, etc), looks wonky across platforms and really do not stand up to the "write once, run anywhere" promise. Also, if you have to do anything even a little out of the lines, count on keeping multiple codebases for different platforms.

Although I had a brief love affair with other VM-type platforms (Adobe Air, Silverlight), mobile mostly pushed support for them out (Air just pivoted to mobile altogether, I believe). They offered single codebase, easy updates, and easy-ish support at a cost of have the user install additional software, but worth the tradeoff in my opinion.

All of the python UI libs are a pain in the ass to distribute, update, and support.

Ultimate++ and Borland Delphi are pretty polished, but you either have to buy into their ecosystems or accept their limitations.

At the end of the day, even though Javascript is a bullshit language for desktop development, HTML/CSS engines (phonegap, Electron, sciter, etc) are just pleasant for maintaining codebase, pushing out updates, doing anything you want with the UI, and support has been a breeze.

<comment><AUTHOR> Why is Tk getting long in the tooth? This comment believes Tk is as good as wkWindows and QT [https://news.ycombinator.com/item?id=12380456](https://news.ycombinator.com/item?id=12380456)

<comment><USER3> Tk and WxWidgets are not in the same league as QT.

Tk is limited, specifically, to being a gui toolkit, and even though the most recent versions look like native widgets, they are limited and the online support (from groups, etc) is limited. All the connecting libraries feel like you are back in the 90's programming again.

WxWidgets is to QT, as Linux is to Mac OS X -- one is cobbled together from amateurs with varying quality of components, and the other is built by professionals and held to professional rigor. The API (and output, in my opinion) is amateurish and dated in comparison. It lacks the polish and ecosystem that the professionally-supported QT has.

If you are making a full-fledged application (as opposed to a user tool or back-end interface) and are hell-bent on using a windowing toolkit (over say an HTML/CSS engine), then QT is currently the only correct answer. There are others around, but they all fall short of QT.

On a side note, Tcl (by the same original author as Tk) is a wildly under- appreciated scripting language.

<comment><AUTHOR> Thanks for sharing this knowledge.

What can Tk not do, specifically? This thread believes Tk is as good as QT [https://news.ycombinator.com/item?id=12380456](https://news.ycombinator.com/item?id=12380456)

<comment><USER4> This might help illustrate:

[http://forum.sqlitestudio.pl/viewtopic.php?f=16&t=334](http://forum.sqlitestudio.pl/viewtopic.php?f=16&t=334)

That post is by the lead developer of a SQLite project competing with the one I'm involved in. The original version was developed in Tcl/Tk, and outgrew it.

Note - I'm not personally familiar with Tck/Tk, I just remembered reading this when you mentioned it. :)

</comment></comment></comment></comment></comment></comment><comment><USER5> Strange nobody mentioned wxWidgets so far which gives you true native apps, so I'll do it:

[http://wxwidgets.org](http://wxwidgets.org)

It provides API layer which compiles to Win32 API on Windows, Gtk2 on Linux and Carbon/Cocoa on Mac OSX.

Qt only emulates Windows controls, but wxWidgets uses the actual Windows controls via Microsoft Win32 API.

BTW, there's wxQt, a wxWidgets implementation that uses Qt instead of Gtk, but it's still experimental:

[https://wiki.wxwidgets.org/WxQt](https://wiki.wxwidgets.org/WxQt)

wxWidgets has been used by some popular projects like Audacity, TortoiseCVS, RapidSVN, FileZilla, BitTorrent, etc.

Another wxWidgets advantage over Qt is the license, which gives you more freedom.

If you're looking for a faster start, take a look at wxFormBuilder which is a graphical WYSIWYG UI editor where you can drop controls in windows/dialogs and hook up event handlers.

You can find links to more related tools/IDEs on the Wikipedia page:

[https://en.wikipedia.org/wiki/WxWidgets](https://en.wikipedia.org/wiki/WxWidgets)

<comment><USER6> In my experience with it, wxwidgets has a very antiquated feeling to the API (I know, subjective) and it didn't ship high DPI support when I used it. Its Python bindings at the time felt rather unpythonic. Generally I wouldn't want to use this again.

<comment><USER7> "wxwidgets has a very antiquated feeling to the API"

This should not be relevant in any professional technical discussion. Last time I looked there was not an overflowing oversupply of cross platform UI frameworks.

"it didn't ship high DPI support "

This, on the otherhand, might be a critical deficit.

<comment><USER8> > This should not be relevant in any professional technical discussion. Last > time I looked there was not an overflowing oversupply of cross platform UI > frameworks.

That latter sentence kinda defeats the argument in your first sentence.

If there's a dearth of options, then there's room for a better API.

<comment><USER7> "If there's a dearth of options, then there's room for a better API."

A new UI framework is not something you can wish for Christmas. One can implement one (like Blender has done) but other than that, one is limited to the options which are available.

I don't think anyone claims there is no space for new UI libraries. It's not obvious one can simply implement a new one. This is not something someone does for fun over a weekend (at industrial scale) or just to try an epiphany of design over a few months. They are huge, laborious beasts. If one has resources to implement a huge UI framework, then generally, they probably have the resources to implement the UI natively on every platform they wish to deploy on.

"A better API" is kinda moot feature for a UI library since they are technically so demanding, all other factors are more critical.

</comment></comment></comment></comment></comment><comment><USER9> What is the best depends on your exact requirements but three good options to get a GUI off the ground quickly are Tk [1], wxWidgets (and wxPython [2] and wxLua [3] in particular) and Lazarus (LCL) [4].

Tk widgets look native on Windows and macOS (if you use the right ones — see [5]), though their behavior is implemented by Tk itself. On Linux it draws its own widgets in several styles; GTK and Qt theme support is immature. Lazarus and wxWidgets use native widgets on Windows and macOS. Both can use GTK2 on Linux but Lazarus also supports GTK1 and Qt.

If I had to deliver a cross-platform desktop GUI application by midnight today, I would go with Tk, write the code in Tcl (which necessarily has the best Tk integration) and package it in a static binary Starpack [6].

[1] [http://www.tkdocs.com/](http://www.tkdocs.com/)

[2] [https://wxpython.org/](https://wxpython.org/)

[3] [http://wxlua.sourceforge.net/](http://wxlua.sourceforge.net/)

[4] [http://www.lazarus-ide.org/](http://www.lazarus-ide.org/), [http://wiki.lazarus.freepascal.org/LCL](http://wiki.lazarus.freepascal.org/LCL)

[5] [http://www.tkdocs.com/tutorial/idle.html](http://www.tkdocs.com/tutorial/idle.html)

[6] [https://tcl.wiki/Starpack](https://tcl.wiki/Starpack)

<comment><USER10> Tk is antiquated (no antialiasing [1]) and has a poor look on Linux. It lacks functionality in widgets such as embedding a progressbar in a tree/list (don't remember) widget, which Qt supports. Also, poor font rendering support. (doesn't render Devanagari and probably CJK scripts). It feels like a 10 year old tech which it is.

(1) Maybe there is some option for it somewhere, but if so, having antialiasing disabled by default is weird.

<comment><USER11> Suitability of Tcl/Tk depends on what the goal is. For some applications, like utilities, GUI access to CLI tools, form-based data entry, etc., Tk is fine. It isn't a good option for a sophisticated drawing program, and I would try to use it for a full-bore word processor.

Within its domain, Tk is a very capable tool that easy to use, well- documented, versatile and relatively bug-free.

Future versions are planned to acquire antialiasing and other improvements, no doubt it will be a while before it's available.

<comment><AUTHOR> From what I'm reading in this thread, Tk is out of the question. Poor antialiasing sounds like bad looks.

<comment><USER12> I don't understand how anyone can assume that antialiasing is missing in Tk, it's simply wrong and has been there for many years for font drawing. On Linux, it must be compiled against fontconfig/xft (default, if the headers can be found). On OSX and Windows, it uses the native font renderer. The only point on OSX high dpi displays: you need to set a property that the application supports high dpi (in a .plist file), but this holds for any App- bundle on OSX. Antialiasing on a canvas (as opposed to text in labels, buttons etc.) is only enabled in OSX by default. tkpath replaces the default canvas with a more complete implementation (alpha blending, gradients, antialiasing...) on all 3 platforms.

<comment><AUTHOR> Thanks so much for this! I know very little about Tk.

Besides antialiasing on a canvas, does antialiasing also work in text in labels, buttons, etc? Can I get in Tk all the fonts I can get in a Mac? Is Helvetica there?

Why can't I find on the web screenshots of Tk apps running on Mac OS X? Is the only way to get Tk to look good on a Mac using Tile [http://tktable.sourceforge.net/tile/screenshots/macosx.html](http://tktable.sourceforge.net/tile/screenshots/macosx.html) ?

From what I'm reading now there might be 4 options: Tk, wxWindows, QT, and a custom "thin layer".

<comment><USER9> The link [5] in my top-level comment plus [http://www.tkdocs.com/tutorial/fonts.html](http://www.tkdocs.com/tutorial/fonts.html) should answer your questions. The former has screenshots of Tk on macOS and discusses how to make it look good there. There is a screenshot of a commercial Mac application built with Tk at [http://www.codebykevin.com/portauthority.html](http://www.codebykevin.com/portauthority.html).

Tile was integrated into Tk with version 8.5 (2007). The Tile button, label, etc. are now built in.

<comment><AUTHOR> This comment says Tk is limited [https://news.ycombinator.com/item?id=12381978](https://news.ycombinator.com/item?id=12381978) You and the GP say it's not.

Is there anything Tk can't do?

Also a question on fonts. Does Tk make it possible to use webfonts I see on websites?

<comment><USER9> >You and the GP say it's not.

But I did not say that. In the reply to the comment you've linked you write that "this thread believes Tk is as good as QT". I am puzzled by this conclusion because I do not see any comparison to Qt at all. Certainly, I didn't want to suggest any with my comments.

If you want to know my option on how Tk compares to Qt, I currently believe that, for the most part, they serve different use cases, with some overlap in the middle. Tk is better than Qt in one area (roughly: small-to-medium applications developed by a lone hacker ASAP) and Qt is better than Tk in another (roughly: medium-to-large applications developed by a team on some sort of a schedule).

Qt does a lot more than Tk. It comes with more features, e.g., networking abstractions. Compared to it, Tk _is_ limited. Qt looks better, too — much better on *nix. I would not recommend Tk over Qt in the general, catch-all, could-become-a-kitchen-sink-application case. (In fact, working well in the general case seems to be a major selling point for Qt.) If you develop one, chances are you will find yourself wanting to do something that Tk can't. In other words, I would expect a large application to outgrow Tk before it outgrows Qt.

I recommended Tk specifically for making a GUI quickly. It is good for prototyping and rapid iteration and has neat widgets like canvas and the text editor that help a lot with that. Tcl with Tk is expressive, so you can do a lot in under 1000 lines of code (toy example: [1]). The Tcl REPL helps more still, as does a great binary deployment story. After the prototype or MVP, once you understand what you want to do better, you may stay with Tk if you decide it suits your needs or switch to something else.

>Is there anything Tk can't do?

That is a very open-ended question. One thing that comes to mind is integrating with the host platform's accessibility features. Most cross- platform GUI toolkits suck at it. There is a wishlist wiki page [2] that might offer some hints at what other things Tk users find missing.

>Does Tk make it possible to use webfonts I see on websites?

Not easily. See [3].

[1] [https://tcl.wiki/41294](https://tcl.wiki/41294)

[2] [https://tcl.wiki/4055](https://tcl.wiki/4055)

[3] [https://www.reddit.com/r/Tcl/comments/456ydh/is_there_a_way_...](https://www.reddit.com/r/Tcl/comments/456ydh/is_there_a_way_to_load_a_ttf_font_file_and_use_it/)

<comment><USER10> > I recommended Tk specifically for making a GUI quickly. It is good for > prototyping and rapid iteration and has neat widgets like canvas and the > text editor that help a lot with that. Tcl with Tk is expressive, so you can > do a lot in under 1000 lines of code (toy example: [1]). The Tcl REPL helps > more still, as does a great binary deployment story. After the prototype or > MVP, once you understand what you want to do better, you may stay with Tk if > you decide it suits your needs or switch to something else.

Actually, I would argue the opposite. I found it easy to create GUIs using Qt Designer and to use connect() to bind functionality together. (Albeit, this was with Python, it might be harder in C++).

> widgets like canvas and the text editor

Is there something particularly unique in Tk's canvas and text editor?

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> React Native supports

* iOS

* Android

* OS X [https://github.com/ptmt/react-native-macos](https://github.com/ptmt/react-native-macos)

* Windows [https://github.com/ReactWindows/react-native-windows](https://github.com/ReactWindows/react-native-windows)

* Ubuntu [https://developer.ubuntu.com/en/blog/2016/08/05/introducing-...](https://developer.ubuntu.com/en/blog/2016/08/05/introducing-react-native-ubuntu/)

* the web [https://github.com/necolas/react-native-web](https://github.com/necolas/react-native-web)

<comment><USER5> AFAICT, it isn't "Windows", but "Windows 10 only".

Is this correct?

<comment><USER14> Yes the windows link above is for Universal Windows Platform apps which isn't what most people think of when they think "windows app". For React Native on desktop I've been bundling my React app into a Electron shell, works pretty well.

</comment></comment></comment><comment><USER15> Qt has a truly pleasant API and bindings in many languages. If you haven't used it before - and I know you haven't, otherwise you wouldn't be asking :) - give it a try. There's very little that's more cross-platform.

<comment><USER16> Qt's nice, but the thing I've always disliked about it is that it re- implements all these basic types, like QString, QVector, QList, QMap, etc. and you need to use them to interact with all their APIs. So, you either have to decide you're all-in on Qt and have these QThis and QThat types littered all over your code (making it more difficult to interact with other third party libraries like boost that know nothing about Qt, or you need to agree on a boundary between your non-Qt-specific code and your UI, and maintain a layer that converts to and from standard types.

<comment><USER17> I'm working on a Qt project, and our convention is to have a pure C++ back-end (i.e., STL), but use QObjects everywhere on the Models, Views and Controllers (as per Qt's MVC pattern). That way we can one day re-implement the UI if needed and keep the same "pure" C++ back-end. This has worked fine for us so far.

<comment><USER18> +1. that's exactly what I do.

</comment></comment></comment></comment><comment><USER19> Just getting started on Electron myself. Used by Atom, Slack, Visual Studio... It's worth a look ;)

Electron - Build Cross-Platform Desktop Apps With HTML, JS, CSS

[http://electron.atom.io/](http://electron.atom.io/)

<comment><USER20> Electron only works for desktop applications and probably needs a js-framework to work good. I think that React + Electron looks like a nice combo and then you can use React Native to create Android and iPhone apps also, probably sharing a lot of code between all versions.

<comment><USER21> At the moment the pairing seems to be Electron + Cordova for non-React JS frameworks; with those two you can share 100% HTML at least if you have a responsive CSS design.

Also, now that React Native is extending into the Desktop space more directly (with Linux, Mac, and Windows UWP variants), for React you may not need Electron at all.

<comment><USER21> Further aside, I'm also amused and unsurprised that engineering has been going into React Native for Web [1] so that with React Native you might not even target base DOM React again.

[1] [https://github.com/necolas/react-native- web](https://github.com/necolas/react-native-web)

</comment></comment></comment></comment><comment><USER22> There are plenty of options (all biased by personal opinion) for this task. Maybe one of these projects is a good fit for you (creating consistent uis should be easy with all of these).

\- [https://crosswalk-project.org/](https://crosswalk-project.org/)

\- [https://cordova.apache.org/](https://cordova.apache.org/)

\- [https://kivy.org/](https://kivy.org/)

\- [https://www.nativescript.org/](https://www.nativescript.org/)

\- [https://www.xamarin.com/](https://www.xamarin.com/)

\- [https://facebook.github.io/react- native/](https://facebook.github.io/react-native/)

#

\- [https://www.wxwidgets.org/](https://www.wxwidgets.org/)

\- [http://nwjs.io/](http://nwjs.io/)

\- [http://electron.atom.io/](http://electron.atom.io/)

</comment><comment><USER23> "The best" is subjective. I have played around with libui ([https://github.com/andlabs/libui](https://github.com/andlabs/libui)), which runs on Windows, Linux, and macOS. A nice thing about it is that it is written in C, and therefore has bindings with several programming languages. I have experimented using it from Java (via JNA) and it works quite nicely.

<comment><AUTHOR> libui is kind of neat. It wraps around GTK+. Why did libui have to do that? In other words, is GTK+ bad enough that the easiest way to use it is to wrap around it?

<comment><USER24> GTK+ is dreadful on Windows. I'd stay away.

Personally I implement the UI in as thin a layer as can be architected and reimplement for every platform. It's the best way, and probably cheaper for most apps than trying to force some lowest common denominator library to express what you want in high fidelity.

<comment><AUTHOR> Ok, no GTK+! (Could this be fixed with GLib?)

I didn't understand this. When you say you implement the UI as a thin layer do you mean you wrap only the few controls you need?

<comment><USER25> libui only wraps around GTK+ on Unix systems. On Windows, it uses the native Windows API directly.

GLib is a utility library; it provides things like container types, filesystem access, networking utilities, threads, object-oriented programming with events and properties, and other similar functions in a platform-independent manner. GTK+ uses GLib. You can use GLib on its own as well. It won't solve the problem of GTK+ being clunky on Windows, though.

<comment><AUTHOR> What I don't get is: which library lets you draw stuff on the screen. GLib or GTK+?

I thought that was GLib, and GTK+ was using GLib to implement controls.

Which library does one need to build their own controls?

</comment></comment></comment></comment></comment></comment><comment><AUTHOR> Here's what I want.

\- The UI to look as good or better than the UI on Mac OS X. I'm not willing to compromise on looks.

\- The library to be cross-platform. I want to deploy the software on Mac OS X, Windows, and Linux. I don't care about mobile right now.

\- I want it to be possible and easy to (a) develop new features on my own and (b) change existing features. I'd rather reimplement a textbox from scratch if it's the only way to change a control. If this means I need something more like GLib instead of GTK+, so be it.

\- I won't use the web. No HTML, no CSS, no Javascript. Sorry.

The end goal is to build the best, easiest UI environment to write software with. If it's not possible to build this with existing UIs and I have to write one from scratch, so be it.

<comment><USER26> Pretty sure that C++ and Qt is what you want. Maybe not perfect in every sense, but widely used and battle-tested.

If you don't want to deal with Windows, you can cross-compile for Windows from Linux using the mingw-* packages (eg [https://fedoraproject.org/wiki/MinGW](https://fedoraproject.org/wiki/MinGW) or the Debian or SUSE equivalents).

<comment><USER27> Or you can use preconfigured cross-compilation toolchain like MXE[1]. If you have clean codebase and use CMake it's usually enough to just pass one extra argument to get working binary out. And it's also work on OS X.

[1] [http://mxe.cc/](http://mxe.cc/)

<comment><USER4> MXE has an ok reputation. Not everything seems to play well with it though. :(

For example, we (sqlitebrowser.org) compile our window nightly releases from Linux, using MXE. But, SQLCipher (an encryption library) doesn't build with MXE. So the nightlies don't support encryption.

Meanwhile, we've figured out how to do full Windows dev setup and builds. eg:

      https://github.com/sqlitebrowser/sqlitebrowser/wiki/Setting-up-a-Win64-development-environment-for-DB4S

We're building our releases natively now, and the nightlies will be built natively too in (hopefully near) future.

Guess we just outgrew MXE?

</comment></comment></comment></comment><comment><USER28> None, abstract the functionality of your app into a cross-platform library and build a native GUI for each platform you support using that platform's native SDK.

<comment><AUTHOR> Shouldn't this be a solved problem?

<comment><USER29> There's a reason there are multiple OS's, right?

One of the reasons is different UI paradigms and choices.

</comment></comment></comment><comment> open-source-ux Take a look at Free Pascal and the Lazarus IDE.

What is a Lazarus? From their website:

" _...a cross-platform IDE for Rapid Application Development. It has variety of components ready for use and a graphical form designer to easily create complex graphical user interfaces._ "

Why use Lazarus and Free Pascal? You can create native, cross-platform UI's all combined into a single, fast, low-memory executable that can easily be deployed and distributed on different platforms.

[http://www.lazarus-ide.org/](http://www.lazarus-ide.org/)

</comment><comment><USER30> I work on a cross-platform application that runs on both Windows and Mac.

We have a cross-platform library for business logic, and native Windows and Mac UIs.

The problem is that cross-platform UI libraries don't really let you fine-tune the UI. They're great for very rapid development with a basic, functional, UI.

If you get an "artiste" in product management, or you need to plug into Windows-specific and Mac-specific functionalities, you will need to use platform-specific UI libraries and keep your business logic platform-neutral.

<comment><AUTHOR> > cross-platform UI libraries don't really let you fine-tune the UI

I want to be able to fine-tune the UI.

<comment><USER31> You can't have both - cross-platform with native looks yet fine tunability, since those desires are at odds with each other (unless you want to implement that tunability for each platform you support).

</comment></comment></comment><comment><USER32> I've recently been using Crank Storyboard and I've been off to a good start. You can run it on embedded devices like ARM Cortex-M series processors, or Linux, iOS, Android, Windows, with openGL support. It does require a license though.

[http://cranksoftware.com/storyboard- suite](http://cranksoftware.com/storyboard-suite)

Also someone else mentioned Phonegap and using HTML/JS. I think is a good option but it depends on what your app does and if you're doing mobile app design.

I have not used QT yet, but after doing some research, it's kind of a pick your poison type of choice, IMO.

</comment><comment><USER33> I have tried many but always turn back to qt. It has bindings for whatever language, compiles for any platform and the documentation is superb.

</comment><comment><USER34> IUP[0] has not been menthioned.

IUP is wrapper for gtk+, motif and win32.

Pros:

* really simple api

* native toolkit

* c api, so other languages can easily write binding for it

Cons:

* controlls(widgets) are limited

* cocoa(mac) is not supported {they suggest to use gtk instead}

* documentation is spotty

* nobody is using? (I believe no linux distros have it in repository)

somebody here menthioned libui[1], it is exactlly the same philosophy

[0][http://webserver2.tecgraf.puc-rio.br/iup/](http://webserver2.tecgraf.puc- rio.br/iup/) [1][https://github.com/andlabs/libui](https://github.com/andlabs/libui)

<comment><USER35> There is a project to add cocoa support that would appreciate some help.

[https://github.com/ewmailing/IupCocoa/tree/Cocoa](https://github.com/ewmailing/IupCocoa/tree/Cocoa)

</comment></comment><comment><USER36> If you don't want a _native_ GUI, you can go the Electron way. This way you'll have a fully cross-platform application with minimum hassle.

If you want a native one, probably Qt is the winner here.

</comment><comment><USER37> React (Native). You can build an iOS and android app with the same codebase. Even windows phone and ubuntu are starting to support it. Then when you want to use the web, your whole data layer can carry over to reactjs. It's a really nice way of doing things. There's even react native for Mac OS that someone has started.

<comment><USER38> You can also wrap the reactjs web application in in Electron ([http://electron.atom.io/](http://electron.atom.io/)), which supports Mac, Windows and Linux.

</comment></comment><comment><USER39> For a file manager I'm developing [1], this question recently boiled down to Electron vs (Py)Qt. I chose (Py)Qt because Electron's startup speed is too slow.

[1]: [https://fman.io](https://fman.io)

<comment><USER31> How are you handling licensing? Are you using the commercial version of PyQt? I've been thinking of distributing some apps I've built but I don't want to make them GPL (I don't mind using MIT or BSD though).

<comment><USER40> There's PySize [https://wiki.qt.io/PySide](https://wiki.qt.io/PySide) but it probably needs work

<comment><USER31> PySide doesn't work with Qt5 yet.

</comment></comment></comment></comment><comment><USER41> It depends on what language you're using and your requirements, but my preference is Qt. It has bindings to several languages; it supports most common platforms; the API is consistent, stable, and well documented; and it's easy to get up and running on all of the platforms it supports.

One complaint people have about Qt is that it doesn't "look native" enough. That's not something I personally care about, and it's not a problem at all for the applications I write, but it's an issue for some people. IME, that's just a trade off of using a cross-platform GUI library. If the layout is good and it's easy to use, most people won't care if it doesn't look native. Photoshop doesn't "look native" either, yet it has a huge following and brings in a ton of money.

</comment><comment><USER42> My vote is for electron, although I'm following how React Native develops really closely. From what I've seen, the best new "Desktop" apps tend to be built with electron. We've been using it in production and, despite having to make pull requests for framework-level bugs fairly regularly, we've haad a pretty good experience overall, and far better than anything else we've tried - although, as I said, we have yet to seriously look into React Native. Also, by cross-platform I'm assuming you mean OS X, Windows, and Linux. If you also want to include mobile, then there are so few options there's no longer any real reason to debate.

</comment><comment><USER43> I'm barely a geek, let alone a hacker, but have been trying to learn NativeScript for the past month or so. You might want to check it out.

Not sure how it compares as a "library" or "framework" etc. I'm still figuring out where the lines are drawn.

[http://docs.nativescript.org](http://docs.nativescript.org) Emulator Here: [https://docs.genymotion.com](https://docs.genymotion.com)

<comment><AUTHOR> No Javascript, sorry.

</comment></comment><comment><USER44> Depending on the type of UI, you could also give Kivy a try. [https://kivy.org/](https://kivy.org/)

It's python based, and really easy to get going. It does have it's quirks, but overall I found it a joy to use.

<comment><USER45> I've had some hard times porting Kivy to the Raspberry PI 3 on Raspbian. It is a decent toolkit, but I'm not so sure on the ease of cross-platform.

</comment></comment><comment><USER46> Depends on what you're after :)

Electron or QT for cross-desktop apps, Angular & Ion framework for cross- mobile apps, React & React-native for cross-mobile apps

<comment><USER47> There are efforts to bring React Native to desktop but I don't think they are production ready yet.

<comment><USER46> you can get react on desktop with electron

</comment></comment></comment><comment><USER48> There is also swing and javafx if you want to use jvm.

<comment><USER49> JavaFX is amazing, but I'm not sure how it holds up when an app gets complex.

<comment><USER50> I think a bigger problem is that less and less end users have the JVM installed.

<comment><USER34> You can use javapackager.

<comment><USER51> Did you try to using it in production? It's flaky at best...

</comment></comment></comment></comment></comment><comment><USER52> It depends on what you mean by, "cross-platform." In my world there is no such thing. You pick your target platforms and program to them. However it is common to imply "major platforms" (ie: _iOS_ , _Android_ , _Windows 10_ , _OSX_ ). Different platforms have different requirements and will shape your solution.

Next... what is the application? Do you need to target native APIs? Do you have memory limitations?

If you don't mind taking up a lot of memory try one of the "cross platform" systems like Xamarin or some Java-based solution. If you need to be more constrained try writing to the native APIs and porting your project to each target platform you need to target. Lastly if you're highly constrained maybe you need to try an immediate-mode style library like Nuklear[0].

It really depends on your needs. There's no one-size-fits-all.

[0] [https://github.com/vurtun/nuklear](https://github.com/vurtun/nuklear)

<comment><AUTHOR> > there is no such thing

Why?

<comment><USER52> Different platform, different requirements.

If a language run-time or virtual machine promises, "you can write code once and run it anywhere," then they're not telling you the whole story. There's no such thing as, "cross platform." It's just a vague term that is commonly interpreted as, "major OS platforms," or, "most popular mobile platforms," etc.

Requirements are both technical and non-technical. If we just focus on the technical requirements you have to look at the data you're working with, your user, and how the program interacts in this system between the human and the rest of the world. If you're writing safety-critical mobile applications for remote workers that spend a week or more in the field you're probably not going to waste your resources on a memory-hungry VM just so that life is more convenient for you. That's starkly different to prototyping an application in a lab where convenience is paramount compared to cheap resources. I have yet to see any kind of language or run-time that lets you have it both ways.

One may say, "Yes agentultra, but what about generating the code for the highly-constrained environment from the higher-level language?" I love this approach. It's possible to generate _efficient_ code this way. This approach still requires you to understand your target platform well enough to spot bugs in the generated code. So while it may be an approach to gain some leverage as a single developer or small team; you're still quite constrained but this DSL... the same code written for the DSL is not likely going to run well or even be considered for use by your other target platforms.

I haven't yet found a way to "escape" the reality that different combinations of hardware and OSs require different solutions for different applications. It may seem like "all you need is Java" or X, Y, or Z -- but the reality is more nuanced than that.

<comment><AUTHOR> > I have yet to see any kind of language or run-time that lets you have it > both ways.

If there were such a language I wouldn't be asking this question on HN. I have yet to see a clear answer _why_ there is no such kind of language or run-time.

> the same code written for the DSL is not likely going to run well or even be > considered for use by your other target platforms.

Why? Can be you more specific with an example?

<comment><USER52> > I have yet to see a clear answer why there is no such kind of language or > run-time.

... I'm having trouble not being glib in my response. I want to say, _because computers_. But let's be a little hand-wavey for a moment.

As programmers we sometimes put too much faith in our poorly-thought-out abstractions. We think, "why is there not a library/runtime/VM that abstracts away all of these painful, tedious details? Surely someone must've invented a GUI library that runs on all platforms, perfectly." We look for ways to avoid the difficulty of thinking too hard about it. We just want to write an application and not think about operating systems, hardware architectures, memory allocation, etc, etc.

Well there are systems that do remove some of the effort in writing such applications. They will manage memory for you, abstract away the differences in various operating systems, and they might even provide a common library for writing a GUI that works across all of the platforms that the VM/runtime supports... this is a great tool to have.

However it has a cost. It has it's own memory model. It makes assumptions about what GUI interfaces are. It targets the common denominator between operating systems. It is, by necessity, quite complex on the inside... so as long as you can sit comfortably in the box and write programs that the system expects you to write you can safely ignore the hairy details of allocating memory, making system calls, managing resources, etc.

But if your application requirements pull you out of that comfort zone be prepared to have to deal with garbage collection algorithms and mapping your application's data to the runtime's model. That has a cost.

For some applications that cost isn't worth it or even feasible. How much battery power are you willing to consume? How many updates to the simulation can you make per second? How fast do you have to stream that data of the disk to this other component?

These languages and runtimes that claim to be "cross platform" are really just selling you a subset of functionality on a subset of platforms that you may or may not care about. It's never what you intuitively assume it to mean, "write once, run everywhere."

> Why? Can be you more specific with an example?

I wrote a 6502 assembler in Common Lisp many moons ago. With it I was able to write applications for that processor in a high-level language with all of the Common Lisp tools I was used to. However that DSL was restricted to that platform backend.

Had I a requirement to target another platform, say x86_64, I would have to write another backend for my high-level DSL and introduce plumbing to my build tools to produce the executable code for either platform. Great! Cross platform code!

Well... not _really_. I still had to write two different backends. And I can't really exploit the unique features of either. I can only really make use of the common denominator between both or else emulate features of one in the other at the expense of making one platform less performant/useful than another.

There's no such thing as "cross platform." It's just a marketing buzz-word. There are hardware platforms. There are operating systems. These are the things we program.

Abstractions are great but they're not free and they don't free you from thinking. It's an easy mistake to make because it comes so naturally to us humans -- we hate doing things that are difficult. But there's nothing natural about programming. It's hard.

</comment></comment></comment></comment></comment><comment><USER53> A few other people have mentioned JavaScript and HTML but in my experience HTML and CSS support varies wildly between platforms and as applications become larger it is difficult to tune the performance of your running application. Also the implementation of the base code for HTML tags and what CSS properties can do are inaccessible to JavaScript making many task much harder than they would be in other environments where you can simply extend or introspect the internals.

But if you want something to run everywhere including web browsers, JavaScript is the only realistic option. So we make do. My current approach is to rely on HTML/CSS and React/React Native for the easy stuff and everything else is rendered in the Canvas tag with lots of JavaScript to bend the platforms into doing what you want.

In the past I have taken similar approaches by using things like Ejecta but the android support for this is lacking and now that WKWebView has addressed many of its issues, using standard WebViews within native containers is fast enough on mobile.

On desktop, Electron, NW or the other things like this can fulfill the same setup.

People will complain about performance which was a really big issues a few years ago but today the difference isn't large enough that it can't be worked around and most of the fear is in people heads. Most environments have web workers, and webgl, and JavaScript that has a JIT, and many new things like Web Assembly and SIMD should be available in the coming years making these platforms even more viable.

</comment><comment><USER54> Not a library per se, but HTML+CSS+JS. Bootstrap or some other mobile responsive framework. Works on just about every device&OS. Phone gap or similar if you really need native.

<comment><USER55> +1, because I had the urge to say the same thing.

I think the question needs to be a lot more specific about the type of app and the platforms it needs to run on. Web-based applications give you the broadest reach for the lowest cost if you can assume internet connectivity and if the GUI that's possible from within the browser sandbox is sufficient for your needs. (Capabilities are growing all the time, but it's still not the same as native.) If your app needs to be offline, it's still possible with web tech but it's harder to justify, unless you're doing a hybrid of online and offline and the online part isn't just service calls.

</comment></comment><comment><USER56> GTK may have a difficult API, but it is portable and it gives a better feel than Qt for Linux+Gnome users like me (I will always choose a GTK app over a Qt app).

<comment><USER4> GTK's documentation is atrocious for anything in depth, and has been for years.

Saying that from wrongly choosing it over Qt for a cross platform screenrecording/annotation project a few years ago.

There's literally no way in hell to recommend GTK for any new desktop project that likely has a Windows audience. GTK is a mess. :(

<comment><AUTHOR> @geraldcombs and @justinclift I didn't know any of this, thanks so much!

It sounds like GTK is eliminated too.

What's left now, QT and wxWidgets?

<comment><USER4> If you're looking to do a desktop GUI type of application, then those two are decent choices.

If you have skill in C++ already, then Qt is a natural fit there. Also, Qt's docs are _very good_. None of the "oh, I was advised to use this class. Where are the docs? What do you mean... go read the source code?".

Gah... sorry... still haven't gotten my __extremely bad __experiences with Gtk out of my system (years later). ;)

If I were doing a desktop GUI type app again, I'd choose Qt for sure. Good docs, very large user base, actively helpful Community on IRC. (I'm not really a forums guy). Plus, bunches of Qt code (of various quality) on GitHub for getting ideas from.

Hope that's useful. :)

<comment><AUTHOR> There seems to be a third choice though. Writing a "thin layer", which sounds like writing one's own wxWindows or QT.

I want to know the difference between the thin layer and the existing libraries. Not in vague terms but specifically with a code example.

<comment><USER4> Hmmm, on first thought, writing "thin layer" sounds like a potential boondoggle.

But then again, it's not something I've personally tried (nor needed), so that might be an inaccurate assessment.

If you don't need a full/complete GUI stack (and other related bits) implementation for your application, then yeah, it might be the way to go.

</comment></comment></comment></comment></comment></comment><comment><USER57> I'll throw in a mention for Xojo:

[http://www.xojo.com](http://www.xojo.com)

Xojo used to be called REALbasic, and it's a cross-platform 'Visual Basic' with support for Windows, Mac, Linux, iOS and Raspberry Pi. I tend to use it for internal tools that need to run on both Windows & Mac, and find it's great for getting to a prototype stage very quickly.

<comment><AUTHOR> Is it open-source?

What I want is closer to writing my own Xojo.

<comment><USER57> Xojo isn't open source, but I think Lazarus is. It's an open source cross- platform version of Delphi, which could be described as "Visual Pascal". I've not used Lazarus myself but I used to use Delphi.

[http://www.lazarus-ide.org](http://www.lazarus-ide.org)

</comment></comment></comment><comment><USER58> I like Xwt: [https://github.com/mono/xwt](https://github.com/mono/xwt)

Used it for the TrueCraft launcher: [https://github.com/SirCmpwn/TrueCraft/tree/master/TrueCraft....](https://github.com/SirCmpwn/TrueCraft/tree/master/TrueCraft.Launcher)

</comment><comment><USER59> It depends on what you need.

In the past we used GTK and wxwidgets with OpenGL but we did not like it.

We started using Qt, much better(proper object oriented by design, and cleaner design than wxwidgets) and web apps. Now we use native libs with our own multiplattform lib with bindings for each plattform:

-javascript for the web.

-native cocoa and windows libs, with openGL, metal and directX.

-Qt for linux with OpenGL.

\- Native mac(iOS and cocoa) and windows.

</comment><comment><USER60> There's a lot of great web-tech based solutions. Other commentors are covering those, so I'll suggest something different: For a take outside of the web, Golang with OpenGL bindings has a lot of promise for shipping $everywhere.

The [https://github.com/go-gl](https://github.com/go-gl) github org has repos with comprehensive pre-generated OpenGL linking. When building off these, you need almost zero interaction with any host libraries. Cross compiling is a _breeze_. I made a demo application on Linux one afternoon to try it out: I was able to hand the code to a friend with a Mac, and he compiled and ran it _first try_. It's hard to understate the level of "wow" there.

Golang+GL also ships to mobile devices. There's a little squeeze dealing with the app stores, but fundamentally, build on GLES2 and you can go anywhere.

[https://github.com/google/gxui/](https://github.com/google/gxui/) is one library on top of these foundations that went all the way to providing ( _beautiful!_ ) cross-platform widgets that can be used to quickly build a desktop application.

Unfortunately, gxui, though a very attractive proof of concept, is now unmaintained. (At the same time, it's worth mentioning that _it still works_ ; there's no insane deprecation schedule or fast-moving/fast-breaking libraries to wreck your day here.) If anyone Out There is interested in renewing this project or starting more frameworks like this, I'd love to collaborate.

Overall, there's work to do here, but if you have some appetite for cutting edge, the foundation is in place to nail portability properly.

Finally, this is unrelated, but I feel compelled to give an anti-pitch to pretty much everything in C/C++ ecosystem of GUI tools: it's a landscape of last decade's promises, and today's despair. I've had comrades complain bitterly over time they've spent in codebases where the wxwidget string objects got out of hand. I have a half dozen applications suffering from various C++ linker hells on my various computers and can't recommend QT with a straight face. I _still_ haven't gotten all my gtk3 and gtk2 configs to line up on my last debian reinstall and all the font sizes are fragged on the computer for no known reason (I literally the gtk configs in my dotfiles in git; I can't imagine how different machines drift)... And I haven't even said a word about build and shipping infrastructure required to really tackle cross-platform. I'll say it again: _the entire C /C++ ecosystem of GUI tools is a landscape of despair_.

</comment><comment> c-smile [http://sciter.com](http://sciter.com)

Embeddable HTML/CSS UI engine designed specifically for desktop UIs.

The "Embeddable" here means that: \- it is a compact (3...4mb) monolithic DLL/dylib/so without external dependencies. \- can be linked statically if needed. \- has simple plain C API of 20-30 functions - C++,C#,Rust,Go,Delphi,Python wrappers.

Same UI resources are used on all platforms: [http://sciter.com/images/sciter- clock.png](http://sciter.com/images/sciter-clock.png)

Check technology introduction article:

[http://www.codeproject.com/Articles/859098/Sciter- multiplatf...](http://www.codeproject.com/Articles/859098/Sciter- multiplatform-embeddable-HTML-CSS-scripting)

</comment><comment><USER61> Which one has the best tutorial so a wanna-be can get started ? Usually, to me, the 'best' tutorials have the most examples. (Yes, an example is worth a thousand words) (I'd want to be starting on Ubuntu, with Python 3)

</comment><comment><USER62> The choice of the UI library depends a lot on the type of app you're developing. For many types of apps, a single page HTML/JS/CSS app bundled as an executable is the best choice.

If your app will do a lot with the hardware (sound, video, networking,...), then you should look at native libraries for cross-platform hardware access and UI (though HTML/JS/CSS based UIs with native core are also possible).

In my experience, making a good "cross-platform" UI can be tricky, especially if your platforms include both desktop and mobile.

The reason is that each platform has it's own set of features, limitations and design requirements, which you either have to emulate, ignore or implement as platform-specific modules.

Most UI libraries implement their own windowing systems which makes it possible to have an app that behaves similarly on all platforms.

The drawback is that the app looks and feels 'cooked' \- things aren't quite standard, animations are a bit off, fonts are rendered differently, etc.

One such example is Qt, which has been mentioned many times here. It is probably the best choice if pixel perfection and native look/feel isn't your primary requirement. With a bit of work you could probably achieve native 'perfection' with it too.

If you work with sound, then you should take a good look at JUCE - it has a very pleasant API, has a low overhead and a very friendly community.

That being said, the best choice IMHO is to develop native UIs for each platform or at least for the mobile versions of your app.

The trick is to separate your design into "core" and "ui" parts. The core is a cross platform C++ library, which implements all the business logic and low level hardware access, exposing an API to the UI layer.

The UI is then implemented in Qt/JUCE for the desktop apps, Objective-C++ and Swift for iOS (and OSX if you want) and Java+JNI on Android.

The advantage of this method is that it forces you to have clear separation of concerns between the core business and UI layers and you can have different people working on the core and the specific platform UIs.

The ultimate advantage is of course your user's experience - native apps are more gratifying.

It might sound like a lot more work, but it's usually not as bad as it sounds - if you have a well designed core API, the UI is just a visual representation of your application state, which is not that difficult to implement on each platform.

In the end, personal preference and tastes also matter - use whatever makes you (and your team) feel more comfortable. Good luck !

</comment><comment><USER63> I'm just going to come out and say The Web. Stick WebViews in your app and if you need some native API use a bridge (like PhoneGap).

By itself you can already have tons and tons of great UI components that work cross platform.

But if you want a web based library specifically designed to present a common interface tailored to each device (desktop, tablet and mobile) and taking advantage of its unique characteristics, use our open source one:

[http://qbix.com/platform](http://qbix.com/platform)

<comment><USER63> Just out of curiosity, why did you downvote this? You don't think the Web is a good platform for UI or you don't like that I linked to our library built on top of it that we open sourced for UI?

<comment><USER64> Didn't downvote but... At the very least, a suggestion for a cross platform library for "sticking webviews to your app" would be needed to answer OP's question.

</comment></comment></comment><comment><USER65> Here's what I use to develop Mutator's [0] and TestLess' [1] GUIs: \- implement in Ruby \- compile to Java using Warbler/JRuby \- Run as Java on any platform that supports Java.

You can use javafx or swing, although javafx needs certain combination of warbler and jruby to work.

[0] [http://ortask.com/mutator/](http://ortask.com/mutator/)

[1] [http://ortask.com/testless/](http://ortask.com/testless/)

</comment><comment><USER66> I've been going the other direction recently. We have a photoshop plugin that exports layers with metadata (where an image is located, fonts, font sizes, text, etc). For any platform that has a basic scene graph and some sort of label functionality (Unity, iOS, android, theoretically even web) we write a runtime that converts the metadata into runtime UIs.

So it ends up being custom logic for interaction on each platform, but the design/assets can be shared cross-platform.

</comment><comment><USER20> You might have to define which platforms you want or need to target. There is a difference between just writing a desktop application that should work on Windows and Mac, an app that should work on iPhone and Android and a solution that needs to work on all of the above plus Linux desktops and Windows Phones and web browsers. [edit: spelling]

</comment><comment><USER67> You can have your cake and eat it too. If you have to build a native desktop app, you can use Chromium Embedded Framework. Spotify is one of its biggest users. You can still build your UI in HTML but drive it with native code (C++, Objective-C, C#, etc). We used CEF when we realized how painful Win32 C++ WTL desktop UI was.

</comment><comment><USER68> SWT rarely gets any love in desktop UI threads around here, but I recently wrote a small desktop program using SWT and Java and found it to be a reasonably pleasant experience. The main purpose of the program was to allow the user to view a couple of database tables, and using a tree view widget with columns was a key requirement. SWT is the widget toolkit used by Eclipse and is mostly native, using GTK on Linux, Cocoa on macOS and the Win32 API on Windows. It is still in active development, and support for HiDpi was recently added.

I started off with an Angular 1 app using Dropwizard for the backend. But I was frustrated with (1) the incidental complexity needed to use a decent tree view widget with sorting, filtering, pagination, etc. and (2) the slow response time of having to go from the web page, to the backend server, to the database and then back again.

Around that time, I ran across a Java Swing app written by another group and was surprised about how fast it was to start up and to access and display info from a database. Since it used Swing though, the fonts under Red Hat 6 were terrible. Since I already had most of the "business logic" in Java, it was straightforward to quickly prototype a viewer using the SWT/JFace tree viewer. It was fast to start up, and the fonts looked decent since it was using native GTK2. I dropped the Angular stuff and coded the program in SWT and it has been well received by my coworkers.

I'm a big believer in using native widgets to the extent possible, which SWT does. For the tree view widget, for example, it uses GTKTreeView for Linux and NSOutlineView for macOS. For Win32, there is not a native tree view widget with columns; SWT uses the native Tree widget and draws the columns itself. Qt on the other hand emulates a treeview widget on macOS for example and does not use NSOutlineView.

There is occasionally a least-common-denominator issue when using SWT. For example, I wanted to use tab widgets that have close buttons on the tab like web browsers do. The native Win32 and Cocoa tab controls do not provide for close buttons, so I had to use an SWT provided tab widget that is not native at all. Doesn't look great, especially on the Mac, but it's fine.

The SWT API is dated, as it comes from the early 2000's, but it seems straightforward and I rarely find myself surprised. Getting the GridLayout to do what I wanted was probably the trickiest part. There are examples to follow on the web. It does not have the kitchen sink aspect that Qt and WxWidgets have, since Java is there to provide the networking and database access, etc. Java 8 cleans up a lot of the issues with having to use anonymous inner classes everywhere in favor of lambdas, and if Java is not your cup of coffee then SWT is usable from other JVM languages.

Deploying the program works ok. For macOS and Windows, I package it up with its own JRE. I do face the issue of the best way for end users to update the program easily. I haven't found an easy to use update package like Sparkle on macOS that works for cross desktop platform Java apps. I'm contemplating turning my program in to a full Eclipse RCP program to take advantage of that framework's built in update facility, but the learning curve seems daunting. And I'm a big fan of Intellij IDEA for Java development, and don't want to use Eclipse. :-)

<comment><USER69> To be fair, I feel like most people either would rather not use Java (I know, I know, it's unreasonable considering the language has become much more idiomatic and the tooling is great) or they just associate Java with huge backend, WebSphere kind of projects.

In a way, Java is a victim of its own success.

</comment></comment><comment><USER70> Adobe AIR - much as people like to hate on flash, Adobe AIR kicks ass as a cross platform UI. It has years of use and abuse.

Its one downside is if you need really low level hardware interaction with OS you have to use an ANE library which are sometimes great, and sometimes sketchy.

</comment><comment><USER71> Electron shell without a doubt. HTMl is so fluid and extensionable that it is hard to beat. It doesn't work on mobile however. Also it isn't as fast as c native but you use node js which is greater than pure js for obvious reasons.

</comment><comment><USER72> I'd probably use Electron and/or SWT along with javascript and kotlin.

</comment><comment><USER73> QT!

<comment><USER74> Not QT, it is Qt.

<comment><USER75> No idea why you're being downvoted.

QT refers to Apple's Quick Time.

Qt refers to the Qt project, pronounced 'cute'.

</comment></comment></comment><comment><USER76> I like JUCE. [http://www.juce.com/](http://www.juce.com/) It's used for a lot of audio apps and plugins but lots beyond that too.

<comment><USER77> JUCE is all that and a bag of chips. It is a perfectly capable competitor to QT, yet also has fantastic multimedia APIs. Docs are excellent. Source is ultra clear.

</comment></comment><comment><USER78> Electron I would say. You make your UI's using HTML and CSS, it looks the same everywhere. Not bad, I guess although it does have it performance issues.

Atom for example is built with Electron.

</comment><comment><USER79> I have used Electron previously, but now Ionic is my favorite [http://ionicframework.com/](http://ionicframework.com/)

<comment><USER80> Electron is desktop only and Ionic is mobile only; you can't really compare them as there is never a choice between them.

<comment><USER81> Ionic 2 supports (or intends to support) Electron, desktop web and progressive web apps: [http://blog.ionic.io/announcing- ionic-2-beta-7/](http://blog.ionic.io/announcing-ionic-2-beta-7/)

</comment></comment></comment><comment><USER82> There is Livecode (livecode.org). Does anyone have experience using it in production? It's cross-platform and has both commercial and open source (community) versions.

<comment><USER83> I like it for prototyping. I have done some real client projects with it and it does work well and fast. Especially for apps that either require a custom UI or not too polished at all.

</comment></comment><comment><USER84> Qt with no hesitation. It works everywhere.

</comment><comment><USER85> I'm surprised nobody has mentioned Angular 2 yet. It's new, so don't expect tons of support. Nonetheless, it's there as an option!

<comment><USER86> Probably because you didn't read the OP's explanation of minimum standards that included.

> \- I won't use the web. No HTML, no CSS, no Javascript. Sorry.

If you're using HTML, you're already limited in known ways. Conflaguration of logic with presentation and callback hells and limitations of CSS extensions by platform. Then the there's the need to split HTML views due to technical limitations and practicality of maintenance adding a whole new layer of complexity in view and view fragment management!

</comment></comment><comment><USER84> Qt with no hésitation. Works everywhere.

</comment><comment><USER87> Motif. >:]

</comment><comment><USER88> The best one I know is html 5

</comment><comment><USER89> I see nobody mentioned Juce. It is pretty neat if you like C++

<comment><USER90> JUCE is a great framework, has a very commendable coding style and is easy to get into. One thing to note is that the "JUCE way" of doing things is to have a UI that looks exactly the same on every platform - this is good for predictability, but if you want a UI that looks _native_ , you're better off using Qt or wxWidgets (as C++ UI toolkits go).

In many cases I'd say that's not an issue, and JUCE is underrated/underused as a general-purpose UI toolkit.

<comment><USER91> _commendable coding style_

Please explain!

<comment><USER90> Well, commendable means "deserving praise", and when working with it, I generally appreciated the simplicity, consistency, and clarity I found throughout the JUCE codebase.

It also encourages you to adopt a coding style that's consistent with the rest of JUCE, particularly in terms of memory management. This is one of the things that makes it a lot more "framework" than "library", and again might not be for everyone. Take a look at the "Object lifetime and ownership" section in this page:

[https://www.juce.com/learn/coding- standards](https://www.juce.com/learn/coding-standards)

</comment></comment></comment></comment><comment><USER92> Why isn't anyone here mentioning Xamarin + GTK#?

<comment><USER7> You just mentioned them. You could elaborate what makes them worthwhile your endorsement...

</comment></comment><comment><USER93> Qt obviously, but beware of licencing

<comment><USER94> Obsolete. Nowadays qt libs are distributed on choice between commercial and lgpl

<comment><USER93> Don't you have to release the source code of your application if you don't want to pay?

<comment><USER95> No. That's GPL, not LGPL.

</comment></comment></comment></comment><comment><USER96> The internet.</comment>


The Nixon Shock. How Nixon stopped backing the dollar with gold - <AUTHOR> http://www.businessweek.com/magazine/the-nixon-shock-08042011.html

<comment><USER2> Please, Obi Wan, save us from the gold standard discussions, you are our only hope.

<comment><AUTHOR> I can understand this fear. Gold standard discussions are usually extremely dull and turn religious in no time.

But the article describes the political context, people and decision-making of this historic event. Much was guided by thought of TV audience response and the next election result. Those concerns are not necessarily the best ones to build a financial system on. Still this is what shaped the decision.

<comment><USER2> Maybe someone should go build an Econ News, so we can send people there to bludgeon each other about the same topics over and over again, and we can stick to startups, hacking, and random, interesting, non-political articles.

</comment></comment></comment><comment><USER3> Single page link: [http://www.businessweek.com/printer/magazine/the-nixon- shock...](http://www.businessweek.com/printer/magazine/the-nixon- shock-08042011.html)

</comment><comment><USER4> I thought gold stopped backing up the dollar in the 1930s, just after the great depression?</comment>


Let Me Google That For You: Better than a Screencast - <AUTHOR> http://jamtoday.org/post/60593356/better-than-a-screencast

<comment><USER2> It's dead.</comment>


HNHiring.me: A pleasant interface for the monthly hiring posts - <AUTHOR> http://hnhiring.me <comment><USER2> I like the idea, but I disagree that this is a pleasant interface.

There's a lot of repetition -- maybe it's just me, but I'd rather have the jobs separated by Fulltime/Freelancer first and then by month, so you'd only have two tabs at the left with a list of months under that tab.

I also like the Regex search so I can do some complex searches, but I wish there was some basic functions built in -- Like pulling out City/State when applicable.

      ([^,]+),\s*(\w{2})\s*

Matches a City, ST

<comment><USER3> (+1) that's about as far from 'pleasant' as you can get, IMO

<comment><USER4> Strongly disagree. It may not be perfect, but it certainly is more pleasant than the native view on HN.

</comment></comment></comment><comment><USER5> An alternative to this is my site UseTheSource where your Hacker News karma gives you the right to post jobs.

<http://jobs.usethesource.com/>

<comment><USER6> It would be nice if people could also post "looking for work" posts.

</comment></comment><comment><USER7> Not to be that guy, but a lot of people have been requesting features such as being able to search by city, intern/remote and all that.

My friend & I built <http://supzu.cc> earlier this month and it has most of these features. Maybe that can scratch some people's itch.

It's missing a lot of stuff that this wonderful version has such as support for freelancers among other things. We posted it when we made it but it never got much attention so there's obviously a reason for that :).

<comment><USER8> I also built something similar recently <http://fit.io>

Amazing how an idea can be implemented by a bunch of different folks all at the same time.

</comment></comment><comment><USER9> Not sure what's going on in the background, but it's impossible to scroll the right column on the iPhone. Very laggy.

<comment><USER10> It's a webkit bug:

<http://www.quirksmode.org/css/overflow.html>

On the iphone, you can use a two-finger drag to scroll.

</comment></comment><comment><USER11> Hehe, looks like a lot of us have built interfaces for HN threads.

I built one last month for the Freelancing thread: <http://hnfreelancer.zacharytong.com/>

</comment><comment><USER12> No-one else has pointed this out yet, apparently, but I just got my mind blown by one little UI decision -- clicking toward either the upper or lower part of the content body, it scrolls to that direction. Wonderful, and very impressive. So obvious, and yet so brilliant.

<comment><USER10> It doesn't appear to be based on where you click on the page. It's whether you click on a post/listing. Without looking at the code, it probably performs a jquery scrollTo on click of any listing.

</comment></comment><comment><USER13> I found it slightly annoying that each of my clicks automatically scrolled through the posts. This included any middle-clicks used to open a link in a new tab.

</comment><comment><USER14> Really useful, any plans on adding RSS/Atom feed? I saw it's implemented in JavaScript and I don't know if there's an easy way to do such thing. Good job.

</comment><comment><USER15> Might want to add / in the shortcuts to go in the search. Good initiative!

</comment><comment><USER16> Love it, great interface and very useful. Keep up the good work.

</comment><comment><USER17> good idea. I think it really needs a built-in filter to exclude all the SEEKING WORK posts though because job hunters (most users) have no desire to see those.

</comment><comment><USER18> Any plans for an intern tab? That would be pretty useful :)

</comment><comment><USER19> I often find your site in my referers

</comment><comment><USER20> Great!</comment>


Our best chance for civil discourse online is on Reddit - <AUTHOR> https://www.wired.com/story/free-speech-issue-reddit-change-my-view/ <comment><USER2> This one particular subreddit, perhaps. The rest of reddit where 99.9% of the discussion happens? Absolutely not.</comment>


Show HN: A partial clone of the Dots game in JavaScript - <AUTHOR> http://viniciuspinto.github.io/pontos/

<comment><USER2> I liked it!

How about leaderboards? :)</comment>


BASH3 Boilerplate – Templates for writing better Bash scripts - <AUTHOR> http://bash3boilerplate.sh/ <comment><USER2> This is actually quite good code. Thanks for the post</comment>


Venture Capital Investing Hits 11-Year Low In 1st Quarter - <AUTHOR> http://online.wsj.com/article/BT-CO-20090418-700002.html

<comment><USER2> For those not subscribed to the WSJ, you can read the whole article by clicking through a google search.[1]

As for the article itself, the numbers do seem quite troubling for companies looking for VC money. On the other hand, from the trends I'm seeing in the web community, more and more entrepreneurs are bootstrapping their companies.

I wonder which side the causation lies on.

[1] [http://www.google.com/search?q=%22Canaan+Partners+said+he+th...](http://www.google.com/search?q=%22Canaan+Partners+said+he+thinks%22)

<comment><USER3> Whichever side causation lies on, the VC as a whole will lose more (have less to gain) than the entrepreneur as a whole.</comment></comment>


Ex-Googlers penetrating Silicon Valley startup hierarchy - <AUTHOR> http://www.mercurynews.com/top-stories/ci_17574915?nclick_check=1

<comment><USER2> I think one of the biggest obstacles to the formation of a "Google mafia" on par with the PayPal mafia is that by-and-large, Googlers don't want to leave. Many of the key figures in the development of the search engine are still working on search, in high-up leadership positions. Googlers generally have a fair bit of latitude to pick their projects, so if they don't like what they're doing, they can do something else within the company instead of leaving and taking on the risk of founding a company.

Contrast that to PayPal, where _the whole company_ was bought by a big, established competitor, one that they'd roundly trounced in the marketplace beforehand. Of course a lot of the employees will leave - the culture of a place usually completely changes after an acquisition.

<comment><USER3> There are a LOT of ex-googles startups out there. Not a huge number of successful ones but they are around.

<comment><USER4> I'd be curious to know how many of those ex-Googler startups were founded by xooglers that were first-100 employees. Any "startup mafia" would seem to be made up mostly from people in that group.

<comment><USER5> At least one startup comes to mind to qualify under that criterion, Friendfeed (Paul Buchheit).

</comment></comment></comment></comment><comment><USER6> I find it a bit amusing that articles of this sort only evaluate people's most recent pre-startup employment. Sure, the Beluga folk previously were at Google. Two of the three started at Microsoft after college, however -- I worked with them both bac then. Of those two one went straight from MS to Google; the other had a more complicated path.

</comment><comment><USER7> There were only a handful of Paypal founders and virtually all were extremely successful. There were 3,021 pre-IPO Google employees [1]. Seems like an unfair comparison.

[1] <http://en.wikipedia.org/wiki/History_of_Google>

</comment><comment><USER3> No we aren't.

(I am an investor in both Weatherbill and Optimizely. Hmm.)</comment>


Health care law's hidden tax change to launch 1099 avalanche - <AUTHOR> http://money.cnn.com/2010/05/05/smallbusiness/1099_health_care_tax_change/?hpt=C2

<comment><AUTHOR> Previously people had asked for a more ... mainstream source about this onerous change.

Note that collecting the info necessary to send out these 1099s is going to cost a _lot_ (e.g. you need the recipients Tax Identification Number <http://en.wikipedia.org/wiki/Tax_identification_number>).

Lots of commentary at the TaxProf Blog [http://taxprof.typepad.com/taxprof_blog/2010/05/cnn- health.h...](http://taxprof.typepad.com/taxprof_blog/2010/05/cnn-health.html)</comment>


Getting Started With Competitor Research - <AUTHOR> http://www.onwardly.com/getting-started-with-competitor-research

<comment><USER2> If they use GetSatisfaction or UserVoice, click through to their community. If they have any traction at all, you'll find a bunch of feature requests, how popular those requests are and how they responded.</comment>


Hacker writes a script to flood phone lines of telephone scammers [video] - <AUTHOR> https://www.youtube.com/watch?v=EzedMdx6QG4 <comment><USER2> This is beautiful.

</comment><comment><USER3> What service allows you to make 28 calls/second and not be tracked back?

<comment><USER4> He's just using twillio</comment></comment>


Heirloom Chemistry Set - <AUTHOR> http://www.kickstarter.com/projects/1742632993/heirloom-chemistry-set <comment><USER2> As a resident of Kansas City and having visited John's store many times, I can tell you that this guys is amazing. He does hands on classes for kids (minimum age 7) on chemistry, archaeology, botany, geology, robotics/ electronics, wood working, etc. Just like this kit; he doesn't dumb down anything.

I turn into a kid every time I go into his store.

<comment><USER3> Indeed; I tend not to find too many kickstarter projects that I'm interested in, but as I continued to read this one I continued to be impressed. John obviously has a gift for bringing sciences to the masses.

My favorite is the "spitfire kit": "Each kit will allow users to kindle a ...fire... by using two chemicals and a drop of spit."

Brilliant.

</comment></comment><comment><USER4> I see a lot of reactionism on this thread regarding "kids and chemistry sets". I agree but disagree. With the right supervision, it's awesome. The latter is key.

I had multiple chemistry sets and am not dead and have all my fingers. In fact I was always, with the aid of reference books, mixing various things together purchased from every day shops, purchasing piles of fireworks and doing things frowned upon.

At my secondary school in the early 1990's we were allowed to help ourselves to stuff in the chemical larder as long as we told them what it was for and did the lab safety test first. It was stuffed full of small chunks of Uranium, sodium (under oil) and all sorts of nasty shit that could easily kill you without much notice.

Inevitably we passed that as too dangerous and proceeded to stock up on fumic nitric acid, formaldehyde and ammonia. This was done with supervision.

About two hours later, in a fume cupboard, we had 50g of RDX (C4 precursor) which was considerably more dangerous than the above. We carried this in a metal flask on a public bus to local GSK labs where they did NMR spectroscopy on it. People were interested and quite helpful there. Then we took it to the school field and blew 10g of it up with a magnesium taper. The rest was disposed of by the lab techns (probably by doing the same because they were slightly nuts).

We extracted Aspirin from willow, made RDX, various plastics, thermite, did glasswork, extracted our own DNA, made fireworks and countless other things I can't remember now that were cool.

Now we would be branded terrorists.

Chemistry was awesome and no one was hurt. My understanding for the universe from a physics and chemistry perspective is pretty good due to this.

I would buy this chemistry set in a second.

<comment><USER5> I recall lighting the dinning room table on fire with one of these. Yet... I too still have all my fingers. Luckily my grandmother was over that day to put out the fire before the house burned. Supervision is a good idea.

<comment><USER4> At the age of 8, my grandmother gave me a box of matches, some newspaper and told me to play in the garden. Shortly afterwards her shed and fence were well on their way to being no more and I knew how quickly fire spread. Couldn't agree more.

</comment></comment></comment><comment><USER6> As a synthetic chemist, it really surprised me to see carbon tetrachloride featured prominently in one of the pictures on kickstarter. The use of this chemical is essentially nonexistent anymore due to its toxicity, carcinogenic properties, and danger to the environment. I'm all for letting kids learn with all manner of chemicals, but why bother with one that both academia and industry have essentially deprecated?

<comment><USER7> Yup. As lovable as John is and how cool the product seems at first... The truth is that the business model is extremely vulnerable on many fronts including: liability, copy-ability and efficient manufacturing.

The first suburbanite kid that may choose any of these fun adventures including: building a bomb, burns down the house with thermite or just turns their parents backyard into a superfund site will have their lawyers put John throughly out of business with legal costs and damages that no one will ever offer this kind of product again. [1] And that is before the CSPC decides which wheel of punishment to spin today.

And, I don't see a fume hood; or solid and liquid waste disposal instructions.

The next point is I don't hear about any design patents, so Joe's Evil Scientist Chemistry Set could be produced. Even if someone doesn't personally believe in patents, they still exist and are very much enforced.

If John gets thousands of orders how, when and where take on all the growing pains, not just cutting out panels. Unless John is an industrial process engineering genius, Asian manufacturers could do this for 1/10 of cost and in 1/5 the time.

Conclusion: All the best. Good luck, John.

[1] [http://www.rsc.org/chemistryworld/issues/2007/december/thech...](http://www.rsc.org/chemistryworld/issues/2007/december/thechemistrysetgeneration.asp)

<comment><USER8> Why does he need to have a "business model"? This isn't a startup. This appears to be essentially a hobby business; something that can be sustainable for a single person and maybe a few employees but not something that can scale considerably. By using CNC routing to cut out the boxes, it can scale beyond what he could cut by hand, and thus he can offer a Kickstarter, but this doesn't really appear to be something that he's intending to scale up beyond the Kickstarter, just a way for him to be able to sell some of his sets to people who wouldn't be able to go there in person and buy them directly from him.

The liability concern is greater. He can personally talk to those who walk into his store about safety; less so those who order this over the internet. No one is going to be building a bomb however; all of these samples are in quantities of 30 ml or less. That's less than the 3 liquid ounces you're allowed to bring on a plane, and that limit was set because you can't actually build anything all that destructive with only a few ounces of material.

I'm not sure how you are determining that there are no solid or liquid disposal instructions; did he post the contents of everything that will be included?

Who cares about patents here? He's shipping a chemistry set that is identical to one from 1936, plus a couple more that he thinks are useful. How are you going to patent that? It's just a collection of chemicals, and an instruction manual. The patents on producing all of these materials have long since expired. There's nothing patentable here.

And sure, other manufacturers could do this for a fraction of what he's doing. As you point out, there is some liability concern; liability concerns are greater for a larger manufacturer than for him, doing this as part of his hobby business, merely because they are a bigger target. Asian manufacturers would probably have a hell of a time getting this past customs. And again, who cares? If someone else produces an awesome chemistry set, great! The whole point is to teach about chemistry, and get kids engaged by allowing them to experiment and explore rather than swaddling them and protecting them. The point is not to get rich. Despite what you may think reading about lots of startups on Hacker News, some people just desire to do a good job, not to build a scalable business that makes them filthy rich.

So, the two main concerns I see are liability, and his ability to scale if the Kickstarter is wildly more popular than he anticipated. Even if CNC machining the case cuts down on a lot of the labor, assembly and finishing will take time. However, I don't see this as being particularly more risky than the average Kickstarter; in this case, he's already been making these for a while for sale in person, so it's far past the prototype stage that many products do a Kickstarter at.

<comment><USER9> I don't understand the liability issue. He isn't selling it as a toy, it is a science kit. Anyone can walk into any store and buy stuff that is dangerous if ingested or misused... cleaning supplies, cooking knives, etc.

Parents should be responsible for teaching their children how to work with dangerous things that we encounter every day in a safe way. The chemistry set should be used to teach science. I don't see the issue, but I guess I'm not surprised in our litigation happy society.

</comment></comment></comment></comment><comment><USER10> I'd always heard that children's chemistry sets got increasingly dumbed down because of a combination of direct regulation of common chemicals, under the rubric of both the War on Drugs and the War on Terror, and fear of tort liability.

Is that not the case?

<comment><USER11> The image shows sulfuric acid right up front. I can't imagine why they no longer sell those to kids.

However, if you think about it then as long as you provide the proper MSDS data-sheets and get the right waivers signed, providing a one-stop-shop chemistry set for educators/parents makes perfect sense.

<comment><USER12> And Carbon Tetra-chloride! I'm not sure why I would want it, but I know I am going to have it. Do want.

<comment><USER13> That's a very dangerous chemical. I'm not sure i'd want a kid having access to it. I don't think I'd want it in my house. I have no problem with 1 molar sulfuric acid.

<comment><USER14> What's so dangerous about an ounce of it? They used to make fire extinguishers out of glass bulbs of the stuff.

</comment></comment></comment></comment></comment><comment><USER15> > it needs to be noted that some states do frown on its citizens owning > chemical glassware.

Excuse me? _Glassware_?

<comment><USER8> Yes. Texas requires you to have a permit to buy laboratory glassware, under the assumption that if you don't have a permit, you are going to use it to manufacture meth:

[http://www.dps.texas.gov/RegulatoryServices/narcotics/narcpr...](http://www.dps.texas.gov/RegulatoryServices/narcotics/narcprecursor.htm)

That's Texas style freedom for you!

<comment><USER16> As a Brit I'm totally baffled that Texas is happy for its citizens to own guns but baulks at them owing beakers…

…baffled _and_ saddened.

<comment><USER14> Why baffled? Any arguments that you use to prohibit one can just as easily be used to prohibit the other.

When your laws target objects rather than actions, you can't avoid this kind of stupidity.

</comment></comment></comment></comment><comment><USER17> Finally, something "for the children" that I can get behind.

</comment><comment><AUTHOR> Here is a link to the text of the manual that came with the original sets (warning: Comic Sans):

[http://science-notebook.com/gilb-chem01.html](http://science- notebook.com/gilb-chem01.html)

EDIT: Found a PDF as well:

[http://keeline.com/chem/1936-Gilbert_Chemistry_Outfit_Manual...](http://keeline.com/chem/1936-Gilbert_Chemistry_Outfit_Manual_M1706.pdf)

<comment><USER18> The full list of chemicals can be found in the final section of that PDF, excluding the 8 additional mentioned in the Kickstarter.

<comment><USER19> Ah, good. Sulphur, Charcoal and Potassium Nitrate -- the essentials!

</comment></comment></comment><comment><USER20> Maybe I'm part of the problem, but I wouldn't let a kid to play with fully equipped chemistry set without supervision any more than I would let him/her play with loaded gun without supervision. Of course I also think that both activities are fine under supervision.

Anyways, I really really hope that anyone buying this for a kid is also prepared to spend time with the kid.

<comment><USER21> Sometimes you have to let kids shoot themselves in the foot. It teaches character.

<comment><USER22> As long as you are talking metaphorically, yes, I agree.

But there is a certain amount of danger that they'd better avoid. And, the best way to avoid danger is by learning the safety procedures. That kit could be used to make the world much safer (and more interesting) for them, but one can't just give the kit to kids, and letting them loose.

</comment></comment></comment><comment><USER23> I am pretty sure the set pictured would be illegal in the state of Texas without registering with the state. Maybe these laws have changed in the last decade, but they don't allow all manner of glassware.

Yep, here is the list.

(A) a condenser (B) a distilling apparatus (C) a vacuum drier (D) a three-neck or distilling flask (E) a tableting machine (F) an encapsulating machine (G) a filter, Buchner, or separatory funnel

(H) an Erlenmeyer, two-neck, or single-neck flask (I) a round-bottom, Florence, thermometer, or filtering flask (J) a Soxhlet extractor (K) a transformer (L) a flask heater (M) a heating mantel or (N) an adaptor tube

It sucks telling your kid she can't have a chemistry set because of this nonsense.

<comment><USER24> Why not just register it then? (Also, he mentions on his website that he's shipped this set to all 50 states in the past)

</comment></comment><comment><USER25> Wow, I passed through Kansas City a few months ago on a cross-country move and wish I knew about this store (and stopped in). I don't often fund kickstarters, but this one I could get behind –– something about it resonates with me.

</comment><comment><USER26> I purchased one of these years ago from this shop. It didn't come in a nice case or anything, but it contained great glassware and chemicals. It's stayed with me for years now. This is a great shop, and if you're ever in Parkville, MO (in the KC Metro Area), you should definitely check it out. The owners are very nice, and they're shop is full of wonder things.

</comment><comment><USER27> I'm confused - he already has a store, already has demand for this product. There are even comments here from people saying they have already bought this set from this guy. Why does he need Kickstarter? He is not asking us to fund development of a new project, he is asking us to fund his supply chain.

<comment><USER28> He is already making the chemicals but isn't in the business of selling finished kits from his description.

So the difference between making a bunch of bottles of stuff and selling a whole box with various things as shown in the pictures.

</comment></comment><comment><USER29> I had the "plastic version" as a kid (11 years old)... so much fun! I ran all the experiments more than once, and felt like I was really learning something for the first time.

I had to wait till I got into computer science (at 18, pentium 75 era), to re- experience such a wonderful feeling.

</comment><comment><USER30> There is a difference between using a chemistry set to learn something about the world through analytics and creation/change of matter, and to play around with it.

I agree with csmuk wholeheartedly that it is the supervision that counts. A chemistry kit can be a great learning tool, but it is not something that should be taken as a toy to play around.

We all play, make mistakes, and learn due to those mistakes. But with chemistry those mistakes could show in the form of a hospital visit, chemical pollution, or long term poisoning. I had the fortune to survive an explosion in a lab unscathed, and I will not forget the day I saw my collegue burn 2 meters from me.

Proper training in chemistry is important for reasons of safety and for scientific understanding and reasoning. But let us face it, most people do not like chemistry at all in school. But blowing stuff up and making drugs a la Breaking Bad is cool. When I read the words RDX, CCl4, conc. H2SO4, Methylamine - a bit of TiCl4 perhaps - etc in this thread I imagine the kid with sparks in his eyes who wants to blow stuff up on new years eve.

So, how can one include proper attitude towards the materials inside this Chemistry Set without proper supervision?

</comment><comment><USER31> I saw this vintage chemistry set at an antique store in Bisbee, AZ. It includes a booklet called "Senior Chemcraft Experiment Book -- Instructive and Fascinating Chemical Experiments -- The Porter Chemical Company, Hagerstown, Maryland" and something labelled "Bryan Chemical Illustrators -- An Exclusive Chemcraft Feature".

[http://farm6.staticflickr.com/5477/10826914195_23dc191246_h....](http://farm6.staticflickr.com/5477/10826914195_23dc191246_h.jpg) [http://farm6.staticflickr.com/5471/10826917855_dfe388f77c_h....](http://farm6.staticflickr.com/5471/10826917855_dfe388f77c_h.jpg) [http://farm6.staticflickr.com/5478/10826957096_a0eec5199e_h....](http://farm6.staticflickr.com/5478/10826957096_a0eec5199e_h.jpg)

I recall thinking how fun it would be to have that set, as well as how risky it could be. I probably should've bought it.

</comment><comment><USER32> Oh man, this is rather tempting.

<comment><USER24> I took the plunge. This is a once in a lifetime chance for me. I've never seen a chemistry set I've actually been interested in before now (that's in production).

</comment></comment><comment><USER33> Wow - I love this, love both the aims of this project and the look of the finished product. Fantastic stuff!

Can't wait to see one of these recreated next:

[http://www.orau.org/ptp/collection/atomictoys/GilbertU238Lab...](http://www.orau.org/ptp/collection/atomictoys/GilbertU238Lab.htm)

<comment><USER14> The United Nuclear guys could put something like that together. Maybe they'll follow this fellow's example, since it looks like his Kickstarter effort is being well received.

</comment></comment><comment><USER24> This is the chemistry set I've always wished I could find. Growing up I had a huge interest in chemistry, but never got a chance to play with it at all.

</comment><comment><USER34> Feelings of nostalgia are frequently observed in subjects discussing chemistry sets, however this observation may be subject to survivorship bias...

<comment><USER9> True, the millions of children killed by chemistry sets don't live to tell...

</comment></comment><comment><USER35> I just can't help but comment on carbon tetrachloride mentioned below. It has NOT been used in fire extinguishers or any other consumer use for decades. It is one of the chemicals specifically banned for consumer use by the Federal Hazardous Substances Act. There are a number if issues with this kit that are likely to be a big deal someday for this company.

</comment><comment><USER36> Can anyone fill me in on what he is likely using for this: "a "Spit Fire, Save Matches" kit. Each kit will allow users to kindle a minimum of 10 campfires, fireplace fires, or charcoal pits by using two chemicals and a drop of spit." (at the $45 reward level)

</comment><comment><USER37> inches... the box dimensions are given in inches...

</comment><comment><USER38> Only ships to the United States, sadly for me and my son.

<comment><USER39> I'm sure shipping these chemicals internationally is a nightmare.

</comment></comment><comment><USER40> This is so nicely packaged. I am definitely going to snag one up for the sake of curiosity

</comment><comment><USER41> This is so amazing, but probably dangerous.

</comment><comment><USER42> is mercury included?

<comment><USER24> He sells mercury on his site.

</comment></comment><comment><USER43> _Our project 's greatest challenge has been producing the actual sets' boxes exactly to my specifications._

This sentence really rubs me the wrong way. It says to me that they really do not think about the possible consequences of distributing these to unsupervised kids. It's the "I just gave him the gun/alcohol, what he did after that is not my problem" point of view.

I'm not saying that all kids shouldn't have access to fully-loaded chemistry sets, but chemicals should be distributed with forethought, and this guy is clearly not thinking about what harm the chemicals can do. (He's thinking about how to design a nice case.)

<comment><USER44> I think you misinterpreted that section. It's a section all kickstarter campaigns have. Eg video game campaigns don't talk about the dangers of playing video games, they talk about the risks of the not shipping..</comment></comment>