BrowserFS: An in-browser filesystem supports various back ends - <AUTHOR> https://github.com/jvilk/BrowserFS <comment><USER2> In general, projects like these are great — they unify a lot of underlying architecture and, with time, can make them ubiquitous to use. LocalForage[1] is a great example of this, and I would recommend using that over regular local storage for every serious web project.

This project raises my eyebrows at two technical points, though:

There is no mention of "Promise" or "async/await" in the readme. I know the project tries to mirror the current Node filesystem, but that also offers Promises[2] — something I would call the industry standard for writing readable async code these days. Despite being in beta, I would argue that this project should also aim to support Promises over nested callback pyramids as the default pattern.

Secondly, maybe I'm just not familiar with the idea, but I'm very sceptical of the AsyncMirror backend — when you use an asynchronous service synchronously, how do you guarantee all writes are flushed before the user leaves the page?

Other than that, a project of this scale is no small feat, so godspeed to all contributors.

[1] [https://github.com/localForage/localForage](https://github.com/localForage/localForage)

[2] [https://nodejs.org/dist/latest-v10.x/docs/api/fs.html#fs_fs_...](https://nodejs.org/dist/latest-v10.x/docs/api/fs.html#fs_fs_promises_api)

<comment><USER3> Does es6-promisify solve your first concern? The callbacks are definitely a pain.

</comment></comment><comment><USER4> I haven't used this yet, but I thought I'd also mention RxDB and GUN that also fit in this similar space of cross client<>server db engines.

[https://github.com/pubkey/rxdb](https://github.com/pubkey/rxdb)

[https://gun.eco/](https://gun.eco/)

EDIT: I'd love to see a discussion comparing localForage, BrowserFS, GUN, and RxDB :D

<comment><USER5> Huh, this would be pretty cool.

BrowserFS seems to even have Dropbox etc. backends, and GUN already has a NodeJS `fs` adapter, so could theoretical could seamlessly swap BrowserFS in for fs and get GUN backed up to Dropbox!!!

</comment></comment><comment><USER3> I posted this earlier but it failed to gain enough upvotes, thx. BrowserFS is a pretty darned nice library that I'm using to make an extension based file manager.

I'm hoping IndexedDB is fast enough for my use case. I haven't been able to benchmark it yet.

<comment><USER6> Am I the only one who thinks this is a rootkit ? What's next? A graphics driver in browser ? Seriously the browser looks more and more like malware.

<comment><USER3> To be perfectly honest, yes it does. But what am I to do if I want maximum interoperability and ease of installation? The difference in penetration my project will get via web extension installation vs binary distribution is huge. I can extend it later with native application calls. Not to mention all of the interactive content that we instantly have access to in the browser vs only on a single person's machine. In addition, the extension also works on mobile Firefox for both ios and android when I use Fenec and extend it.

There are use cases that you'll see in the future that couldn't grow or exist otherwise.

Hyperbolic tldr; Don't be old and crotchety. Join us, lead us, or die.

<comment><USER7> > Hyperbolic tldr; Don't be old and crotchety. Join us, lead us, or die.

I know it was hyperbole but this sort of attitude is what got a generation of technologists and end-users to blindly accept oversharing their personal data, having that data used by nefarious third parties, and to be spied on. We're now in the midst of that same generation realising this far too late and having the monumentally difficult task of convincing their technologically- illiterate friends and family to move away from the shiny reality they promised but never delivered.

I'm happy with softly-softly-catchy-monkey rather than driving off the side of the cliff at 100 km/h, thank you.

<comment><USER3> But that's why I'm making this in the first place lol. Just wait, it's actually going to be awesome.

</comment></comment></comment></comment></comment><comment><USER8> We wrote something similar a long time ago before knowing about browserfs. js- virtualfs [https://github.com/MatrixAI/js- virtualfs/blob/master/README....](https://github.com/MatrixAI/js- virtualfs/blob/master/README.md) it has a list of unique features on it that makes it a better simulation of real posix filesystems.

</comment><comment><USER9> > If you decide to use BrowserFS in a project that leads to a publication, > please cite the academic papers on Doppio and Browsix

I empathize with their desire for more citations, but this rubs me the wrong way. Either they don't trust authors to cite sources appropriately, or they are asking authors to create inappropriate citations. I suggest trusting authors to cite appropriately.

Moreover, using a system isn't the same as building on work from a paper. If one needs to add a reference for a system, it may be more useful to cite a more up-to-date reference for the system rather than the original paper where it was proposed.

</comment><comment><USER10> Really nice, but this is not a "File System" but an I/O library.

<comment><USER11> It seems to be part of a larger framework which looks something like an in- browser OS.

Here's their paper, mentioned in the GitHub page (PDF format): [https://people.cs.umass.edu/~emery/pubs/doppio.pdf](https://people.cs.umass.edu/~emery/pubs/doppio.pdf)

</comment></comment><comment><USER12> The really cool thing about this is it highlights how complex something as simple as a filesystem can be in a browser.

Seriously, over 20 ways to backend a filesystem!!!

Really really incredible!

</comment><comment><USER13> In general, do people recommend using libraries like this for in-browser filesystem or building it from scratch? I'm looking for something to sync files between Google Drive, IndexedDB, and which has a treeview component to display and modify files.</comment>


Marvell announces 96-core ThunderX3 Arm server processor - <AUTHOR> https://www.networkworld.com/article/3533355/marvell-announces-96-core-thunderx3-arm-server-processor.html <comment><USER2> "Marvell is going for the single monolithic chip design rather than breaking it up into chiplets" Wouldn't this be a nightmare from a yield perspective? There's a reason why AMD/Intel use chiplets...

</comment><comment><USER3> This is interesting. I wonder when we'll have desktops and laptops with ARM chips though? Will the tipping point be when Apple launches an ARM based Mac Mini or MacBook?</comment>


Space K - <AUTHOR> https://blog.dcpos.ch/space-k <comment><USER2> [https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

>" _Off-Topic: Most stories about politics, or crime, or sports, unless they 're evidence of some interesting new phenomenon._"

<comment><AUTHOR> Most, not all.

This story is about political money in Silicon Valley. I think it's relevant to a lot of people here on Hacker News, because many of us work for one of these guys.

One effect of cap tables is that when things go well, someone else is typically making a specific multiple of whatever you're making. Say you're an early employee at Company X and you really work hard and ship something great, and that makes Company X more valuable. Your stake in the company has appreciated---but someone else, typically a founder or VC, has made exactly 20x or 50x or 100x as much!

Those people are in a position of power. They have a lot of leverage. If they're using that clout to advance a specific political agenda, maybe you want to know what the agenda is?

What I'm trying to do is show people that political contributions are public records and show people how to search them and make sense of them.</comment></comment>


Spoiler: Intel CPUs afflicted with simple data-spewing spec-exec vulnerability - <AUTHOR> https://www.theregister.co.uk/2019/03/05/spoiler_intel_processor_flaw/ <comment><USER2> Hm. You usually don't think of the physical location of a page in memory as being security-critical information. This should only be a problem for memory vulnerable to rowhammer-type attacks. That's a hardware defect. It's embarrassing that hardware vulnerable to such attacks is still being manufactured. The fix is just to refresh DRAM more often. Yes, you pay for that in battery life on mobile devices.</comment>


Why the Linux Mint hack is an indicator of a larger problem - <AUTHOR> http://www.techrepublic.com/article/why-the-linux-mint-hack-is-an-indicator-of-a-larger-problem/ <comment><USER2> As the user of elementary OS, I do have to disagree on the statement that it is as vulnerable as Linux Mint.

* It is based solely on LTS Ubuntu versions since the project started.

* It does not override application names like Linux Mint does.

* It does not try to support a whole bunch of other desktop environments (it is stated in article, but still...)

* Its website is open source.

* It does not rely on things such as phpBB. Its official communities are on Google+ and StackExchange and they use Tumblr for their blog, therefore focusing more on the actual OS and not having to worry about supporting these things.

* They don't delay upgrades in any single way.</comment>


Show HN: My MusicHackDay project. A MPC-esque JS drum machine (requires Chrome) - <AUTHOR> http://jpc.heroku.com/

<comment><USER2> Including some sample mp3s to directly start playing around would be great. I pressed 'q' and nothing happened. :/

<comment><AUTHOR> I might add in some default samples if someone can suggest good ones with a suitable license? That said I believe this is exactly how a MPC would work, i.e. no sounds loaded when it is powered on!

<comment><USER3> Sure, the problem is 99.999% of people don't have small cut up mp3's ready to go. Making your project useless to us because we'll never see how it works!

<comment><AUTHOR> You can select portions of the mp3 by clicking and dragging on the display.

</comment></comment></comment></comment><comment><USER4> You passed the 16th note high hat test! Well done.

FWIW, you said "mp3" but I just used the first folder of one-shot samples I came across, which happened to be WAVs and worked fine, but may have contributed to Chrome crashing when I hit the back button.

As far as royalty free samples go, you might want to take a look at <http://freesound.org>, or one of my personal favorites, <http://hellosamples.com>

Requests: Keymappings for rec/stop/play/undo/pitchbend, a fourth row of pads, maybe sample slicing?

<comment><AUTHOR> You can slice samples by clicking and dragging on a waveform, which will cause the selected part of the waveform to be played whenever the pad is triggered.

<comment><USER4> Tried that out, it works well, but also revealed another limitation—it seems as if I can only trigger two pads concurrently. That may be less a flaw in your app and more an inherent reality resulting from the fact that my keyboard wasn't necessarily meant to be used as a drum pad.

Edit: Potential workaround would be pad-linking (hard kick and deep kick, snare and clap, kick and closed hh if I know I'm playing 16th note hats, etc), if indeed there's no issue with playback of multiple samples and it's only a limitation of the input device.

When I mentioned slicing, I meant more along the lines of setting multiple slice points and assigning the slices to several pads, as one would when loading a drum break into an MPC, for instance. A copy function would accomplish largely the same thing.

Anyway, it's all academic, there's a Maschine sitting right next to the keyboard on my desk, it's not as if I'm actually going to use this as an MPC replacement. Just throwing ideas out there.

Great job though.

</comment></comment></comment><comment><USER5> Off the top of my head, things that this is lacking: velocity control for each pad, a way to zoom in on waveforms and chop up samples, maybe better loop controls, and the ability to export as .wav?

But suggestions aside, as a budding hip-hop producer/hacker, I had the idea to make this but never the skills/conviction. It made my day to see that this is something actually doable, and capable of being done well.

</comment><comment><USER6> I get 'unsupported file format' when i try to load an mp3. Chromium 16, tried several mp3s.

Also, the font rendering of the instructions is pretty awful for me -- <http://imgur.com/Iy31O>

Neat idea though.

<comment><USER7> I got that a lot for different WAVs that work fine in my other software.

<comment><AUTHOR> Chrome cannot play WAV files

</comment></comment></comment><comment><USER8> Could I get a volume control/equalizer in there? My mp3s seem to be not really normalized.

But its a lot of fun to play with!

<comment><AUTHOR> I had the idea to add that and some filters on there too. I'll see what I can do… :)

<comment><USER9> Being able to zoom in on the track's waveform would be nice too.

<comment><USER10> Love it. Being able to expand/contract the wave selection instead of redrawing would be great too. Wanna grab that crackling snare!

Check out Pete Rock gettin down on his MPC <http://www.youtube.com/watch?v=z73CcodfT_w>

<comment><USER11> Genius! The first serious (old school) sampler that i see on the web.

But for me it requires a metronome to record in right time. Then it will be perfect. :-)

</comment></comment></comment></comment></comment><comment><USER12> Clicking record repeatedly while it's playing back an existing pattern creates some awesome cacophony.

</comment><comment><USER13> I tried dragging mp3 samples as instructed and nothing happen! Using Chrome on Windows 7.

<comment><USER13> Got it working, it needs Chrome Beta!

</comment></comment><comment><USER14> Pretty nice. Forked!

Is this it for the demo, or do you plan to continue development?

<comment><AUTHOR> Thanks. There are a few things I want to add, e.g. a better sequencer, variable tempo, quantisation, local persistence of loaded samples and sequencer data, zoomable waveform for finer grained editing on longer files, etc. I'm quite busy so who knows when I'll get around to it?

</comment></comment><comment><USER15> Why should it need Chrome. This is just as bad as needing IE6 twelve years ago.

<comment><AUTHOR> This is such an ignorant comment. You're wrong, it's actually nothing like that. It's technical demonstration of edge W3C APIs, not something coded against proprietary APIs or around rendering engine bugs. It requires any browser that has implemented the W3C AudioContext API, which at this point only Chrome has implemented in a generally available release. But this doesn't quite fit into the 80 char constraint of HN link titles.

<comment><USER15> "which at this point only Chrome has implemented in a generally available release"

My point exactly.

<comment><USER16> The difference is that someday this will also work in Firefox, Opera, and/or Safari -- perhaps even the mobile versions. It requires Chrome _today_ , but it won't require Chrome _forever_.</comment></comment></comment></comment>


PacketShader – GPU-Accelerated Software Router (2011) - <AUTHOR> https://shader.kaist.edu/packetshader/ <comment><USER2> Nowadays GPUs are a poor choice for this. GPUs have fairly high latency and are designed to be optimal for embarrassingly parallel computations. Sure you can do 10gigabits/sec but because you're batching that'll result in your latency being high-ish on average.

In terms of non-CPU hardware for routing FPGA's are still king if you need a bit of flexibility. In theory a rule table can be defined in configs and then flashed onto the FGPA for line-speed packet processing. Even then, given how slow FPGA's are to flash CPUs are still king when general packet processing is needed.

</comment><comment><USER3> meh, just use plain cpus; see dpdk

[https://fast.dpdk.org/doc/perf/DPDK_19_11_Intel_NIC_performa...](https://fast.dpdk.org/doc/perf/DPDK_19_11_Intel_NIC_performance_report.pdf)

</comment><comment><USER4> This is 10 years old! The GPU the benchmarks run on has 480 cores, and modern GPUs have >5000, and the available memory has gone from 1.5GB to 32GB.

I'd love to see these numbers run with a modern GPU.

</comment><comment><USER5> Interesting... looks like it's effective for routing minimum-sized packets. As an aside, this is the epitome of good web design. Fast, clear, proper line- widths... I'm in love :)</comment>


Yes, that $750 generic pill is a pure artifact of regulation - <AUTHOR> http://overlawyered.com/2015/09/yes-that-750-generic-pill-is-a-pure-artifact-of-regulation/ <comment><USER2> The article talks about the burden of regulation, but fails to recognise that the reason all that regulation exists is because people would happily sell vitamin C as a cure for cancer or lemon juice as a cure for HIV/AIDs if the regulation didn't exist.

The fact that an abusive idiot manages to find and exploit a loophole is a failure of that person's ethics and morals, not of regulation.

EDIT

> Underlying it all — but seldom asked — was whether the gigantic costs of > regulatory approval are really a necessary evil. Libertarian-minded critics > were especially inclined to question whether hugely expensive studies and > paperwork should really be required in the case of grandfathered or > "generally recognized as safe" drugs, many of which have been familiar to > the medical profession for decades or even centuries, allowing for a > collective sense to emerge of their safety and effectiveness. But the view > that progressives tended to champion — which prevailed — was that older > compounds and those used for rare diseases should be held to no less > stringent a standard than any other, and should either be withdrawn from the > market or have their safety and effectiveness proved at someone's expense.

A bunch of now generics were introduced when studies were just not very good. There are good reasons to want to see evidence of safety and efficacy.

</comment><comment><USER3> Of course it's possible to say it's a "pure artifact of regulation". It's also meaningless.

It seems to me that anything making the broad claim that this generic is a 'pure artifact of regulation' must also be against patents, trademarks, copyright and other similar monopolies backed by the power of the state. Are these not also all pure artifacts of regulation?

But perhaps those regulations are somehow "natural" or "fair", so I'll put that argument aside. This piece says:

> which he cleverly amplified by sharp practices described by Ronald Bailey: > "First, he apparently talked Impax [a predecessor holder of the sole FDA > rights to market Daraprim] into starving the wholesale market of the drug, > so that when Turing completed its purchase of the rights there were no extra > pills floating around. Next, he set up an exclusive distribution network as > a way of preventing potential competitors from obtaining enough Daraprim to > conduct [the equivalence] trials for the FDA" necessary to develop an ANDA > so as eventually to challenge his regulatory monopoly.

See that part about 'exclusive distribution network', which is praised as a 'sharp practice'? How did that get to be there? If the FDA prevented closed distribution, then other companies could get the supply needed to demonstrate that their copy was sufficiently similar. While that wouldn't prevent price jacking, it would lower how high the price could be jacked.

So long as companies are required to demonstrate biosimilarity and have no way to get access to the materials needed to demonstrate biosimilarity, then there's a problem. If you think demonstrating biosimilarity is the problem then you think regulation are in the way (and you're fine letting people distribute snake oil as a replacement for a tested drug). If you think that restricted access to the drugs is the problem, then you think that the regulations we have should be tweaked.

This piece only looks at the former, and praises the latter.</comment>


Web-assembly powered WYSIWYG LaTeX Editor, supporting nearly all LaTeX package - <AUTHOR> https://github.com/SwiftLaTeX/SwiftLaTeX <comment><USER2> This is amazing.

• This seems to be their main page: [https://www.swiftlatex.com/](https://www.swiftlatex.com/)

• Not all the source code is on GitHub; crucially their modification of the TeX engine seems to be distributed only as the two `.wasm` binary files). Not sure if they plan to share more or not.

• As mentioned in the FAQ/docs page, this is the work of just two people from New Zealand (Gerald Weber and Elliott Wen), and they have a paper about it from 2018 ("SwiftLaTeX: Exploring Web-based True WYSIWYG Editing for Digital Publishing", DOI: 10.1145/3209280.3209522). Based on a quick skim so far, the paper looks fantastic, looking forward to reading it in more detail.

• In the paper, Figure 5 and the surrounding text describe how TeX was modified (the part of most interest to me); it's really clever! To avoid modifying the data structures and introducing new bugs, they hook only into TeX's internal allocation functions for tokens. (TeX as originally written by Knuth does not use malloc() or equivalent; it does all its own allocation out of giant arrays called "mem" and "str".) They can then look up this bookkeeping when the token lists are being shipped out to PDF format.

• Looks like it has some limitations as far as PS/PDF specials goes (aka "drivers" in the TeX world), so TikZ or tcolorbox don't work too well for example. However my guess is that this is just an issue with their PDF rendering (per the paper they use something like Pdf2htmlEX rather than pdf.js, for speed), and not a fundamental issue.

• But otherwise most of the standard LaTeX features and packages seem to work (labels and cross-references, etc); you can \usepackage anything and it will download the corresponding files but no data leaves your system; everything happens in the browser. Heck I even pasted in xii.tex (without the final "jbye") and it works (can click on "partridge" in the PDF and go to the corresponding part of the source).

• This sort of WYSIWYG editing for LaTeX has been done in a couple of proprietary systems before (BaKoMa TeX / Texpad), and some ancient systems as well (VorTeX), but they've been buggy in my limited experience. There was also a very impressive demo at this year's TUG meeting, by David Fuchs (who Knuth described as his "right-hand man" on the TeX project). All these projects have had to grapple with the same issues (achieving quiescence etc). This one seems to have its share of minor bugs (some artefacts seem to be visible in their published paper too!), so e.g. a feature to fully update the PDF after a (very) long typing pause (or manual user request) seems desirable. Nevertheless it's very impressive as it is.

• I think some sort of engagement with the TeX community (the mailing lists at [http://tug.org/texlive/lists.html](http://tug.org/texlive/lists.html) etc) may help: it appears their code is currently based on pdfTeX; they should probably consider XeTeX / LuaTeX as well (given that the doc page at [https://swiftlatex.readthedocs.io/en/latest/](https://swiftlatex.readthedocs.io/en/latest/) mentions "Lack of Unicode Support"). There are experts there with some idea of corner cases, the weird things that users want, etc. Hope this becomes part of the TeX mainstream (what little there is of it) to benefit all users (good typesetting for everyone!) and not some sort of edge case that dies when/if the authors lose interest.

Overall, am really awestruck by all this. Congratulations and good luck to the authors!

<comment><USER3> >crucially their modification of the TeX engine seems to be distributed only as the two `.wasm` binary files

I thought one of the selling points of webassembly is that wasm files must have a textual format that anyone can read the source.

<comment><USER4> The binary format and the text format are completely interchangeable. [https://www.webassemblyman.com/wat_webassembly_text_format.h...](https://www.webassemblyman.com/wat_webassembly_text_format.html) (As far as I can tell, comments are not preserved in the binary format though.)

<comment><USER5> It's the same with regular assembly. When you compile/assemble a .S or .asm file, you get a binary file with none of the comments

</comment></comment></comment></comment><comment><USER6> One of the key aspects about LaTeX that made me very productive with it was that I could just dump lots and lots of text pretty much directly from my brain into the plaintext editor, without thinking much about the intricate details of the layout. I suspect that an important "feature" that enabled this was the fact that I didn't have the exact layout present and visible in front of me all the time, but just the semantic aspects of it - until I manually triggered a compilation to actually get everything laid out.

However, this is still an awesome editor, and I would probably have loved to use the near-instant WYSIWYG updates for more complex and layout-sensitive parts of papers, like tables and such. I'd just wish this editor would allow to disable the distracting layout rendering completely for "dump-text-from- brain" phases.

<comment><USER7> For me it was the reverse. Layout and content always went hand in hand, with both engaging and influencing each other.

I have noticed these different approaches, text as 'data' irrespective of presentation and text as an element part of a holistic piece of work, to be strongly preferred by different people and either of them struggling to be productive when mismatched.

<comment><USER8> This is a good observation. Interestingly, I'm quite a visual writer in that the final form of the piece influences my writing. However, I still prefer the latex workflow of entering the text in a raw form coupled with regular compilation into the final layout. Perhaps as a developer of just feels more like coding to isolate and iterate.

<comment><USER9> Exactly. My writing process is always sort of "two-phased". First get the content right, use semantic commands (section, theorem, keyword, algorithm listing, etc). For this the LaTeX plaintext is great, I define macros for everything that I'm going to use more than a couple of times that has a semantic meaning. Then, the second phase is adjusting the layout/typography to convey my meaning in the best way possible.

</comment></comment></comment></comment><comment><USER10> Personally I hate Tex/LaTeX and I think it should be replacted by something else long time ago. First of all syntax is horrible, if you don't work with it on daily basis try to figure out what macro you wrote one year ago is doing. Each time you have to jump to manual and learn almost everythig from very beginning. Next thing is lack of utf-8 and TrueType fonts supports (I know there is XeTeX and LuaTeX) but today such features such be in very core of text system no in some software branch. Extensibility is next thing and here again it is very poor unless you use something modern like LuaTeX or you are an expert in TeX macros. Packages dependency hell is next thing side by side with stupid compilation process with meaningless error messages. Am I the only one who think this way?

<comment><USER9> Your comment reminds me of the people who shit on C++. Some of the criticism may be true, but there simply isn't anything out there that could possibly be considered a feasible replacement.

Also:

>lack of utf-8 and TrueType fonts supports

There's UTF-8 support in the standard pdfLaTeX compiler and TrueType support in XeTeX (which is far far from a trivial issue, which is why there are two branches, if you don't need TT fonts you're better off with pdfLaTeX which has more support for e.g. microtypographical adjustments).

<comment><USER11> I don't think that's true. Both Latex and C++ were replaced. It's just that their best replacements were more specialized tools so that left a bit of space for both to survive.

It's just like that example of cars mostly replacing trucks in the US. Trucks aren't obsolete, but most don't need them so choose alternatives that fit their life better.

Latex was replaced by Microsoft Word, Adobe InDesign, and Markdown. Each one is different but for people who might have used Latex for a certain use case, one of those more specialized tools might be better. But there will always be a need for Latex itself.

<comment><USER9> That just proved my point. Saying markdown replaces LaTeX is like saying javascript replaces C++. They're not even in the same league, they're tools for completely different purposes.

</comment></comment></comment></comment><comment><USER12> I sat next to Prof. Knuth in 1982 at Stanford, while he did a demo of TeX on the university's DEC-10. I asked him what was next? He said: real-time, WYSYWIG display.

At the time, the idea struck me as utterly impossible.

<comment><USER13> Back in the 80's I worked as an OS software architect. I used to do a mental exercise occasionally. I would imagine how I would design things if processors were infinitely fast. Back then we were still following Moore's law, even for single processor machines. Processor speed, memory size, disk speed, and network speed all put hurdles up for what we could do.

I remember talking to a colleague about the possibility of a TeX system that would rerender a page as it was typed in one screen and viewed in another. Ok

</comment></comment><comment><USER14> Very nice. Used ShareLatex back in the days. Now it is Overleaf[0]. I guess this will help to bring in competition. One of the benchmark I use to test Latex Editor is my Bachelor paper [1] written in French with all the accents and math symbols. I used that to test this new Latex editor and it seems not produce the PDF. But Texmaker ( my favorite) would just produce the PDF even if there are errors.

[0]: [https://www.overleaf.com/](https://www.overleaf.com/) [1]: [https://bitbucket.org/iMitwe/my- thesis/src/master/inegalites...](https://bitbucket.org/iMitwe/my- thesis/src/master/inegalites.tex)

</comment><comment><USER15> Whaaaaaat. This is amazing! I know so many people who have difficulties collaborating on manuscripts the mismatch between skills document skills (life sciences vs. computer science), but thanks to WYSIWYG, they will now be able to collaborate.

The checkpointing thing is very impressive... typing + update is near instant. Never seen that before.

</comment><comment><USER16> A web grandmaster see I. Office365/GoogleDocs should be very interested in this stuff and by "very" I mean 50 millions at least (they burn way more money on complete bs projects). It's very likely that the author knows more than I do, but it seems reasonable to work out some sort of dual-licensing deal: one for corps who want to take it and develop further and one for smaller businesses who are ok with saas-ish solution.

<comment><USER17> I'm a big fan of LaTex, having used it for my thesis, presentation (beamer) and a few peer reviewed articles/jounals.

With that disclaimer I can safely contend that Google/MSFT will not be interested in this. LaTex is for academic typesetting, with a special focus on math-y content. Even with WYSIWYG, every now and then one will need to get into the weeds of Tex syntax, which is simply not for the average computer user.

As for academia, they will not pay a Google/Microsoft for LaTex use when they might as well use Lyx/Kile or their favorite editor with some syntax highlighting support for Tex. And unlike regular note taking, academic writing isn't so spontaneous that you start editing your IEEE manuscript on the pot, while on your phone.

My guess is that the FAANG tribe have little incentive to commercialize this, and hence acquire it

<comment><USER18> Have you checked out Overleaf? I would say they are proof that there is definitely a market. My university (40k students, 8k employees) has a deal with them where all students and employees get access to premium features, and they probably pay a decent chunk of money for that.

They have published a list of institutions using Overleaf here: [https://www.overleaf.com/for/universities](https://www.overleaf.com/for/universities)

</comment></comment></comment><comment><USER19> The typing update speed blows Overleaf out of the water. I've used Overleaf for the past 3 years. It's a great product, but one of my biggest complaints is slow LaTeX rendering. If this product were a bit more polished I would use it instead of Overleaf.

<comment><USER20> You should check out TexPad![0] It's lovely and essentially real-time, with autocomplete, etc. I use it as my editor of choice for all of my papers (not that any of them have particularly challenging layouts).

Really cannot recommend it enough. :)

———

[0] [https://www.texpad.com/](https://www.texpad.com/)

<comment><USER21> Shame it's Mac only as it looks exceptionally good. Would love to use on Windows.

</comment></comment></comment><comment><USER21> LyX [0] eat your heart out.

It's good to see competition in this space as LyX's development has slowed the last few years. I still like it, but will be interested to try this alternative.

0\. [https://wiki.lyx.org](https://wiki.lyx.org)

<comment><USER22> I use Lyx as my primary tool for writing. I know it's clunky but it's as reliable as the tides.

</comment></comment><comment><USER23> The rendering happens in real-time when you type! Is this using pdflatex? Because I've never seen an editor with this low of a response time.

Only slight nit is the blue progress bar/page load bar that appears across the top of the screen while you're typing is annoying. And the baseline kerning of the fonts in math mode seem a bit off: $$x^2 + 2x + 1$$ has the x in 2x a bit raised

<comment><USER24> It appears to be using a heuristic to update the PDF directly when you type, and then it periodically runs LaTeX to do global layout. Try putting the cursor before \LaTeX in the example document and input a few spaces. For me, it shifted the first characters into the later ones, perhaps because their heuristic couldn't detect that they are on the same line due to the vertical offset.

</comment></comment><comment><USER25> Really nice, the speed is way better than e.g. Overleaf.

Is there any way to divide the screen horizontally instead of vertically for use with widescreens? Did not find an option at first glance.

</comment><comment><USER26> This is incredible. I've never seen LaTeX render so fast; it almost feels like WYSIWYG editing.

</comment><comment><USER27> With the development of pure Rust[1] TeX engine (based on XeTeX) it will be possible to compile into WebAssembly too.

[1] [https://github.com/crlf0710/tectonic](https://github.com/crlf0710/tectonic)

</comment><comment><USER28> While I don't doubt the utility of this at all, I am quite amused by the concept of WYSISYG LaTeX.

<comment><USER29> Some people I know literally share LaTeX math in emails and chats and assume my head has an internal LaTeX-compiler to understand it (usually I do). I guess this means people are really accustomed to writing maths in one go in LaTeX -- it's like the pseudo-code of maths.

</comment></comment><comment><USER30> I'm getting this on ios Safari when creating document:

"Oops Error Detected! Looks like there was a problem when creating the project: DataCloneError: Failed to store record in an IDBObjectStore: BlobURLs are not yet supported."

<comment><USER31> It went very smoothly on Firefox.. Maybe this is a thing with iOS/Safari?

</comment></comment><comment><USER32> Fortunately, the WYSIWYG-bit is non-mandatory. You can also edit the source directly.

I assume Google Drive files can be simultaneously edited by multiple people? If so, then this represents a real competitor to Overleaf.

</comment><comment><USER33> This is indeed amazing! But I was wondering if it's possible to compile the whole TeXmacs into WebAssembly and have it in the browser. That will be a totally different world.

</comment><comment><USER34> This seems like an incredible tool to increase adoption of TeX systems. It solves the problem of: I want to try my hand at TeX but you're saying I have to install what now?

<comment><USER32> Overleaf.com is another place to try out TeX without installing anything. (The free version is perfectly fine for almost anything other than collaborating with 3+ people on the same project.) The web interface isn't as nice as a proper text editor, but it's not too bad.

</comment></comment><comment><USER35> This tool is very cool - however it appears to be written in JavaScript. I can't see any evidence of the use of WebAssembly.

<comment><USER36> Boot up the sandbox demo [https://www.swiftlatex.com/oauth/login_oauth?type=sandbox](https://www.swiftlatex.com/oauth/login_oauth?type=sandbox), it fetches and runs this wasm blob: [https://www.swiftlatex.com/ide/js/fastlatex/cpdfetex.wasm](https://www.swiftlatex.com/ide/js/fastlatex/cpdfetex.wasm)

</comment></comment><comment><USER37> Google drive and dropbox are blocked at work for me...It would be nice if they had an option for if you don't want to save your work. Like just an in-browser editor without saving. Sometimes I just might want to write up some Latex and then copy it into something else. Nowadays I usually need to open up Lyx to do the same thing.

<comment><USER37> Ah, so the sandbox mode on github is what works for me. However, there is no link for it on the main page.

Regardless, I suppose I was mistaken on what the project was. I assumed it was like a WYSIWYG version of Lyx in the browser. You're still writing Latex with this.

</comment></comment><comment><USER38> I think it's really funny that swiftlatex is written in python!

Somebody should write an application called pythonlatex in swift!

</comment><comment><USER39> This is interesting. I noticed that the first compilation is sort of slow (takes a couple seconds). But each subsequent small change is almost instant. How is this done? I'd imagine each tex->ps should take at least a few seconds.

</comment><comment><USER40> Are there similar, "true WYSIWYG" LaTeX clients that are not web-based but native for one's platform? I know about Lyx but it's honestly quite disappointing in comparison to this project

</comment><comment><USER41> This works surprisingly well on mobile. It's not 100% usable, but it works

</comment><comment><USER42> this is absolutely amazing!

Even though I prefer to write everything locally, I've been forced to use overleaf due to the fact that my collaborator forced me to do so.

But, with this speed, I will probably throw away overleaf. :)

</comment><comment><USER43> Out of curiosity, and in the context of Latex, does anyone know of a good self-hosted collaborative web-based editor with preview? Or even something decentralized that works over WebRTC?

<comment><USER44> If you want one using latex, you can use open source self hosted overleaf variant. The worst part is the user management though, as they even keep somewhat sensible user management for the paid version.

</comment></comment><comment><USER45> Tried creating a resume using one of the provided templates. Failed because XeLaTeX was required.

Tried creating a Tufte-style book using the provided template. Failed because of a missing file.

</comment><comment><USER46> One thing I'd really like to see is the ability to adjust line spacing. It's insanely painful in latex, and a WYSIWYG editor would be amazing.

</comment><comment><USER47> This is great! It still needs some polishing (like autoscrolling the output to where I just made a change), but it FEELS really great!

</comment><comment><USER48> This is incredible. The render speed is amazing!

</comment><comment><USER9> Dissapointing that it requires a Google account.

</comment><comment><USER49> Can someone enlighten me on the benefits of LaTeX? I've never run across it or someone who uses it.

<comment><USER50> It's a markup language with a long history I won't get into. But that means it at least aims at separating content and presentation. Relative to producing a document in something like Word, it has a few real strengths. It's very good at:typesetting mathematical notation, typesetting different languages properly in the same document, and pretty good managing large complicated documents. It tends to do hyphenation breaks and spacing better than word processors.

You can easily solve versioning and collaboration issues because the input is plain text (like source code, just version control it and use patches, PRs, etc.) This works better than "track changes" in practice, especially with multiple authors.

So those are the upsides. Downsides: it's a bit esoteric, and clunky for lots of documentation tasks. The implementation is complex and the package/module system can step all over itself. If you have output that is nearly but not quite right, it can be a real bear to fix it.

These days Markdown may be a better choice for a lot of simple documentation tasks where you don't care much about the final output presentation details. Any word processor can probably let you do some things more quickly.

When I was a grad student I knew multiple people in STEM fields who tried to do their thesis in Word (or equivalent) and gave up in frustration, moving it all to LaTeX. I never knew anyone who successfully went the other direction. I don't know if that is still the case.

If you use it a lot, you may find yourself wanting to use it for everything (letters, resumes, presentations, etc.) but many of those things aren't particularly strengths. If you don't use it a lot you will find it hard to come back to casually.

One other strength I should mention, especially for automated documentation. Knuth was very particular about stability in TeX, and LaTeX has mostly-kinda- sorta followed this philosophy. So unless you have used a lot of marginal packages or something, it's entirely reasonable to expect that processing a 20 year old input will work fine using current builds. This is not something you can say of most systems.

<comment><USER51> "When I was a grad student I knew multiple people in STEM fields who tried to do their thesis in Word (or equivalent) and gave up in frustration, moving it all to LaTeX. I never knew anyone who successfully went the other direction. I don't know if that is still the case."

Ha! I started my thesis in LaTeX but my adviser only wanted a word document for reading it, so I had to go the other way :)

<comment><USER50> You have my condolences :)

One person I knew gave up on word when it suddenly lost half a dozen figures they no longer had the originals for. Never did figure out what the mechanism was, but you bet they became more disciplined about backups.

I'm sure it's much more reliable today, but once you had a long document with a bunch of figures, tables, and equations in it, Word started doing odd things. Including just refusing input for a couple of minutes with no message, then crashing. Good times.

</comment></comment></comment></comment><comment><USER52> this is excellent! My main reason for a web-based Latex editor is multi user editing. Overleaf/ShareLatex had it, but now they are closing it down and charging for it. An open source competitor, even if with less features than the commercial ones, is a great piece of news.

</comment><comment><USER53> i don't see anyone outside of math/csci/physics folks using latex. Almost all profs in chemistry, biology, pharmaceuticals, etc field just use word.

</comment><comment><USER54> From the referenced document :

> Known bug lists

> 1\. WYSIWYG

I agree. The first bug is that it is WYSIWYG. ;-)

Oh that's not what they meant. Or is it a clever innuendo ?

/Joke

## Praise of WYSIWYM (WYM for "what you mean")

Seriously, I wrote my Ph.D. as LaTeX source code with the help of LaTeX-mode in Emacs, including colored syntax highlighting, and was/am very happy.

As explained in a number of places, the point is to write for content without diluting your brainpower with appearance issues.

Moreover it is a common experience that proofreading a rendered copy allows the brain to more easily find typos without the filtering effect that cause one to miss them in a document being edited WYSIWYG fashion.

Also, editing source code has the nice property that there is no hidden state. Ever been annoyed in Word or Google Docs by undesired formatting conflict on a copy-paste? (yes I know "paste as plain text") Also, bullet list with some bullets having mysteriously different appearance from their siblings and you can't fix it. With sane source document editing these issues cannot happen.

## What next

That said, imagine a hybrid future from assertions below:

* I now use asciidoc as it is simpler to edit (much simpler for things like tables), and have a toolchain that renders it to PDF via LaTeX (the xsl-fo path was never near as visually clean). I wrote a LaTeX style for my personal freelancing company (quotes, invoices, reports, technical documentation) and the fact that one cannot deviate from the style is a feature.

* Side-by-side source+rendered editing somehow can make sense.

* There is practical educational value to let newcomers benefit from LaTeX power and rendering quality with the WYSIWYG they still perceive as comfortable, some will migrate to source editing.

* This project could spawn some variants with other rendering engines.

* Did they solve all the problems with cursor positioning (see "text editing hates you" mentioned here on HN recently) ? In many cases, several visual positions correspond to same source position and vice versa.

* What will happen in practice is the tech will be applied to some other places, which is the very point of public research. That reminds me the project Boomerang. [https://www.seas.upenn.edu/~harmony/](https://www.seas.upenn.edu/~harmony/) there is probably some common ground between those projects.

</comment><comment><USER53> I'm getting a giant pink screen, this is broken.

<comment><USER55> Getting the same issue on the Master Thesis template in Firefox 71.0

</comment></comment><comment><USER56> Even works on my iPhone 11. Very cool.

</comment><comment><USER57> thanks to WYSIWYG</comment>


Show HN: A cute timezone mac app for traveller, distributed team - <AUTHOR> http://zonerly.sanci.me/?fr=producthunt <comment><USER2> I think midnight should be 12AM instead of PM, in the screenshot for NYC ([http://zonerly.sanci.me/imgs/main- o-n.png](http://zonerly.sanci.me/imgs/main-o-n.png)).

<comment><AUTHOR> Yes, the screen shot is wrong, I'll update it.</comment></comment>


Q&A on the ethics of warfare in the autonomous future - <AUTHOR> https://www.bloomberg.com/view/articles/2017-12-30/nobody-s-ready-for-the-killer-robot <comment><USER2> _> RL: Generally, some of the things that had to do with biology were a little frightening, things like synthetic biology where you don't really know the ultimate implications. And some of the work with electromagnetics was a little scary, particularly as it had to do with humans and lethality.

TH: Got it. So you spent some time in the private sector, and …_

Got it? Really? Am I alone in having nothing but questions in my mind after such a briefing? Sure, the interview must go on, but the lack of precision in this "got it" is disturbing to me. I have noticed this phrase being use in some loose ways lately. Am I being too sensitive?

<comment><USER3> Seems pretty clear to me that he was not in a position to offer any specifics. Probably due to NDA or national security yada yada yada.

<comment><USER2> My comment concerns the interviewer's "Got it" response, not the interviewee's lack of information. I immediately considered what you're saying, but I wonder if it justifies the affirmative response. Your assumption is merely contextually reasonable. It is not implied and not 'clear'.

I think it's becoming accepted to say "got it" when a conveyance is understood even when the conveyance remains _between the lines_. The result is a confirmation of one of two meanings, and no telling which one it is. It's a lot worse when the only value is to be snarky. I've seen both result in dysfunction, though. I think I prefer sincerity.

<comment> semi-extrinsic Well, it says in the article _" here is a lightly edited transcript of our discussion"_. The actual raw transcript was probably more like:

 _TH: Interesting, can you tell me some more about what worries you most here?

RL: I'm afraid I can't share any more details. Let's move on.

TH: So you spent some time in the private sector, and …_

where the first part was edited into _Got it_.

</comment></comment></comment></comment><comment><USER4> It will be interesting to see how human soldiers will react to the introduction of autonomous allies. They already have trust issues with unmanned systems [0], I imagine the reaction against to autonomous systems will be even stronger.

[0] [https://www.foreignaffairs.com/articles/united- states/2017-1...](https://www.foreignaffairs.com/articles/united- states/2017-12-20/why-troops-dont-trust-drones)

<comment><USER5> But surely drones aren't unmanned? Just their pilot is elsewhere. Curious as to what the real root of this is.

<comment><USER4> The focus seems to be on the fact that the pilot is elsewhere. From the article:

>Instead, the trust issue was a human issue. Not once did any of our respondents refer to a drone pilot as a human. Instead, drones were discussed in abstract terms that explicitly avoided any reference to a human controlling the machine. UAVs were "robots" or "machines" whose "operators," as one respondent put it, were playing a video game "a world away." This is despite the fact that most of them knew there was a human controlling the drone, and some even knew these pilots personally. Yet across the JTAC community, we heard a familiar narrative: drone pilots were coffee-drinking gamers whose distance from the battlefield severed their emotional connection to friendly ground troops. For instance, one of the JTACs explained that he preferred manned aircraft because their pilots "are in the fight, not just sipping a latte playing a video game."</comment></comment></comment>


Obama Administration proposes massive increase in H-1B visas - <AUTHOR> http://www.ifpte.org/news/details/Obama-Administration-proposes-massive-increase-in-H-1B-visas

<comment><USER2> This plan will likely only displace workers in the low end of the tech job spectrum - one where I see a significant amount of american tech workers doing contract jobs for manual testing, simple tool programming etc. I'm not saying that american workers can only take the low end of the tech market (quite the contrary), but companies have been relying on not-so-skilled contractors for the simple tasks for a long time.

I've seen many highly skilled spouses of H1B visas getting jobs because ultimately companies can apply for these visas already. This one in particular really looks like it is trying to displace the low end of the market by dumping thousands of people on the market who would accept rock bottom wages.

</comment><comment><USER3> this is not as massive as it is being made out to be.

The chances of a spouse of an existing H1-b holder who is past his/her 6 yr H1b visa and has his/her GC under processing, getting Work Authorization for a STEM job, is almost nonexistent!!!</comment>


Ask HN: Is China throttling Google.com? help me - <AUTHOR>

this is a double post but just because i need help.
I do live in Shenzhen, and i noticed that in the past 2 days Google.com is getting seriously slow and unusable. Since it works quite perfectly with my VPN located in USA, i am becoming quite concerned. Moreover Google.com.cn does work perfectly, and all the other foreign sites are at the average usual speed. My main concern is that for all of us, foreigners in China, Google is absolutely a must have, for me is even more, a survival tool. Can somebody in China confirm that this is actually happening ? it is damaging my business and i would have to take counter measures if this is happening for real. Thanks a lot in advance. <comment><USER2> Why run an Internet business in China? Even the giants like Google can't quite get it right. Why do you think you will succeed?

Much better to be in the US or Europe. It's worth the extra taxes or whatever.

<comment><USER3> He didn't say he has an Internet business, but just a business that runs with the help of Google tools, apps...

</comment></comment><comment><USER4> It's working fine for me in central China. Why not just use the VPN if you're having trouble?

</comment><comment><USER5> Can you use traceroute to determine where the lag is being incurred?

<comment><AUTHOR> this is what i am getting :

C:\Users\Administrator>tracert google.com

通过最多 30 个跃点跟踪 到 google.com [184.108.40.206] 的路由:

      1     1 ms     1 ms    <1 毫秒 WRT54GL [188.8.131.52]
      2     5 ms     2 ms     2 ms  192.168.1.1
      3    46 ms    46 ms    47 ms  188.8.131.52
      4    48 ms    47 ms    47 ms  22.214.171.124
      5    45 ms    45 ms    45 ms  184.108.40.206
      6    51 ms    49 ms    51 ms  188.8.131.52
      7    49 ms   114 ms    48 ms  126.96.36.199
      8    49 ms    49 ms    49 ms  188.8.131.52
      9    49 ms    48 ms    48 ms  188.8.131.52
     10    53 ms    52 ms    52 ms  18.104.22.168
     11    58 ms    52 ms    51 ms  184.108.40.206
     12    53 ms    53 ms    53 ms  220.127.116.11
     13    52 ms    61 ms    55 ms  188.8.131.52
     14    54 ms    54 ms    55 ms  hkg01s01-in-f104.1e100.net [22.214.171.124]

<comment><USER5> Huh, that looks fairly reasonable. I'm afraid I don't have any other suggestions at the moment -- I'm too unfamiliar with the workings of the Chinese firewall.</comment></comment></comment>


A neuroanatomist discusses the day she realized she was having a massive stroke - <AUTHOR> http://www.ted.com/index.php/talks/view/id/229

<comment><USER2> I almost didn't upmod this because I thought it was a repeat of the last submission on this topic - this isn't: the last one was a text summary; this one is the real talk. Worth watching, even if (especially if) you've read the previous HN submission about this.</comment>


Disqus hit one billion monthly unique visitors - <AUTHOR> http://blog.disqus.com/post/50374065365/whats-cooler-than-a-billion-monthly-uniques

<comment><USER2> They have done a great job making it easier to have one login for comments across all sites who use their system - the spam problem is not really solved.</comment>


Elm in Production: 25K Lines Later - <AUTHOR> https://charukiewi.cz/posts/elm/ <comment><USER2> First:

> Elm has an incredibly powerful type system

Near the end of the article:

>Want to decode some JSON? Hard, especially if the JSON is heavily nested and it must be decoded to custom types defined in your application.

IMHO the lack of typeclasses/traits is really hurting Elm. Take haskell f.e.

      {-# LANGUAGE DeriveGeneric #-}

      import GHC.Generics

      data Person = Person {
            name :: Text
          , age  :: Int
          } deriving (Generic, Show)

      instance ToJSON Person
      instance FromJSON Person

While I understand Evan's aversion against complexity, it makes me a bit wary about using ElmLang in production. I am currently using TypeScript, but if I would need a more powerful type system, I would probably switch to Haskell/PureScript or OCaml/BuckleScript instead.

<comment><USER3> I really wish people would stop spreading the meme that decoding JSON in Elm is "hard". Yes, Haskell allows you to automatically decode/encode datatypes, but this only works in the simplest of cases. For example, if your backend returns a JSON object with snake-cased fields, but your model has camel-cased fields, `instance ToJSON Person` won't work; you'll have to write a custom decoder. The automatic decoders/encoders in Haskell only work if the shape of your JSON perfectly matches your record definition.

Writing decoders in Elm is not hard. It's manual. It's explicit. It forces you to specify what should happen if the JSON object has missing fields, incorrect types, or is otherwise malformed. There's a slight learning curve and it can be time consuming at first, but it guarantees that your application won't blow up at runtime because of some bad data. Because of this, JSON decoding is frankly one of my favorite parts about Elm.

Typescript, on the other hand, offers no such guarantee. If you write a function that takes an Int and you accidentally pass it a String from a JSON response, your app will blow up and there's the nothing the compiler can do to help you. Personally, I'd rather write JSON decoders than have my app blow up because of a silly mistake.

<comment><USER4> You don't need to write the decoder boilerplate manually to get all those benefits.

For example, here's how you rename a JSON field while serializing/deserializing a data type in Rust:

[https://play.rust- lang.org/?gist=1b382bc1572858841d5e392435d...](https://play.rust- lang.org/?gist=1b382bc1572858841d5e392435de73f4&version=stable)

You just annotate the field with #[serde(rename = "..")]. Here is a list of such annotations

[https://serde.rs/field-attrs.html](https://serde.rs/field-attrs.html)

Serde is also generic in the serialization format; the example I linked uses serde_json, and was adapted from its README here [https://github.com/serde- rs/json](https://github.com/serde-rs/json)

<comment><USER5> Same for Haskell. This package provides common translations like snake_case to CamelCase:

[https://www.stackage.org/haddock/lts-9.0/aeson- casing-0.1.0....](https://www.stackage.org/haddock/lts-9.0/aeson- casing-0.1.0.5/Data-Aeson-Casing.html)

Giving you automatic encoders/decoders like so:

instance ToJSON Person where toJSON = genericToJSON $ aesonPrefix snakeCase instance FromJSON Person where parseJSON = genericParseJSON $ aesonPrefix snakeCase

And the implementation of that package is like 4 simple lines for snake case; it's totally doable on your own for whatever you need [https://github.com/AndrewRademacher/aeson- casing/blob/260d18...](https://github.com/AndrewRademacher/aeson- casing/blob/260d18d62bbb57240b0b7b1e908c8a896ffd8d77/src/Data/Aeson/Casing/Internal.hs#L34-L40)

I haven't had to do snake_case to CamelCase with Aeson before, but I have dropped a prefix before, like "userName" -> "name", "userAge" -> "age", and it was pretty easy and well supported.

Also I would note that this isn't as big of a deal for Haskell and Rust, because they're primarily backend languages, so they're more often sending out JSON in whatever form they please, rather than consuming it. In my experience the main consumers (Javascript on the web, Objective-C on iOS and Java on Android) use CamelCase anyway, so there's a natural compatibility.

</comment></comment></comment></comment><comment><USER6> After doing a couple of contracts on Elm projects for several months, and returning now back to a React-Redux stack project, I cannot emphasize enough how much better working with Elm is.

In every single aspect. I just wish that it will get mainstream as soon as possible.

His article is spot on, and agrees with what I've seen, and most others that used Elm. Just look it up.

<comment><USER7> I am more interested in the details that just this blank statement that everything is better. After trying Elm several times we failed to implement even basic things in it that we could do in React/Redux easily. For an average JS developer Elm is totally alien tech compare to React or Angular. For Haskell programmers Elm is pretty appealing because of the familiar syntax and type system, but the intersection of Haskell programmers and frontend developers are pretty small.

<comment><USER6>
         For an average JS developer Elm is totally alien tech compare to React or Angular

To turn your argument the other way. The JS landscape, where "trendy" libraries change every few months, is also alien to anyone that doesn't keep with the latest libraries every few months. Is that not worse? I don't have to explain "JS fatigue", it's a fact.

For example, I just got into a new team, and I have to now use what they use. I've been doing JS for 4+ years, and that stack I'm facing now, is alien and confusing to me. I have to invest time and learn what the hell those redux- sagas are, or what "magic" create-react-app tools hide, and in general, it's very confusing so far.

With Elm, I spent a few weeks 1 year ago to learn the language, and that was it. All the libraries are very simple to use because of the language. I doubt that learning "redux-sagas" will help me a year from now.

Also, Elm, gives a very coherent package. You don't have to transpile or add a linter, or a type checker, or stitch new libraries every few months because the trend changed. No webpack or babel or eslint or immutable.js or typescript or flow or any of those.

Not to go into the part of the safety and confidence the compiler gives you. Typescript or flow are not even close to that quality and guarantee level. _Note that again you have to learn their syntax and configure them, so that 's again a cost on top of learning JS. And they are as much alien as Elm._

FWIW, I start now side-projects in Elm, and I get things done way faster than with JS. And that's also what I see from other people as well, regardless of whether they come from JS or another language.

<comment><USER7> Well sure, but as an architect/CTO I do not care about trendy, I care only about properly working, easy to develop and maintain and wildly used so I can hire for. Elm is none of these at the moment, but React is.

<comment><USER8> Properly working, check.

Easy to develop and maintain, big check.

Widely used so you can hire - it's usually easier to hire Elm developers because there are more people who want to use it than jobs hiring for it. The opposite is true for JS. So...better than check, at least for right now! :)

Here is a CTO giving a talk about his company's experiences with Elm:

"Elm from a business perspective" \- [https://www.youtube.com/watch?v=DvQI1KntMhk](https://www.youtube.com/watch?v=DvQI1KntMhk)

</comment></comment></comment></comment></comment><comment><USER9> If decoding json in Elm is considered hard, I'd recommend checking out _miso_ ([https://github.com/dmjio/miso](https://github.com/dmjio/miso)), a Haskell re-implementation of the Elm arch. It has access to mature json libraries like _aeson_ for that sort of thing, along with mature lens libraries for updating your model. Here's an example of decoding json with GHC.Generics using typeclasses. [https://github.com/dmjio/miso/blob/master/examples/xhr/Main....](https://github.com/dmjio/miso/blob/master/examples/xhr/Main.hs#L130-L131)

<comment><USER10> You don't need to switch a whole language because of JSON decoding. There are many tools that exist to aid you write JSON decoders in Elm. The language is not just about the architecture -- you can implement the architecture in any language, as Redux has proven. What people like about Elm is the compiler and design philosophy that radiates through the entire community. Switching to Haskell won't give you that, as the Haskell community has different priorities.

Here are some JSON tools for Elm:

\- json-to-elm [http://json2elm.com](http://json2elm.com)

\- swagger-elm [https://github.com/ahultgren/swagger- elm/](https://github.com/ahultgren/swagger-elm/)

\- elm-graphql [https://github.com/jahewson/elm- graphql](https://github.com/jahewson/elm-graphql), [https://github.com/jamesmacaulay/elm- graphql](https://github.com/jamesmacaulay/elm-graphql)

\- elm-export [https://hackage.haskell.org/package/elm- export](https://hackage.haskell.org/package/elm-export)

<comment><USER11> Oh, this is awesome, json2elm really helps :) thanks, didn't know about it.

<comment><USER10> No problem! Glad you found it useful :) It's not perfect by any means, but it's not meant to be.

<comment><USER11> Yeah right, just to jumpstart the effort, especially when there are a lot of entities.

</comment></comment></comment></comment></comment><comment><USER12> I'm really looking forward to the day when all these new-to-Elm people start hitting the complexity ceiling of their language and convince the maintainers to add just a little more power. Example: Haskell's typeclasses have a high power-to-weight ratio, and Elm has to work around their absence (e.g., writing a fresh map function for each data type). Once there's a critical mass of frontend types who understand the power of FP, convincing people to try FP won't be the difficult step any more, and Elm won't need to try so hard to be un-intimidating.

<comment><USER13> Can't for the life of me figure out why people equate FP with the abomination that Haskell is.

Erlang is FP. Javascript is FP. Ocaml is FP.

Type classes, or anything else that has "types" in them such as dependent, or liquid, are not FP, they are types. Types that found their way into a couple of FP languages.

<comment><USER14> I don't think many people (and not the parent) "equate" FP with Haskell, but Haskell is in a way the most functional mainstream language because it is the only lazy one. You can have a purely functional language without laziness in principle, but, as Simon Peyton-Jones points has said, laziness, despite having serious costs, keeps a language designer honest by making it impossible to add side effects. The non-lazy languages all have side effects. A language like OCaml can still be relatively functional because of the way it is typically used. While JavaScript is not traditionally used in a functional way but can be.

[http://www.cs.nott.ac.uk/~gmh/appsem- slides/peytonjones.ppt](http://www.cs.nott.ac.uk/~gmh/appsem- slides/peytonjones.ppt)

<comment><USER13> > Haskell is in a way the most functional mainstream language

1\. Is it the most functional language because it's lazy? No

2\. Is it the most mainstream language because it's lazy? No

3\. Is it the most functional mainstream language because it's lazy? No + no = no

Laziness does not a functional language make.

> You can have a purely functional language

What would be the purpose of a pure FP? Oh. There would be no purpose.

> laziness ... keeps a language designer honest by making it impossible to add > side effects

wat

Laziness is delayed execution. That's it. There's _nothing_ stopping you from delaying a side effect.

<comment><USER15> > Laziness is delayed execution. That's it. There's _nothing_ stopping you > from delaying a side effect.

Laziness is about more than just side effects.

I think "evaluation" or "reduction" would be better words than "execution" here. Laziness (call by need) is an evaluation strategy for (beta-)reducing expressions, which has two nice properties:

\- If an expression can be reduced without diverging by _some_ evaluation strategy, then it can be reduced without diverging using call by need.

\- Efficiency, in the sense that no duplicated work is performed.

The other common evaluation strategies are call by name and call by value. Call by name has the first property, but not the second; so there are cases when it's exponentially slower than call by need. Call by value has the second property, but not the first, so there are cases when it diverges unnecessarily.

This 'unnecessary divergence' is a major reason why most programming languages end up overly complicated to understand (at least, mathematically). For example, consider something like a pair `(cons x y)`, and its projection functions `car` and `cdr`. We might want to describe their behaviour like this:

        ∀x. ∀y. (car (cons x y)) = x
        ∀x. ∀y. (cdr (cons x y)) = y

This is perfectly correct if we're using call by name or call by need, but it's wrong if we're using call by value. Why? Because under call by value `(car (cons x y))` and `(cdr (cons x y))` will diverge if either `x` or `y` diverges. Since the right-hand-sides only contain one variable each, they don't care whether or not the other diverges.

This is why Haskell programs can focus on constructing and destructing data, whilst most other languages must concern themselves with control flow at every point (branching, looping, divergence, delaying, forcing, etc.).

<comment><USER13> Thank you! I clean forgot about call-by-need vs. call-by-value

</comment></comment></comment></comment></comment></comment><comment><USER16> What an excellent article: from tech to business, from the human aspect to practical code examples. Worth a read, even if you're not considering Elm.

<comment><USER17> Not into Elm at all right now and also kind of not convinced about functional programming, yet. But the article was definitely worth a read. I need to slowly open up for FP, I guess.

<comment><USER18> I'll make an observation: I write C# for a living. The great thing about that is that it has a truly great debugger. But, as you rapidly discover, it's easier to debug some code than others. For one thing, you want to be able to go back to the start of the function and re-run it. That means that methods that mutate internal state are hard to debug. Also, it's even better if you can follow the chain of reasoning without rerunning the code. This means having a variable for each assignment, rather than overwriting an existing one. Finally, when processing large data lists, it's easier to debug if you have separate variables for logical steps. e.g. Get the employees of Company X (variable) that are managers (variable) and sum their salaries (variable). Trying to debug round a for loop is an exercise in frustration.

What all these things have in common is: it's easier to reason about the values in a program than the program counter, and that destroying information makes it harder too. And that, to a great extent, is why FP is useful. Even really basic FP in C# or Java.

<comment><USER19> Dumb question: Have you tried IntelliTrace in VS Enterprise (sadly only available there)? It tries to solve many of the issues you're mentioning. You can even start a remote IntelliTrace debugging session in production.

<comment><USER18> Not a VS enterprise shop, sadly. Don't think I've ever worked for anyone prepared to pay for it! It does sound enormously cool. Does it also handle one of my favourite problems: when a method fails because a constructor parameter was wrong, it's pretty hard to rewind.

With that said, VS Pro still has one of the best debuggers on any platform. To the extent that I think C# developers sometimes cut corners because the debugger helps so much.

</comment></comment></comment></comment></comment><comment><USER13> > making very heavy use of Ajax calls to a JSON-based RESTful API

and then

> Want to decode some JSON? Hard, especially if the JSON is heavily nested and > it must be decoded to custom types defined in your application. Doing this > will require an understanding of how JSON decoding works in Elm and will > usually result in quite a bit of code (our application contains over 900 > lines of JSON decoders alone).

What a great pragmatic language

<comment><AUTHOR> Author here. As I posted in a different reply:

JSON decoding is hard relative to what it is like in JavaScript. In your JS code you can just call JSON.parse() and get the corresponding JavaScript object.

In Elm, decoding is not nearly as easy as it is in JS because every field must be explicitly converted to an Elm value. Depending on the complexity of your conversion from JSON to Elm value (e.g. whether you are just decoding to primitive values or to custom types defined in your program), there may also be a bit of a learning curve.

As I stated in the post, there is a benefit in doing all of this: your Elm application will effectively type-check your JSON and reject it if it is malformed.

<comment><USER20> Can you not do the same thing as JSON.parse() in Elm by parsing into an unstructured JSON type?

<comment><USER21> Parsing into Json.Encode.Value gives you that Value but no way to work with it except, at later time, using Json.Decode.decodeValue on it. And you're back to specifying decoders...

<comment><USER20> Seems like you could easily make a library that just parses into some Union type that represents JSON values.

It's likely a design decision to force people that otherwise wouldn't to represent their data in a more structured way.

</comment></comment></comment></comment></comment><comment><USER22> Having started using Elm for side projects over 3 years ago, the article is pretty much spot on.

Programming in Elm had been a delight, especially when you let go of OOP and embrace functional concepts and practices. On one hand, you lose mental tools that you've relied on, but you gain the other tools you didn't even know existed before.

Where I really disliked about Elm is when I had to encode or decode JSON. It's a giant royal pain in the ass. Also, when you find you have to break out to JS often for libraries you don't want to write yourself, it's not a good fit--as I found out when write a toy interactive notebook to render markdown in Elm.

But for most SPA that just manipulate form data and communicate with the server, it's a pretty great fit.

<comment><USER23> Isn't decoding JSON a big part of an SPA though? How do you deal with data from the server?

<comment><USER10> There exist multiple tools to aid you with writing decoders:

\- json-to-elm [http://json2elm.com](http://json2elm.com)

\- swagger-elm [https://github.com/ahultgren/swagger- elm/](https://github.com/ahultgren/swagger-elm/)

\- elm-graphql [https://github.com/jahewson/elm- graphql](https://github.com/jahewson/elm-graphql), [https://github.com/jamesmacaulay/elm- graphql](https://github.com/jamesmacaulay/elm-graphql)

\- elm-export [https://hackage.haskell.org/package/elm- export](https://hackage.haskell.org/package/elm-export)

Once you've got the hang of it, it's not that hard either. Just time consuming. That's where json2elm comes in :)

</comment></comment></comment><comment><USER24> Something I find incredibly off-putting about Elm is the evangelical and generally unbalanced tone taken by many prominent members of the Elm community. I almost never come across Elm advocates accepting a valid criticism of the language. The response almost always amounts to "you don't understand" or "yes, but". They spend a lot of time celebrating the compiler's humanistic virtues but seem less clearly humanist in their relation to original thinking or diversity of thought. So much of Elm community dialogue (in talks, in articles, in the Elm slack which I follow daily) is simply those with more experience initiating those with lesser experience into the "Elm way" of doing things. For this reason, Elm feels more like a framework with a domain specific language than a fully qualified programming language. And while it might seem like a gentle introduction to functional programming techniques, I'm not confidant that it really teaches people the concepts themselves nor gives them enough room to think critically about how to apply them. Instead, the task is to internalize and apply the "Elm way". The inability to even acknowledge the unprecedented labor required simply to parse a JSON response is a perfect example of the cultish mentality emerging in this community.

<comment><USER25> > less clearly humanist in their relation to original thinking or diversity of > thought

So what you're frustrated with is that a group of likeminded individuals celebrates their common point of interest and doesn't make room for you to nay-say them?

> So much of Elm community dialogue (in talks, in articles, in the Elm slack > which I follow daily) is simply those with more experience initiating those > with lesser experience into the "Elm way" of doing things

This could be said of a lot of PL environments. How many Python tutorials stop midstride to browbeat you about how great Python's way of doing things is? Sure feels like a lot to me.

> The inability to even acknowledge the unprecedented labor required simply to > parse a JSON response is a perfect example of the cultish mentality emerging > in this community.

Right but... what do you want? Acknowledgement? My friend, literally everyone here is agreeing it's harder than JSON.parse. No one argues it is "easier." I can't find a handy example in this thread of anyone saying, "Yeah this is great." There are tools to ease this pain, and there are ways to call external JS code that does this.

At the end of the day though, validating data structures on the wire both structurally and for content is a lot of work. Most Javascript projects don't do it. Hell, most _typescript_ projects just say, 'Well if it breaks it breaks.'.

By pure coincidence this redacted typescript snippet is up on my other screen:

        function validateTaskArgs(cdata: any, ldata: any): [boolean, IDomainObject1, IDomainObject2] {
            if (cdata === null || ldata === null) {
                return [false, null, null]
            }

            const cdkeys = ["key1", "key2", "key3"]
            const ldkeys = ["key1", "key2", "key3", "key4"]

            const checkKeys = (keyset: string[], obj: any) => {
                const result = keyset.reduce(
                    (p, c) => { return p && !!obj[c]},
                    true)
                return result
            }

            return [
                checkKeys(cdkeys, cdata) && checkKeys(ldkeys, ldata),
                cdata as IDomainObject1,
                ldata as IDomainObject2
            ]
        }

This ugly bit of custom logic just to validate a pair of objects in a larger json datastructure, and even that has bugs. This can't deal with a bunch of problems, but it's just too much pain to actually string together the logic in a composable way in typescript, so I accept this kind of drudgery.

But earlier I actually linked a much more sophisticated piece of purescript that's about the same size and not only is easier to read and is self- describing (the code to build the objects IS the spec), but it uses those properties to report console errors. You can see it here:

[https://gist.github.com/KirinDave/9af0fc90d005164743198692f3...](https://gist.github.com/KirinDave/9af0fc90d005164743198692f380d4d9)

If you want to make Elm better at JSON, that's the sort of stuff you wanna ask for. And folks will rightly be resistant. Because the programming concepts that make that work (free applicative, in this case) are not things the elm target audience has learned about, yet. Elm's leadership is acutely aware of how big a stack of new concepts they're putting on everyone's plate, and they're cautious about offering more.

<comment><USER24> Thanks for the code snippets. That actually helps me to understand quite a bit how Elm's JSON parsing situation can be improved within the FP paradigm.

> So what you're frustrated with is that a group of likeminded individuals > celebrates their common point of interest and doesn't make room for you to > nay-say them?

I'm not frustrated with responses to criticisms I've made. In fact, I haven't made any criticisms (except of course, the ones in the last comment :P). So I don't have any experience of anyone not making room for _me_. But I have observed some smart people with well-articulated suggestions get shut down. It's not that their suggestions weren't accepted but it was the way that their ideas were received. I haven't actually seen someone who isn't Evan C. contribute something significant that isn't "doing X like Evan would do it." In the entire world of this language, there seems to be 1 architect and a community of implementers. Now, there's nothing wrong with being an implementer. I am an implementer. But it seems easy to see that cultures are healthier when there are a diversity of ideas.

I think that your characterization of the Elm community as a "group of likeminded individuals celebrat(ing) their common point of interest" is actually close to what I'm talking about. It's great when a programming language community is passionate about the language. If people enjoy using that language, it's certainly a good sign. But I wouldn't trust the judgment of a group of people who can't critique what they love and are unwelcoming to those who do.

The counterpoint here is Dan Abramov and the Redux community. Dan is continually pushing people to understand why they are using Redux and _not_ to see it as a solution for everything. That kind of transparency, and the continual acknowledgement by Redux maintainers that there is more than one good way to do something, is the kind of intellectual honesty that I'm using as a standard in my assessment of Elm.

> How many Python tutorials stop midstride to browbeat you about how great > Python's way of doing things is?

I couldn't say and it wouldn't change my opinion of Elm.

</comment></comment></comment><comment><USER26> Anyone familiar with both Elm and Clojurescript ?

Clojurescript's 're-frame' lib implements something similar to the Elm architecture and is quite pleasant to work with.

How does the Elm experience compare to the Clojurescript experience ?

<comment><USER27> Similarities:

1) Re-frame and Elm are both backed by a virtual dom (Re-frame leverages React behind the scenes, Elm uses virtual-dom)

2) Both impose a single app state

3) Both require user events and outgoing state mutation to be explicitly defined somewhere outside of the context of a view

4) Both operate on a sort of "game loop" style of processing events and calling view functions

5) All data is immutable in both languages (though Clojurescript provides explicit mutable structures if desired, which require special syntax so any mutation is evident)

Differences:

1) Elm's model is pure FP -- data is passed to a function, and then it calls other functions. An individual view function in Elm cannot independently subscribe to any kind of data event, either a state change or a socket message, etc; it must receive the data it needs as an argument to the function only. Depending on who you talk to, this is either limiting or properly restrictive. It does mean that a branch of your Elm user interface should generally correspond to a single branch of your app state, or that view functions in complex interfaces must take quite a lot of arguments; this is a pattern for which re-frame explicitly offers a workaround (though you can also do it the Elm way in re-frame if you want). In general, these differences lead to more re-usable components in re-frame than in Elm.

2) Elm has no real asynchronous library for high-level concurrency. Most Clojurescript projects (at least large SPAs) often leverage core.async as an abstraction for large UIs that handle many independent processes simultaneously. Core.async makes clojurescript particularly versatile for accomplishing things in a single-threaded environment as if it were modelled with multiple threads.

3) Elm has its own compilation story that is separate from the JS ecosystem. The Elm devs are working on dead code elimination. Clojurescript projects are all built on Closure, which provides DCE, compression, and global inlining which can provide some projects notable speedups. The Closure libraries also give Clojurescript cross-browser abstractions for hundreds of common tasks in front-end development that have been battle-tested by Google in all of their web services, so it can greatly reduce development and debugging time for complex apps that run everywhere.

4) Elm controls JS interop much differently than Clojurescript. The tradeoff is that in Clojurescript you will inevitably spend more time debugging runtime errors, while in Elm you will spend more time developing your JS interop code and testing cross-browser compatibility.

5) There are many UI libraries available for re-frame because it can wrap existing JS tools (including wrapping UI libraries built for React). There are fewer for Elm, and it's more common to roll your own UI in Elm. There are pros and cons here. I've worked on two large projects in Clojurescript, one which was all custom UI components and another that leveraged polished libraries in the wild. The former took much much longer to make but looked more unique. Having the choice to go either way is a big benefit since project goals widely vary. If you are primarily a developer/coder and not a web/graphic designer, you may be frustrated at UI design in Elm. If you work with a designer, this is not a problem. But if you work alone, having access to a lot of UI tools can free up your time and efforts quite a bit, and Clojurescript has an edge here.

6) Types: Elm has static types, while Clojurescript offers clojure.spec (which is optional though widely used). Spec is a runtime contract system so you can guarantee that all args passed to functions or setup in data structures meet specified criteria; not just types of the args, but also any other predicates, such as a valid range for an integer, etc. For example, an Elm union type would be a Clojure set, where each element could be a specific data structure with other specs attached to it. However, Elm has proper static types, which are caught at compile time, not runtime. There are benefits of both styles. If you want to tightly catch very specific data aberrations that flow through an app, clojure.spec is easy to use for that purpose; but if you want more general checks before the program runs, Elm would be preferable.

7) Performance: All of Clojurescript libraries that wrap React (including Re- frame, vanilla Reagent, and Om) offer an interesting runtime optimization that I've not seen in other languages, and is not available in React itself. If the data that a view function requires (either via its arguments or subscription) has not changed from the prior render frame, then the entire view function is skipped without running, since its output would not be any different. What this means is vast sections of your app's code don't even need to run on each render frame, and this is not trivial. In a small app, it would make no difference, but in complex SPAs this can be very significant. Elm offers a library, Html.Lazy, that attempts something similar, though my impression is that most Elm projects do not use it since it can be tricky to explicitly add this behavior; in Clojurescript, it is built in automatically. In Re-frame, they go an extra step by de-duplicating any queries or subscriptions so that multiple views which use the same data context do not query, fetch or calculate the required data more than once, which is then passed to all requested functions. If you are working on an app that processes lots of data frequently, this can be the single selling point of using Clojurescript, as it frees up the CPU to deal with only those things that are guaranteed to require processing.

Clojure's syntax is very tight and concise, while Elm's language is elegant but more verbose. I have found that there is approximately a 2.5X increase in code size in Elm when trying the same ideas out in both languages.

All other things being equal, you can probably get a re-frame app going very quickly; if you need to prototype something or get to an MVP as soon as possible, it is really hard to beat Clojurescript compared to any other compile-to-JS language. If however you are going for application purity and a reduction in runtime debugging, Elm (or Purescript or some other statically- typed languages) would be a better fit.

Ultimately, Clojurescript is a general purpose language, while Elm has a very specific use-case; if you fit into the Elm model, it can be nice. If you need to reach outside that model, it is a challenge.

<comment><USER28> Worth mentioning that Clojure(Script) comes from a different school of thought (Lisps) and has its own approach to development called REPL driven development. It allows you to experiment a lot and fail fast.

Large projects are absolutely doable but require more discipline and experience with the language from developer. For example you can start with a crude prototype and introduce clojure.spec later. When you do this is entirely your choice while in Elm you just have to write function signatures and types/structures definitions from the beginning.

ClojureScript has a very easy interop with JavaScript. Actually this is one of design goals. Consuming JavaScript library is super easy. For example most of virtual DOM libraries are built upon React. This is good because writing performant virtual DOM with older browsers support isn't an easy task.

The toolchain has code splitting and dead code elimination. It had it long before Webpack and can even optimize imported JS libraries code. As far as I know Elm still can't do it.

Another good thing is you can use Clojure(Script) both on the client and the server. This allows you to nearly skip data serialization/deserialization using powerful "transit" library. Actually you can use transit on server with several other languages. So it's not a lock in but it's much smoother with Clojure.

The libraries ecosystem is rich. For example Clojure(Script) has a mature WebSockets library (it's both server-side and front-end) with any kind of fallback you can imagine.

<comment><USER27> I agree with much of your points but a few things to add clarification:

While lisps do traditionally provide repl-driven development and you can do this in Clojure, most Clojure devs I know are not actively working right at the repl. If you do like some aspects of repl-like interactivity, Elm does have elm-reactor which has some similarities to Clojurescript's figwheel, though not quite as mature or comprehensive.

Aside from the repl, you are right that you can get a proof-of-concept going in Clojurescript extremely fast so if you want to see if an idea succeeds or fails before investing lots of time, you can't beat Clojurescript.

The Elm toolchain is slowly evolving to include things like dead code elimination (which it doesn't have yet but probably will in the near future). However, I think it will be a long time (if ever) that Elm will support global inlining, automatic variable renaming and some other optimizations that come for free with the Google Closure compiler support. The other important difference is that as the Google Closure compiler adds features or further improves its optimizations, these are mature and widely used and immediately available for free without much (if any) extra work on the Clojurescript team. It's a philosophical difference that the Elm devs prefer to solve these problems on their own rather than leverage existing tools in the industry, but since the Elm dev community is small (much of it is only one person), this means that lots of time must be spent on these solutions at the expense of features more specific to the Elm language.

Also I think you are right that Elm as a language is a little easier to learn than Clojurescript (though to someone new to FP, both Elm/Haskell style syntax and Lisp syntax might be equally bizarre). But I think that ease is made up for by some of the concepts in Elm that can be difficult to learn (decoding, Tasks, ports, etc), so it's probably a net flat difference on the learning curves between the two systems.

<comment><USER21> I believe you can use Google Closure Compiler on Elm JS files with great effect the same as Leiningen uses it on ClojureScript JS files. (Although most people probably use uglifyjs instead.)

But of course ClojureScript's JS is generated carefully so as to be better optimizable by Google Closure Compiler, and that's not the case with Elm. IIRC, in version 0.19 Elm will change it's JS so that it's better optimizable by uglifyjs.

<comment><USER27> > I believe you can use Google Closure Compiler on Elm JS files with great > effect

No, you can't use the advanced optimizations from Closure compiler in Elm. This is unlikely to change any time soon because Elm's compiler emits JS that directly violates one of the restrictions that Closure requires for advanced optimizations, namely the referencing of field names as a string.

<comment><USER21> Good to know, thanks!

</comment></comment></comment></comment></comment></comment></comment><comment><USER29> I've used Elm for a while and I don't really see what's the problem about JSON decoders/encoders. Sure, they're verbose and annoying to write if you have a particularly intricate JSON structure, but I don't really see a better alternative for decoding and encoding JSON in a type-safe way, and with Elm's constraints on ease of learning.

More freedom on type-level programming would help, but that would certainly complicate the type system, and the only language I know that lets you fold over arbitrary record types is Ur/Web, which has a richer type system than even Haskell, and I don't see Elm adding things to its type system (other than type classes, hopefully), given that other interesting features were already removed because very few people used them.

</comment><comment><USER30> Quick question.

> Want to measure the height of an element on the page at the moment a user > clicks on it? Hard, in order to do this we had to make heavy use of event > bubbling and writing JSON decoders for the native event.target object that > is produced by an onclick event.

What would be considered best practice?

Is it best practice to re-implement this sort of thing? Seems one could easily find vanilla JS code and encapsulate it, or add a helper lib?

</comment><comment><USER31> I think JSON decoding is great in Elm. Actually, that may be the best part of that language.

</comment><comment><USER32> When JSON decoding is hard this is not a minor thing when looking at my RESTful APIs. This is a major trade off. How to deal with it ideally?

<comment><AUTHOR> Author here. JSON decoding is hard relative to what it is like in JavaScript. In your JS code you can just call JSON.parse() and get the corresponding JavaScript object.

In Elm, decoding is not nearly as easy as it is in JS because every field must be explicitly converted to an Elm value. Depending on the complexity of your conversion from JSON to Elm value (e.g. whether you are just decoding to primitive values or to custom types defined in your program), there may also be a bit of a learning curve.

As I stated in the post, there is a benefit in doing all of this: your Elm application will effectively type-check your JSON and reject it if it is malformed.

<comment><USER33> > JSON decoding is hard relative to what it is like in JavaScript

I'm not making a joke but this is a valid point. And if it had ELMON (Elm object notation), things would be more straight forward.

<comment><USER34> No, that is not a joke. If one tried to convert an Applet to HTML5 and came across a server backend that returned serialized Java objects, parsing that into JS would have been significantly harder than the two lines with ObjectInputStream it would take in Java.

</comment></comment></comment></comment><comment><USER35> Great article! I have no experience with Elm but I'm much more likely to try it out now. I'm curious to hear your thoughts on this though:

[http://reasonablypolymorphic.com/blog/elm-is- wrong](http://reasonablypolymorphic.com/blog/elm-is-wrong)

<comment><USER36> The core complaint is the lack of typeclasses. If your coding style relies heavily on generics, maybe Elm isn't for you.

<comment><USER37> Why? Elm has generics.

</comment></comment></comment><comment><USER38> When I last tried Elm, I didn't find any really good UI libraries. Also there weren't any good solutions for i18n. Has the situation changed?

<comment><USER27> Depends on your needs. If you are targeting desktop, there are a couple of UI libraries for Elm. However, they are buggy when you try to test them out on a mobile tablet. I have found that most Elm developers create their own UIs since wider access to JS UI toolkits is not easy. That does mean that you need to enjoy general web design or work with a designer, or be willing to put in extra time when working in Elm.

<comment><USER38> Yep, Agree. I specifically used elm-mdl and elm-ui. Elm-mdl were not well maintained and elm-ui, while nice, is desktop only.

</comment></comment></comment><comment><USER39> "JSON-based RESTful API as its back end" what language do you use for the backend, Haskell?

<comment><USER22> You can use anything that can expose an HTTP port. It doesn't have to be Haskell.

</comment></comment><comment><USER40> I wonder if its successor framework will be called pine.

<comment><USER41> 2019: JSON decoding in Mahogany-lang is hard…</comment></comment>


Blogcast WordPress Migrator - <AUTHOR> http://techoctave.com/c7/posts/43-blogcast-1-0-5-release-notes-and-the-wordpress-migrator-tool

<comment><USER2> That looks really good, does it work OK on Heroku?</comment>


Memory card recovery software - <AUTHOR> http://www.p-dd.mobi Memory card recovery software has non destructive and read only utility which helps you to get back your precious files without any data loss. <comment><USER2> Does that work? Under what conditions would a flash card still be recoverable?</comment>


U.S. Terrorism Agency to Tap a Vast Database of Citizens - <AUTHOR> http://online.wsj.com/article_email/SB10001424127887324478304578171623040640006-lMyQjAxMTAyMDEwMzExNDMyWj.html?mod=wsj_valettop_email <comment><USER2> Already on front page.

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

Submitting the canonical URL helps with popular articles like this.

<comment><AUTHOR> Usually I do a better job checking. Apologize.</comment></comment>