Cloudflare Workers now supports COBOL - <AUTHOR> https://blog.cloudflare.com/cloudflare-workers-now-support-cobol/ <comment><USER2> This was a higher-effort post than I had expected.

The Game of Life implementation pushes itself into my Back-button browser history, which is rather annoying, but it was very cool to see some COBOL besides the obligatory Hello World.

I hardly think anyone maintaining crusty old systems will be allowed to move to Cloudflare Workers, but it is rather amazing and funny to see that it could technically now be done.

Great job and great post!

<comment><USER3> I think you'd be surprised how eager the owners of crusty mainframe systems are to stop managing ancient infra and how heavily they have been sold on serverless / "the cloud".

<comment><USER4> I've never really heard this from anyone that is actually technical. I think people with actual technical skills and joy would be quite impressed by mainframe systems.

The issue for management is you can't copy someone else's strategy like hiring random fungible devs so easily, you need to invest in some training and retaining. So if you're a stuffed shirt the easiest thing to do to explain your lack of leadership and foresight is to point to the mysterious system and point to other companies doing (x, y or z) and say you need to be more like them in a copycat way with little consideration for the difficulty or success of the existing business and systems. The evergreening that goes on in tech is extremely low dividend activity for any business but the new employees and new vendors make a lot of money until they too are out fashioned.

<comment><USER5> Really? My impression is that you have to scour the earth for people who know anything about those systems, and then pay them 5x what you would pay someone working on a modern system.

<comment><USER4> Did you like.. actually read my comment? Poorly run companies want the equivalent of a Scala dev with 30 years of Scala experience. It doesn't work like that. Computer systems and PLs aren't that hard to pick up.

</comment></comment></comment></comment></comment><comment><USER6> > Our work can be used by anyone wanting to compile COBOL to WebAssembly

future is now

<comment><USER7> Cobol compilers for JVM and CLR exist since 20 years now, but yeah WebAssembly is that new thing that no one else has ever done before.

</comment></comment><comment><USER8> So, was this a delayed April Fools joke/project that had to wait until the anti-April Fools backlash of 2020 subsided?

I wonder how many other projects like this were cancelled or delayed.

<comment><AUTHOR> This is not a joke at all. We are serious about WebAssembly in our serverless platform and showing that it can support languages like COBOL is important.

<comment><USER9> The hardest part about WebAssembly that I found is that very few projects document their ABIs. For example, I want to write a Rust WebAssembly program to do whatever with CloudFlare workers (literally anything, just to try it).

Is there a page listing all the functions I can import and call? IIRC I had only managed to find some "hello world" examples, ran them, they did indeed say hello world, and then I thought "well okay, now I know how to return stuff and nothing else" and gave up because I couldn't find documentation on other calls.

<comment><USER9> Ahh, yes, that helps a lot, thanks Steve! I missed the fact that the wrapper is what the backend communicates with, and then the wrapper calls wasm. I thought the backend would call wasm directly (and that I could just not have a JS wrapper at all).

It would be extremely helpful if this was mentioned somewhere on the starting docs (maybe it is and I missed it?).

<comment><USER10> Any time!

Where did you look for this information? I can file a bug, but knowing where to put it would be helpful.

<comment><USER9> Great question. Because I was thinking that I could use workers with just rust, I Googled for "CloudFlare workers rust" and ignored anything that had JS in it. I can tell you where I probably was when I get to my computer if you want, it was probably the CloudFlare articles about Rust and workers.

EDIT: Oops, looks like I replied to my own comment before, HN mobile app fail. Luckily, you saw the reply.

<comment><USER10> Cool thanks :) I think that's still helpful.

<comment><USER9> No problem! I looked again, and I think I looked around at the blog articles, wrangler and messed a bit with the examples, then didn't make much sense of it and gave up.

I would have had much better luck if I had seen what you told me, ie "you can call wasm from JS" rather than thinking I could somehow execute wasm directly on the worker. Thanks again!

<comment><USER11> Unrelated but if you are the same guy that wrote the wireguard blog post, thank you!

It was the only one I could follow and get up and running really quickly. And my go-to when I setup a new instance if I need to.

<comment><USER9> I am, thanks, glad you liked it!

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> Gnu Cobol is an interesting project, they support a lot of dialects. One big draw back is the generated code isn't thread safe so cgi is about the only option for server side apps. Maybe someone more familiar with the project could comment on that?

<comment><USER13> It's kind of funny that you mention "only cgi" as a drawback on an article discussing "edge workers" \- not sure if they're like "serverless functions" (new vm pr request) - but I'm assuming they're heavier than "just" new process pr request :)

<comment><USER10> They're much, much lighter than a process. They're a V8 Isolate, basically a VM thread.

<comment><USER13> Thank you (and sibling comments)! Cunningham's Law still works wonders, it seems ;) (and no, I wasn't aware there were such a light weight primitive beneath cf workers - so I didn't make a "false"(ish) claim on purposeose ).

Ed: although for rust, and maybe go - i suppose the wasm vm does add quite a bit of overhead? Compared to just compiling to machine code.

Are there any open source application servers built around the same architecture? I gather the cf worker implementation itself isn't released as open source?

<comment><USER10> There's no separate VM; since we're using V8, it does everything. Some folks have made standalone webassembly VMs, but web browsers run wasm in the context of their existing JS vm, and we're following browser tech, even though it's "server side" in a sense :)

wasm is a bit slower than native, but it all depends. All of this is being actively worked on by folks, and so numbers change.

> Are there any open source application servers built around the same > architecture? I gather the cf worker implementation itself isn't released as > open source?

There's nothing _exactly_ like workers that's open source, and yes, our implementation isn't open source either, though I would love for that to be the case. There is some stuff that's sort of similar in some senses that is open source; a lot of folks are playing around with server-side wasm. But they have different properties than Workers does. So maybe that's a comparison in one sense, but it's very much not in another sense.

<comment><USER12> I always thought lua and luajit would be great at this but no ones ever done it.

<comment><USER13> I'm not quite sure which "this" you mean, but there's:

Lua and varnish [https://github.com/flygoast/libvmod- lua/](https://github.com/flygoast/libvmod-lua/)

Lua in nginx [https://openresty.org/](https://openresty.org/)

And lua in haproxy - for example to verify jwt tokens: [https://github.com/haproxytech/haproxy-lua- jwt](https://github.com/haproxytech/haproxy-lua-jwt)

So depending on if you mean green-thread/sandbox or smart edge side includes - or application server... There may or may not be some thing out there already..?

</comment></comment></comment></comment></comment></comment></comment><comment><USER14> Is there a list of languages Cloudflare Workers supports? From what I can tell, it's JS, Rust, C, C++, and now COBOL.

So... no PHP then? Seems like it would be a good fit, no?

<comment><USER10> The officially supported languages are:

* JavaScript (and TypeScript)

* C and C++

* Rust

Other languages may _work_ , and we we won't stop you from using them, but you may run into problems. The main issue with getting most languages to work is that we support JavaScript and WebAssembly, which means any other language needs support for compiling to wasm before it's even possible. Once it is, we have a one megabyte limit for the size of a worker, and so many other languages won't work because their minimal wasm output is too large.

We'd like to support more in the future. It takes a lot of work.

<comment><USER15> Thanks. Official languages aside, are there plans to support protocols other than HTTP? Say, WebRTC? Or, even raw TCP/UDP sockets. From what I know, Spectrum lets one deal with L4 and MagicTransit with L3 (provided BYOAnycastIP), but will there be a way for Workers to be an _origin_ to those?

<comment><USER10> We would like to do this as well, yes, but I can't make any commitments regarding it.

</comment></comment></comment></comment><comment><USER16> There's a related thread about the "discovery" of the source of the Terminator COBOL from a few days ago--and the original author is still alive and well and programming mostly in CUDA/C++, Erlang and Elm according to his Twitter.

[https://news.ycombinator.com/item?id=22857531](https://news.ycombinator.com/item?id=22857531)

</comment><comment><USER17> That page generates an entry in my browser back history every second.

<comment><AUTHOR> Yeah, sorry about that. We'll change it.

Edit: Done.

</comment></comment><comment><USER18> This reminds me of another classic: [http://www.coboloncogs.org](http://www.coboloncogs.org)

<comment><USER19> I thought of [https://github.com/azac/cobol-on- wheelchair](https://github.com/azac/cobol-on-wheelchair)

</comment></comment><comment><USER10> I _almost_ got Pascal working, but ran into a compiler bug.

</comment><comment><USER20> A very practical question: I am language agnostic. Lots of people have commented about COBOL and FORTRAN performance for purely mathematical problems, given the amount of man-hours that went into the libs used by these languages when computing resources were scarce.

That caught my eye. Because for what I do, every little bit of performance matters. There are no hiring constraints - I will get whoever and whatever I need, as long as it can be shown to increase performance - mostly latency, but also speed of computation on given hardware.

Can I expect practical gains in a COBOL implementation of mathematical algorithms? (mostly matrix inversion and multiplications, but not just that)

<comment><USER21> I've done some programming in Fortran in school doing computational physics. From what I can tell it isn't necessarily that the languages are super fast, compared to any other compiled language. You can get similar speed out of Fortran as C or C++ by doing the normal performance conscious practices of not allocating a lot of memory during calculations, optimizing loops, etc. Fortran has a lot of scientific packages that have been optimized very heavily, and those are linkable from other language, that is whay Scipy in Python is essentially. The Cobol I have touched isn't really that optimized I think, mostly just business code. But its fast due to no abstractions and being compiled.

I don't think you would get gains from Cobol per se, and it might not be worth it compared to just writing C or C++ in a high performance manner.

<comment><USER22> Fortran as a language had some advantages over C for high-performance numeric code (eg more restrictive aliasing rules or stack-allocated variable-length arrays). C99 addressed this.

<comment><USER7> C99 kind of addressed it, unless one manually takes the effort to properly place _restrict_ in the correct places, and not mistakenly misuse it (possibly triggering UB), it won't match what optimizing Fortran compilers are capable of without any additional effort from the programmer.

<comment><USER22> But note that that as far as I'm aware, Fortran compilers will happily miscompile code that breaks the aliasing assumptions as well. No matter which language you use, it's the responsibility of the programmer to not break these invariants, the main difference being that Fortran doesn't force you to type out `restrict` first.

<comment><USER7> In Fortran there aren't aliasing assumptions as in C, given that they are forbidden by the type system.

<comment><USER22> It's forbidden by the language standard, hence compilers _assume_ no aliasing occurs, but it nevertheless may do so due to 'non-conforming' code.

In the words of the g77 manual:

> Essentially, compilers are promised (by the standard and, therefore, by > programmers who write code they claim to be standard-conforming) that if > they cannot detect aliasing via static analysis of a single program unit's > EQUIVALENCE and COMMON statements, no such aliasing exists. In such cases, > compilers are free to assume that an assignment to one variable will not > change the value of another variable, allowing it to avoid generating code > to re-read the value of the other variable, to re-schedule reads and writes, > and so on, to produce a faster executable.

> [...]

> Unfortunately, there is no way to find all possible cases of violations of > the prohibitions against aliasing in Fortran code. Static analysis is > certainly imperfect, as is run-time analysis, since neither can catch all > violations. (Static analysis can catch all likely violations, and some that > might never actually happen, while run-time analysis can catch only those > violations that actually happen during a particular run. Neither approach > can cope with programs mixing Fortran code with routines written in other > languages, however.)

Like in C, it will result in undefined behaviour (though the Fortran spec doesn't use the term).

<comment><USER7> Fortran 77, when the latest version is Fortran 2018?

Nevertheless, that is like describing C semantics with something that is only possible in GNU C.

Naturally if one goes outside what the standard allows, everything goes.

<comment><USER22> _Fortran 77, when the latest version is Fortran 2018?_

It was the first relevant search result. Feel free to look for more recent resources on the topic, eg [https://www.sciencedirect.com/science/article/pii/S157106610...](https://www.sciencedirect.com/science/article/pii/S1571066104803967) (still a bit dated).

 _Naturally if one goes outside what the standard allows, everything goes._

Which makes the Fortran situation essentially the same as the C one once you've typed out `restrict`.

<comment><USER7> Not really, because the standard is what defines the language, just because GNU Fortran does non conforming stuff it doesn't mean that for example PGI Fortran would do the same non conforming behavior.

By the same measure I can assert that C++ is a memory safe language given that Visual C++ enables bounds checking and iterator invalidation in the standard library by default.

<comment><USER22> The C language standard makes certain guarantees, such as no out-of-bounds array access, or no modification of memory accessed through a restrict- qualified expression by other means.

If such things happen during program execution, the program does not conform to the standard, and its runtime behaviour becomes undefined.

This is exactly the same situation you have with Fortran, which makes certain guarantees about, say, the aliasing of function arguments. If all such cases could be detected ahead of time, it would be impossible for programmers to write non-conforming programs. This is not possible.

I repeat, there is no essential difference between the Fortran and C situation. The best one could argue is that given that the Fortran guarantees are universal (instead of limited to restrict-qualified pointers), a Fortran programmer is less likely to write an incorrect program, but that's it.

<comment><USER7> I guess we have different ways to interpret ISO standards documents, so let's leave at it.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER23> At first, I thought this was a 1st April joke. It's impressive what can be done inside the CF workers using the WebAssembly feature of V8. Now I can learn a 60 years old lang to run on the closest CF datacenter :3

</comment><comment><USER7> While a nice achievement for WebAssembly, it is nothing new as concept.

Cobol on the JVM:

MicroFocus

[https://www.microfocus.com/documentation/visual- cobol/VC40/E...](https://www.microfocus.com/documentation/visual- cobol/VC40/EclWin/GUID-DEAFFCA6-6D75-4AEA-A3B6-6DF0BDCF3E2F.html)

Fujitsu

[https://software.fujitsu.com/jp/manual/manualfiles/m150010/b...](https://software.fujitsu.com/jp/manual/manualfiles/m150010/b1wd3373/01enz200/b3373-00-03-02-01.html)

Cobol on the CLR:

MicroFocus

[https://www.microfocus.com/documentation/extend- acucobol/101...](https://www.microfocus.com/documentation/extend- acucobol/1011/BKITITDOTNU001.html)

Cobol on the CLR and Azure:

GT Software / Fujitsu

[https://www.gtsoftware.com/products/netcobol/netcobol-for- ne...](https://www.gtsoftware.com/products/netcobol/netcobol-for-net/)

</comment><comment><USER24> So I guess you could use [https://github.com/azac/cobol-on- wheelchair](https://github.com/azac/cobol-on-wheelchair) and develop your entire app in a Worker. Great!

</comment><comment><USER25> Next: Microsoft Basic

<comment><USER26> GORILLAS.BAS.museum

<comment><USER27> I think DONKEY.BAS is more famous

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

<comment><USER28> I don't recognise the name DONKEY.BAS, but I spent plenty of time in my youth with GORILLAS.BAS and have heard it mentioned from time to time since then.

<comment><USER27> I should clarify DONKEY.BAS was (probably) not famous for gameplay as much as the author.

</comment></comment></comment></comment></comment><comment><USER29> I'm still not understanding what it means for their workers to support COBOL?

<comment><USER30> I'm pretty sure cloudflare has a service called "Workers" and that this doesn't literally mean that their employees support COBOL.

<comment><USER10> This is correct, yes.

</comment></comment></comment><comment><USER31> Off-topic, but I hadn't seen the xkcd comic and it actually brought a tear to my eye. What a beautiful homage!

</comment><comment><USER32> art

<comment><USER33> Oh hi ArtDecider.</comment></comment>


Ann Arbor's start-up culture v. collapse in Warren, Michigan - <AUTHOR> http://online.wsj.com/article/SB124329299105252505.html

<comment><USER2> Having spent a few years in Ann Arbor, it is almost like it is not in Michigan. But then again, Michigan has more variety by many measures than most states.</comment>


Cthulhu Ventures - <AUTHOR> https://cthulhuventures.com/ <comment><USER2> (I'm assuming that this is not satire - it looks a bit too real)

I really love it when people carry jokes into serious business and take it all the way to the end. There's a lot of guts in that. I envy that level of self- confidence and hope to one day get there myself.

That said, somehow I love it even more when such jokes get featured on HN and, invariably, shares of dry humorless grumpy people complain that they can't _possibly_ take people who make jokes seriously. I always wonder what brings someone to distrust ballsy humor, I can't really wrap my head around it.

Personally, if someone has the guts to not only make a silly joke with friends over a beer, but actually turn it into a real thing (in this case, a venture fund), then that's the kind of person I want to do business with. That sort of guts shows elsewhere too (Elon Musk is a nice example).

<comment><USER3> I think a lot of people value that HN isn't the kind of place where you get puns and flippant comments and posts.

<comment><USER4> I turn to Reddit for that. Here on HN humour is generally very lacking and even frowned upon. Things lighten up a bit when people like idlewords[1] show up, but that's pretty much the exception. For a recent example, just read through the comments in here[2] (a Show HN that reached the homepage yesterday). This is a regrettable state of affairs.

1: [https://news.ycombinator.com/user?id=idlewords](https://news.ycombinator.com/user?id=idlewords)

2: [https://news.ycombinator.com/item?id=21627714](https://news.ycombinator.com/item?id=21627714)

Edit: forgot that HN also lacks Markdown besides humour

</comment></comment></comment><comment><USER5> > We also strive, in our weak moments, to generate some sort of meaningful > "good" for humanity (whom we would like to see at least survive until the > day that we, ourselves, rise from those same dark depths to act as the > harbinger of mankind's final doom).

Chtulhu Ventures seems to be far more invested in the the good of mankind than the average SF VC.

</comment><comment><USER6> Ph'nglui mglw'nafh Cthulhu Ventures R'lyeh wgah'nagl fhtagn

<comment><USER7> Nice try, mortal

</comment></comment><comment><USER8> I expected The Team to include Yog Sothoth.

</comment><comment><USER9> Comedy comment in a standard post? Downvotes.

Comedy name for a VC firm on a site where people hope they can get VC cash for their "it's the Uber of XYZ industry" start-up?

"Epic lulz sir! Taking jokes into the business world is brave!"

</comment><comment><USER10> I hate to ask this but is this satire?

<comment><USER11> Nope looks real after digging deeper. Based on the portfolio it looks to be based on Australia or NZ.

<comment><USER12> The website footer Contact section:

      Cthulhu Ventures llc
      100 Shoreline Hwy • Suite B280
      Mill Valley, CA 94941
      Tel: 415-444-9602 • Fax: 415-444-9602
      info at cthulhuventures.com

</comment></comment></comment><comment><USER13> We invest in things that should not be

</comment><comment><USER14> Portfolio looks interesting, Life360 is big. Unfortunately, this website is poorly designed to put it lightly.

I get that one of the founders really likes Lovecraft, but spend some money and do the website right instead of finding cthulu pictures off of google images and pasting them into a template.

<comment><USER15> [https://www.wired.com/story/life360-location-tracking- famili...](https://www.wired.com/story/life360-location-tracking-families/)

>Parents can use Life360 to track their teen's location in real time. The company can use that data to sell car insurance.

I think apps which allow parents to monitor their kids and invade their privacy are bad for humanity.

<comment><USER16> You think? It seems like about the one valid use case for tracking. I bought phones for my kids on the proviso they would be primarily for safety purposes. Though it will start to get a bit grey as they get older.

</comment></comment></comment><comment><USER17> Finally a venture capitalist I can trust.

<comment><USER18> Cthulhu 2020. Why choose the lesser evil?

<comment><USER17> Nyarlatothep 2020: The Dark Pharao for President!

Hastur 2020: Who but that which is already the yellow king?

<comment><USER19> > Nyarlatothep 2020: The Dark Pharao for President!

He's standing for Prime Minister of the UK, but in his views, that doesn't disqualify him from running for president too. No "dirty laundry", so to speak.

<comment><USER20> I take it you are a fan of the Laundry Files then?

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

<comment><USER19> You might very well think that; I couldn't possibly comment.

<comment><USER20> Or your head catches fire?

</comment></comment></comment></comment></comment></comment></comment><comment><USER21> Checked the Portofolio and seems to be... authentic? Cthulhu Fhtagn!

</comment><comment><USER22> Slightly off-topic, but is "The Call of Cthulu" still worth reading?

I haven't read it yet, so I'm curious if it's somewhat dated, or tame according to modern sensibilities.

<comment><USER23> It's very short. Go for it. Personally it's one of my least favorite short stories by Lovecraft and it's amusing to me that Cthulhu became so wrapped up in popular culture when there are many far more interesting beasties in his lore.

<comment><USER22> Thanks! Which of his stories would you _most_ recommend?

<comment><USER24> The color out of Space[1] is pretty good! However the Dunwich Horror[2], The Shadow over Innsmouth[3], At the Mountains of Madness[4], and of course, the Call of Cthulhu[5] are all good.

[1] [https://www.youtube.com/watch?v=TXyda5iiGEo](https://www.youtube.com/watch?v=TXyda5iiGEo)

[2] [https://www.youtube.com/watch?v=gKkya1pMhMQ](https://www.youtube.com/watch?v=gKkya1pMhMQ)

[3] [https://www.youtube.com/watch?v=gviofDcypzE](https://www.youtube.com/watch?v=gviofDcypzE)

[4] [https://www.youtube.com/watch?v=e2iSmE129uQ](https://www.youtube.com/watch?v=e2iSmE129uQ)

[5] [https://www.youtube.com/watch?v=XM9Z39D1yyI](https://www.youtube.com/watch?v=XM9Z39D1yyI)

</comment></comment></comment></comment><comment><USER25> Cthulhu Mythos is the best example of open source in the genre we now know as Weird Fiction.

All Hail, Cthulhu!

</comment><comment><USER26> The percentage put into advertising is kinda low

</comment><comment><USER27> I appreciate their commitment to the bit. I wish their team included slightly more diversity however.

<comment><USER22> I just had mandatory diversity training, and TBH I'm genuinely confused about what is considered acceptable by its proponents.

If your comment is based on diversity of gender, it seems to run afoul of several "diversity" tenets I was just taught:

\- It infers their physical gender based on their appearance.

\- It conflates physical gender with gender identity.

\- It infers race based on physical appearance.

\- It infers ethnicity based on apparent race.

\- If brings up the topic of those particular persons' races, ethnicities, physical gender, and perhaps gender identities, when you can't be sure they want them to be discussed.

I'm not trying to be snarky with this comment. I genuinely don't understand what it is that the diversity-advocating crowd is advocating regarding acceptable discussion.

<comment><USER28> You're overthinking this.

Humans have to make basic baseline assumptions when interacting with people. This is normal, and there is no majority voice in the community that advocates for increasing diversity that is saying you can't do this. The 'DID YOU JUST ASSUME MY GENDER?' stuff is is an out of the norm reaction that has largely been co-opted into a meme by those that are against increased diversity as an attempt to ridicule it. The same with the 'identifying as an attack helicopter' crap. There are definitely extreme voices, but they are a small minority.

The goal for those who are pushing for diversity and continuing to combat sexism, racism, homophobia, transphobia, etc. is not to alienate everyone and force them to never believe anything about someone's race, gender, etc. unless explicitly informed. The goal is to make sure you respect that sometimes appearances don't match reality.

I have a lot of good friends. Some of them happen to be trans. I have never seen any of them get upset at someone who misgendered them prior to transition, as long as they made an effort to correctly gender them after being informed. During transition, largely the same. Post-transition it's usually quite obvious, but I still see them exercise patience, at least at first, if the person's demeanor isn't hostile.

As for bringing up the topics - they might not want to rehash it with you, or anyone. That means that if they ask you to drop it or are otherwise expressing discomfort with the subject, do so. Don't debate it right around them (and I'm guilty of this one!). But that doesn't mean don't discuss the issues. They can ignore comment threads on the internet they don't want to read, and those of us not facing those issues need to be cognizant of them and discuss them. In person, not so much - especially in the workplace, where they might not have any way to escape the discussion.

The goal isn't to be the thought police. The goal is to be courteous to others.

</comment></comment></comment><comment><USER29> Sorry but I would not trust a company that brands itself using a mythical monster to give me funding. If I'm putting the future of my company in the hands of some venture-capitalists I'd want to know they're the real deal and a company that uses:

"Our goal, as Cthulhu, is to support initiatives designed to rise from the dark depths of R'lyeh (metaphorically speaking!) and end up destroying or at least disrupting, some market paradigm."

As its opening line does not exude professionalism.

<comment><USER30> [https://www.mithril.com](https://www.mithril.com)

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

<comment><USER29> These I don't really see a problem with. The name is inspired by fiction that's fine. When I go onto a firms website and see images of a mythical monster plastered everywhere that's when it gets a bit ridiculous.

<comment><USER31> A good chunk of countries, counties and cities on the planet have mythical beasts in their official signage. So do the militaries and companies dealing with them. From the other end, entrepreneurial scene is full of discussions about a particular mythical beast, the unicorn (as 'DoreenMichele pointed out upthread). And, of course, dragons.

Really, it doesn't seem to me that you're uncomfortable with mythical beasts _per se_. It's just this creature isn't part of the old, baseline culture. It isn't Greek/Roman/Chinese mythology. It's a part of the _nerd subculture_. That's what I think you're uncomfortable with.

<comment><USER29> > A good chunk of countries, counties and cities on the planet have mythical > beasts in their official signage. So do the militaries and companies dealing > with them.

Yes they do and that isn't a problem. There is a difference between using symbols and names and then branding your entire website with said things.

> From the other end, entrepreneurial scene is full of discussions about a > particular mythical beast, the unicorn (as 'DoreenMichele pointed out > upthread).

The link 'DoreenMichele sent is not the point. I don't care about signage I care about branding. Starbucks isn't using the Mermaid mythology in how it describes its company, it uses it as signage. That's fine no issues there.

Side note: I think the "unicorn" obsession in the tech sector is stupid and overrated. If a company advertises that it's looking for its next "unicorn-x" then I pretty much write them off.

> Really, it doesn't seem to me that you're uncomfortable with mythical beasts > per se. It's just this creature isn't part of the old, baseline culture. It > isn't Greek/Roman/Chinese mythology. It's a part of the nerd subculture. > That's what I think you're uncomfortable with.

I think that's a pretty big leap to make. I have no issues with a company calling itself "Cthulu". I have an issue with how it is plastered all over the site and has even formed its mission statement around it.

<comment><USER32> Pretty sure this is on-point branding and differentiation.

Some people want to work with your faceless pristine professional top-heavy VC firm oozing with pedigree (McK,GS,Ivy galore) and some people want to roll the dice with people who aren't afraid to distinguish themselves from the culture of their herd and go hard (maybe too hard?) on something niche. So their branding is probably serving some use in self-selection and mindshare - I'm sure plenty of people will remember Cthulhu Ventures, for instance.

I'm ambivalent either way, I wouldn't judge too about this book based on its cover per se other than they've clearly thought about how they want the cover to be received which is a data point in and of itself. I suppose better that than not thinking about the cover whatsoever.

<comment><USER29> If that's what they're going for then fine. I expressed my opinion that I wouldn't take them seriously. Underneath the ridiculous branding they may very well be a great VC firm but the website doesn't sell that to me.

</comment></comment></comment></comment></comment></comment></comment><comment><USER33> "Our goal, as Cthulhu, is to support initiatives designed to rise from the dark depths of R'lyeh (metaphorically speaking!) and end up destroying or at least disrupting, some market paradigm."

Happy to maintain social paradigms though - only one woman on then entire team...

<comment><USER34> "In his house at R'lyeh dead Cthulhu waits dreaming" They do not want him woke

<comment><USER35> Underrated comment.</comment></comment></comment>


Ars Technica editor arrested for soliciting sex with minors - <AUTHOR> https://www.businessinsider.com/peter-bright-charges-attempting-solicit-sex-minors-2019-6 <comment><USER2> Child molester _and_ Microsoft shill, can't get much worse than that.

Edit: It pains me to do so, but I have to flag this story. There is no way I can fit this under 'stimulates intellectual curiosity'.

</comment><comment><USER3> linked from the article: [https://www.docdroid.net/UMNWMSx/bright.pdf](https://www.docdroid.net/UMNWMSx/bright.pdf)

looks pretty damning. All the same, kind of lame to lose your job prior to conviction. I mean, from Ars' perspective, on the moon shot that he gets acquitted, it still looks bad, but for now, we only see an _arrest_ , and only the FBI's side of the story.

</comment><comment><USER4> I wish I could scan these people's heads and discover why they have these desires ... where and how it all went wrong. The individual and societal harm they do to satisfy these personal desires is devastating.</comment>


The PC Industry is Digging Its Own Grave - <AUTHOR> http://www.forbes.com/sites/rogerkay/2013/04/12/the-pc-industry-is-digging-its-own-grave/

<comment><USER2> Let me make it short for you:

      15 * Microsoft
      8 * Intel
      2 * Apple
      1 * Android
      4 * Tablets
      2 * Smartphones
      0 * Linux
      0 * Amd

</comment><comment><USER3> There may be specific players in the PC industry who are "digging their own grave" but the retrenchment of PC sales is the result of the PC overshooting the bounds of its natural market.

Personal Computer means a general-purpose computer you own and control completely. How many PCs are actually deployed that way? The PC market will probably never shrink to include only the people who really need a Personal Computer, but it will get much smaller than it is now.</comment>


Universe is most likely to end in ice - <AUTHOR> http://www.nobelprize.org/nobel_prizes/physics/laureates/2011/press.html

<comment><USER2> This refers to a 1998 study that says the universe is accelerating. I thought since then there had been news of dark matter being more than what we had thought of, which would exceed critical mass resulting in the universe coalescing again ???

p.s. I hope there'll be some whiskey to go with it :)</comment>


Petition: Public Money Should Produce Public Code - <AUTHOR> https://creativecommons.org/2017/09/18/sign-petition-public-money-produce-public-code/ <comment><USER2> Wholeheartedly agree. There is a big push do this inside the US federal government right now. I work for the United States Digital Service, and at the Department of Veterans' Affairs, almost all application code we write is open source:

[https://github.com/department-of-veterans- affairs](https://github.com/department-of-veterans-affairs)

This push is happening in other agencies as well. Check out [https://code.gov/](https://code.gov/) for other shared projects from agencies around the federal government.

<comment><USER3> How has your experience with the USDS been? From a selfish point of view, it seems like a great way to make contacts in the industry while serving your country.

<comment><USER2> I'm coming up on having been here for two years, and both of those things have been true. It's been a great experience to work alongside top-notch folks from all over the tech industry on problems that deeply impact so many lives.

It's also the best civics lesson you'll ever have. You get to see up close how the federal government runs, good and bad. There's a lot of nuance on how policy, legislation, and technology all interact that I didn't appreciate before I worked for the USDS.

<comment><USER4> >>There's a lot of nuance on how policy, legislation, and technology all interact that I didn't appreciate before I worked for the USDS.

Would you mind sharing some of your insights?

</comment></comment></comment></comment><comment><USER5> I've seen quite some code which was paid for by public money. If this would actually happen it would mostly just expose a tremendous shitheap of "enterprise" code created by consulting firms whose entire business model is based on delivering and "maintaining" overengineered crap with huge maintenance costs.

<comment><USER6> > If this would actually happen it would mostly just expose a tremendous > shitheap of "enterprise" code created by consulting firms whose entire > business model is based on delivering and "maintaining" overengineered crap > with huge maintenance costs.

But that's a good thing to expose too. Might even provide a deterrent to those that are in the habit of producing bad and over-engineered work as it'll be public and potentially affect their reputation. And even then, we can probably still use that code and learn from it. Just because bad code is written with public money doesn't mean it should be kept private.

<comment><USER5> Agreed, however I think it is unavoidable simply because demand for cheap code is many times higher than demand for good code. And even if it was the other way around, I don't think the market would be able to provide it.

</comment></comment></comment><comment><USER7> I hope this campaign gets some traction. Closed source is wasteful, and even more so to fund it with public money.

Software development today is quite inefficient. It mainly suffers from two problems: duplicated effort, when a solution already exists, but it is inaccessible, and misdirected effort, when a problem is solved in a way that doesn't facilitate preparing other, possibly hardly-related, solutions in the future.

The cause of duplicated effort is that closed source carries no social stigma; in other words greed is not penalized. The cause of misdirected effort is lack of understanding of how to ergonomically assemble sub-systems into systems, which is simple enough and is described in the Unix philosophy [0], but nonetheless is very rare.

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

<comment><USER8> > misdirected effort, when a problem is solved in a way that doesn't > facilitate preparing other, possibly hardly-related, solutions in the future

Would you be able to clarify what you mean by this? In my experience, trying to write all-encompassing software quickly leads to issues with actually ever getting anything out the door in a working state - better to solve your particular problem and generalise later as needed.

<comment><USER9> In my experience misdirected effort comes more from a lack of planning or full-fat spec being produced before the work begins rather than an attempt to cram in every feature under the sun.

Instead of knowing exactly what features to put in you get a request along the line of "We need something that does x" and no time to plan how to do x, so you end up with something that does it then the feature creep starts, making the original x look like a code version of Seth Brundle after his teleportation mishap in The Fly.

The age old "Weeks of programming can save hours of planning"

<comment><USER8> Totally agree. A few pages of good spec / design docs can save so much wasted effort. Indeed I'd struggle to think of many non-trivial past projects where committing the design to paper hasn't revealed some hidden flaw that would've bitten hard later on.

> Seth Brundle after his teleportation mishap in The Fly

For anyone who didn't get this reference like me ... [http://i43.tinypic.com/2ngr969.jpg](http://i43.tinypic.com/2ngr969.jpg)

</comment></comment></comment></comment><comment><USER10> The intent is good and I hope we find a good way to implement this.

I do see pitfalls though: I would separate ownership (i.e., one cannot patent the code developed with public money -- IMO a good idea) and visibility (showing the code on request -- IMO a very dangerous one).

My big concern is formalizing things that should be left informal. For example, in applied research, we usually build a number of throwaway prototypes before the real system. Those quick prototypes and proofs of concept are often ugly in many ways. If I have to expose those to the world I have to smooth sharp edges (HR -- "we cannot get _this_ outside"), which means instead of building 10 throwaways I can only build 2-3.

<comment><USER11> > in applied research, we usually build a number of throwaway prototypes > before the real system. Those quick prototypes and proofs of concept are > often ugly in many ways.

So basically you just do normal development? In the commercial world, one of those prototypes usually becomes the production code.

<comment><USER10> Yes; but I am just saying that putting a bright spotlight on intermediate steps might stifle quick prototyping.

<comment><USER12> i don't think public code means community driven, or public development.

Just uploading a zip of the final source code is enough to count as public code imho.

</comment></comment></comment></comment><comment><USER13> This would specially be interesting to enable easy external auditing. Specially since governments rely a lot in large consulting companies, and these often deliver software of questionable quality. Also easier to evaluate would be the high costs usually associated with contracts to develop software sponsored by tax money.

<comment><USER14> Also those who review the open sourced code could find themselves getting job offers potentially, or find it easier to apply for jobs with those systems. The only exception I see to the whole "Public Money should produce Public Code" is in the defense sector depending on the project components. We wouldn't want to share code that is used in war with the entire world I don't think?

</comment></comment><comment><USER15> I'd love to see this be adopted in the US, but I'm not holding my breath.

There's an example of this in my field that upsets me quite a bit. A set of tools were developed using public funds through federal research grants and other similar mechanisms, with the express purpose of making free alternatives to private tools available. After the project was successfully completed, the leaders of the project decided to start charging hundreds of dollars for "maintenance" of the toolset, which would only run on Apple devices no less. (For some tools, the cost is substantially less than private alternatives; for others it's more expensive or about the same.)

My concern about this isn't so much that they started charging money to maintain the project per se, after federal grants ran dry. My concern is that the product development costs were already paid for using taxpayer dollars, and that if it were open-sourced, it would be almost as usable, if not more usable (if it were ported to other non-Apple platforms), and free.

The other area of this that I find upsetting are these "small business grants" that basically use taxpayer funds for VC software development, with no public return. Government pays for software development, and then the developer gets to charge for it later.

<comment><USER16> The public return comes in the form of the company that receives the grant paying federal income taxes on their profits.

Commercial profitability is usually a desired goal for these business grants, _because_ the government wants their money back (via taxes).

</comment></comment><comment><USER17> Unfortunately this doesn't work in public education where it is most needed. All the companies pushing content to the kids, e.g. i-ready, st-math, while they may be "non-profit" do not share their code or source materials. What's worse is often their licenses only last for 1 year and have to be renewed again.

</comment><comment><USER18> Example: Public of Andorra gives money to Andorra Programmers to make some cool program that all people need.

Why US Public is allowed to use that code? Andorra's budget is not that big so why people of Andorra should pay for people in States? That's a very good way to not produce Public Code at all.

<comment><USER19> There are other benefits, like US public submitting bug fixes, Andorra's code becoming a de-facto standard making it easier for them to hire contractors and support, and the fact that Andorra can use lots of open source from the US already. It's not a zero sum game.

</comment></comment><comment><USER20> One counter argument: national taxes shouldn't be used to produce code that could benefit other countries, unless that is recognised as a kind of international aid.

(Not my opinion, but one I can imagine from certain political quarters)

<comment><USER21> Has anyone ever made the argument that NASA images are international aid, because they help astronomers in other countries?

<comment><USER22> Well what matters is whether it is, or can even be, a convincing argument. Just saying things doesn't make them true.

<comment><USER23> it makes them true for some people

</comment></comment></comment></comment><comment><USER24> The obvious problem with proprietary code is the questionable quality of consulting companies, etc., but I think the biggest advantage to free software is _interoperability_.

Right now, there are thousands of _data entry_ jobs, whose sole purpose is to translate data from one system to another, often _within the same organization_.

A friend of mine who has recently learned simple Visual Basic has told me about what he calls "huge" savings simply from writing scripts to copy and transform data rather than pay people to read and type it.

</comment><comment><USER25> Much of gov.uk is open source [https://www.gov.uk/service-manual/service- standard/make-all-...](https://www.gov.uk/service-manual/service- standard/make-all-new-source-code-open)

<comment><USER26> It's unfortunate that large public sector orgs in the UK are going more in for AWS and their proprietry pieces such as DynamoDB though. Also more crazy when they (AWS) pay very little corporation tax and one of the orgs is in charge of collecting tax </rant>

</comment></comment><comment><USER27> At the US federal level this already occurs. Any code written by government employees exclusively gets released to the public. Just the other day I came across the NIST biometrics matching stuff which was made open for exactly this reason.

</comment><comment><USER28> Shouldn't then transportation funded with public money be freely accessible? What about public parks that now we have to pay for to get in?

</comment><comment><USER29> I like how this video also calls for open architectural plans, aka the source code of our buildings.</comment>


I created the exact same app in React and Vue - <AUTHOR> https://medium.com/javascript-in-plain-english/i-created-the-exact-same-app-in-react-and-vue-here-are-the-differences-e9a1ae8077fd <comment><USER2> As far as I can tell, Vue doesn't introduce anything new over other front end technologies. It's ironic developers who complain about React being the "new hotness" turn to Vue. It's the same core concepts as Backbone, Knockout, Angular, Ember, and the countless private frameworks we've home-grown on top of jQuery in our front end jobs. This is highly stateful, object oriented, mutate-by-defualt, class based, imperative programming, with imperative DOM manual wirings, separate templates from view logic (probably the biggest sin), and programming by non-transferable conventions (v-model="todo", this.$parent.$emit). I don't even want to know the implicit magic that makes list.push() update the view (notice how the author of the article doesn't know either!), but this is again the same as all of the above.

While I don't personally prefer any of the above style, the point is not a criticism, but to point out that fundamentally Vue doesn't seem to offer any different core concepts than other frameworks. I think it just hit a sweet spot timing of being a React competitor, when developers who didn't like (or, I suspect, don't fully understand) React's fundamentally paradigm and convention shift. As a biased pattern match, most times I see people comparing React to Vue, they're new to both, and don't get React.

I'm biased, but I'm biased through experience. Building Backbone apps where you glue events to DOMs written in strings with magic stateful data classes, and then scaling and debugging those apps, _sucked_. We didn't know any better back then, though, because we didn't have React to compare it too.

React can introduce problems (like any framework), but instead of trying to jump through hoops of convention, custom data binding and HTML tags, now my problems are my own. They're problems of composing functions or structuring my data flow. React is so thin that it's rare to have a "React" problem, now I have vanilla "Javascript" or even "function" problems, and it's such a breath of fresh air. Even when I'm debugging performance problems, I don't feel like I'm dealing with React, I'm dealing with comparing Javascript objects.

<comment><USER3> Seeing those quasi-JS expressions in HTML attributes is enough to put me off Vue.

I understand why people feel overwhelmed with the whole React/Redux/Router/Saga stack but you really don't need most of that when you're just getting started and React itself is quite simple and elegant.

<comment><USER4> > Seeing those quasi-JS expressions in HTML attributes is enough to put me off > Vue.

They are supremely useful. Ultimately, it's knowing how to use them to their maximum potential.

I've been coding since '02-ish. When I code with Vue, I have an App Developer mindset, rather than a web developer jQuery mindset.

When I use an attribute, it's just referencing a variable. It reacts to its own state in real-time.

I'm not the best at explaining. But with a legacy mindset, you have to interact with the DOM in some way. Whereas with HTML attributes in Vue, you can use the state in the local component to determine whether something is shown or even if a particular class is shown depending on what the state is of a variable.

Even better, that could be a computed variable or one that's watched. This functionality allows a bit of logic to then be run to determine how that variable behaves. This alone minimises the code I need to write in terms of legacy applications. Which also leads to less bugs.

Using if, for, show, and binding classes are very very powerful. I rarely interact with the DOM now and everything in state that is complex is an array. I can write way more complex apps with Vue, than I ever could with jQuery.

About the examples given here by the developer. You can still see that he's coding with a legacy mindset and that he hasn't internalised a lot of what Vue offers.

Some minor nitpicks:

\- No need for this.$parent.$emit. There is a better way to use $emit.

\- this.$on. <\- What is this? An Event Bus? This should really have been a method.

\- No need to use id attributes at all.

\- Why not pass in the index attribute (which he is not using) to the delete function and then he can simply splice the array?

If he wanted to be real flash. He could have written the ToDo component as a JSX render function and taken the array from the parent and looped out the list. I know the Vue community looks down on it, but would have been a better way of going.

I don't really want to seem like I'm crapping over this. I'm not. I've only been using Vue since April myself. But there seems to be a lot of mistakes here and it's just not idiomatic.

<comment><USER5> > > Seeing those quasi-JS expressions in HTML attributes is enough to put me > off Vue.

> They are supremely useful. Ultimately, it's knowing how to use them to their > maximum potential.

Supremely useful for a typical full stack developer -- yes. Supremely useful for a dev team with members who specialize in web design (plain HTML, CSS, etc) -- not necessarily.

When your source code mixes a bunch of different web technologies it limits the types of developers who can effectively work on it.

Many commenters here regard React and Vue as "easy", but for many designers it's not easy. There are plenty of talented web designers who are just not interested or not capable of working efficiently with React/Vue.

Our company built an in-house JS component framework that is heavily inspired by React and Vue but that doesn't suffer from the intertwining of disparate web technologies. HTML, CSS and JavaScript stay separate from one another. As a result, our designers can independently iterate on UI without needing to touch a bit of JavaScript or quasi-JavaScript constructs.

<comment><USER6> Coupling the CSS and JS and HTML isn't a random design choice. It came out of some very useful styleguides for AngularJS (and other guides too, I'm sure). These guidelines suggest grouping the CSS and HTML and JS together when they are related. It makes a lot of sense in larger applications, but maybe not so much for server-rendered static pages.

There are global styles, and there are styles that are relevant only to a particular component. Hoist styles up to a global (or more general) layer whenever you can, but I really appreciate the fact that I know the important styles I need will be in the same file/folder.

<comment><USER5> > These guidelines suggest grouping the CSS and HTML and JS together when they > are related. It makes a lot of sense in larger applications.

I absolutely agree with you on that.

It's important to point out that grouping and intertwining are two very different things. If you are building a large client-side rendered JavaScript web app, then it is very beneficial to group together the JS, HTML and CSS for a particular component. That's what we do too. However, it is highly debatable whether the JS, HTML, and CSS should be intertwined together (i.e., literally mixed within the same lines) and controlled using framework-specific quasi-JS syntax. As I mentioned above, when you do the latter, you will unquestionably limit the types of developers who are able to work effectively with the code base.

If your team is comprised of a bunch of full stack developers, then you won't face much limitation. But if you're like us and your dev teams include web designers who are JS 'lightweights', then it's a problem.

Reading your other comment from above:

> I hate seeing code syntax mixed with markup syntax. You can end up with hard > to parse views (reminds me of PHP and Rails), and abstracts the final HTML > structure from the developer.

You hit the nail on the head -- I couldn't agree more.

</comment></comment></comment></comment></comment></comment><comment><USER7> > I decided to try and build a fairly standard To Do App that allows a user to > add and delete items from the list.

Isn't it enough of such really? These (micro)apps which are actually single extracted screens of anything seriously larger can't help to decide about a stack.

What about other aspects of real apps: user auth, undo, back-button action, rich forms, client-side error logging, permalinks, rendering/filtering user markup, uploading/attaching content, drag&drop, notifications, SEO, integration with other useful libs (e.g. bootstrap, highcharts, d3), app extensibility with customer views/plugins?

<comment><USER8> I am not sure having all of that together in one demo would help or just be to much noise. It might be better to pull each feature in to its own isolated demo. That you can see how they are differ.

<comment><USER7> Right, but real apps are such glued "noise". For isolated demos we already have countless todoapps on GH and snippets on StackOverflow or some JS Fiddles.

Then when it comes to integration of a front-end framework in a real app with non trivial but common use case the one has to compare and learn the hard way by scouring forums or diving deep down into source.

E.g. dynamic templates are discouraged in Vue, but customers would like to have a control over couple of loadable HTMLs without npm work - think of most CMS stuff.

My point is that I came to this article with true intrest that the author made a real non-trivial application comparison, thus we could learn subtle gotchas and battlefield tactics. But then I got letdown it's another todoapp to compare basic syntax.

<comment><USER9> I've thought for a while that this would be an awesome community project for people to work on together. Pick a project and create it using a few different technologies. It would also help to demonstrate the best way of doing things in each framework because everyone would be competing to make their framework appear to be the most compelling choice.

<comment><USER10> Somebody else agrees with you..

[https://github.com/gothinkster/realworld](https://github.com/gothinkster/realworld)

<comment><USER9> Woohoooo! That's brilliant. Thanks.

</comment></comment></comment></comment></comment></comment><comment><USER11> Is a todo app really a good way to compare any kind of language or framework?

I work with several large apps, some in Vue and some in React. After the learning curve, they are more or less the same. They solve the same problem, more often than not in the same way (or rather using the same concepts). I don't think either is better or worse, or introduces significantly more or less code.

The one big different I have taken away from my experiences with both is React is more approachable for "developer" types, who are big on unit tests and design patterns. Vue is more approachable for people coming from a design background, partly because of its (not so much once you understand how it works) "magic" two way binding and single file components (which let you write <script> <template> and <style> inside a single file, which is way designers are used to).

If I know the app will have more designers, or less experienced developers, I think Vue is a good choice. If it will be built mostly by more developer types, React seems like a good choice. Once you know one, though, it's very easy to pick the other one up.

</comment><comment><USER12> I find vue to be much more approachable, and easier to teach to people that might just modify components, and they like the standard syntax. If you work in PHP, which I don't anymore, there's pretty decent exposure to vue through laravel, so you can get some halfway decent "full stack" apps done by a person or two on a pretty tight schedule.

I've since went to node on the backend and vue on the front-end, going to work with Nuxt next for a small project to see how I like it. I have exposure to React as well, vue to me makes more sense, I built a pretty large angular 1 app in 2011-2012 that's still running out there, so angular was my first real exposure to this sort of thing. I've had zero interest in angular since then. Vue works well for me, though I could easily hop back into react if necessary.

<comment><USER13> I think React is most approachable to developers with a good grasp of Javascript and the DOM, and Vue (which I admittedly have less experience with) is more approachable to designers or developers with a good grasp of other programming languages/not the DOM.

<comment><USER12> Perhaps. I do trust in the work of the the shadow dom manipulations behind the scenes, they're way smarter and way more interested in that. I work with people that make stuff in squarespace and just do html and css, and vue is a choice just in case they decide they want to come over and try some of the other apps. So approachability to me a feature, I don't want to be the only one that can make a trivial update just because someone goes in, looks at the JSX and nopes right out of there.

</comment></comment></comment><comment><USER14> [http://todomvc.com](http://todomvc.com)

This is exactly what he described not being able to find.

I've seen several different websites collecting these todo app comparisons.

<comment><USER15> I was slightly flabbergasted when he said it was going to be a to-do app for comparison. It's on the third page of Google results for "compare javascript frameworks", but I'm sure it was higher about a year ago when I had that question.

</comment></comment><comment><USER16> I've been struggling with the thought that both react and vue feel wrong when writing. Vue seems quickier but things like emit feel gross. React is kinda fun to write small items but things turn ugly when you start breaking down components into smaller and smaller components.

AngularJS still feels nicer until you get into directives.

I think there is still space for one more framework to rule them all.

<comment><USER17> Thoughts on Mithril?

<comment><USER18> Mithril felt really slow to load for me, using it on a little hobby site and was not impressed with it's page-load performance.

<comment><USER19> I've been working with Mithril for 2 years and never heard anybody say that before. What's the site?

</comment></comment></comment></comment><comment><USER20> As a backend developer that is trying to get into frontend what bothers me the most is that no one knows what is the proper way of doing things in React. There's no golden standard.

Sure, there's opinions, but no standards within the React framework, and that's what keeps bothering me the most. I can't get into react because person x will tell me - "oh you should do x like this instead, because of y' and then I'll read y is heresy. I don't have enough experience or time to vet what's good or bad and I can't make that choice. I also however don't want to refactor every other month because someone suggests the new best practice.

With Vue, at least for myself, things felt more natural and straightforward. Not saying I understand Vue fully either, but, I made a fully working standalone project that complements the business in less than a day. JWT, multiple api calls, toasts, Vuex, components and voala it was done, while for react it took a real front end dev almost an entire week to get something up and running.

At some point it's not about modularity or code perfection, but rather delivering. It was easy for me to get something up and running with Vue, but I was overwhelmed with React. I don't want to spend 3-6 months learning something only to be able to write PR passable code.

<comment><USER21> There's right and wrong ways to do stuff in every other ecosystem too. The difference is some of the wrong ways get baked into 'best practices' and you can't engineer a clean code base even if you want to.

</comment></comment><comment><USER22> That's why the TodoMVC project was created, so we show off how to build the same app in all those methodologies.

<comment><USER23> The difference being that the TodoMVC projects are written by different people, so each one follows the best practices for each framework.

<comment><USER24> Except the author needs to be proficient in both, and this author wrote two anti-patterns in the Vue example.

</comment></comment></comment><comment><USER25> Do note that you can use React with much less boilerplate! The nice thing about React is it's very easy to write abstractions on top of it, since it's just a small JS library. For example, instead of writing value/onChange/setState, you can use valueLink={linkState()}. (Note valueLink and linkState were both formerly shipped with React and since deprecated, but it's easy to write them yourself.)

<comment><USER26> Recently I was looking at my 200Kb app minfied for what was the largest portion of it, and, Lo and behold, react-dom comprised a little under half that size.

Part of this is because React and ReactDOM haven't switched over to ESM (and still use CJS), but calling react small is probably not entirely honest, at least if you use it like most folks do.

<comment><USER27> They meant its API surface, not filesize. React is ridiculously small and simple for what it can do.

<comment><USER25> yes, this is exactly what I meant. Thank you!

</comment></comment></comment></comment><comment><USER28> Thank you for posting my article. It would be awesome to hear all of your thoughts and to applause the article if you liked it :)

<comment><USER29> Just a side note - you don't need the constructor boilerplate to initialize state in React components if you use property initializers (I see you're already doing it for handleInput): [https://babeljs.io/docs/en/babel-plugin- transform-class-prop...](https://babeljs.io/docs/en/babel-plugin-transform- class-properties/)

Additionally, you don't need to .bind on deleteItem since functions initialized as class properties are automatically bound (you should just be able to do deleteItem={() => this.deleteItem(key)}).

Another thing is that there are certain weird things that happen if you use the index as the key for ToDo's render function (consider using the actual item text itself): [https://medium.com/@robinpokorny/index-as-a-key-is-an- anti-p...](https://medium.com/@robinpokorny/index-as-a-key-is-an-anti- pattern-e0349aece318)

Overall, great article! Hope that's not too nitpicky!

<comment><USER30> > you should just be able to do deleteItem={() => this.deleteItem(key)}

Don't do this. Arrow functions (and bind) are reallocated on every render, so this can result in a lot of useless re-renders.

<comment><USER29> I think you meant allocations instead of rerenders - if you wanted to reduce rerenders, switching to PureComponent would be the way to go. IMO, what you're suggesting is a premature optimization.

<comment><USER31> An arrow function as a prop is a new function instance on every render causing child components that extend _React.PureComponent_ to render even if no other property has changed.

I consider this a code smell (b/c we had huge problems with it) and I usually give the advice to do it differently. There are exceptions, of course.

<comment><USER29> Fair enough. In this case, I guess it's a tradeoff between code organization (should the child component be concerned with its position in the parent) versus avoiding rerenders.

<comment><USER32> I don't think it's a concerns issue. You can simply decide to never create functions in any render(). There's even an eslint rule for it.

<comment><USER29> The rationale behind that is avoiding re-renders, which can (but doesn't always) improve performance (shouldComponentUpdate can be slower than simply always re-rendering, per a React core developer): [https://news.ycombinator.com/item?id=14418576](https://news.ycombinator.com/item?id=14418576)

If you're concerned about allocation, here's what the same core developer has to say about inline functions in render(): [https://twitter.com/sophiebits/status/938075351414063104?lan...](https://twitter.com/sophiebits/status/938075351414063104?lang=en)

Also see the article that acemarke linked above.

This is a textbook case of premature optimization. Why make your code harder to read just to achieve some performance gains that likely aren't even noticeable?

Lastly, regarding the ESLint rule, sophiebits put it better than I can:

 _I don't recall ever having seen a credible-looking study about this, including in 2015._

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER33> While I understand why we don't really see them, I would love to see a much more involved comparison. A reasonably sized app would probably use redux/vuex, routers, async, etc. which changes things dramatically. Even just adding the state managers changes things completely. Then you have things like cost to maintain/upgrade.

</comment><comment><USER34> I don't really like that we're trying to draw comparisons based on a toy app. The things which really tell you how good or bad something is comes when you start reaching the edge cases, which in complex applications is practically guaranteed. This makes the simple app for comparison a trap, a poor heuristic. The problem is, hobbyists don't have the time to try something deeper, time is simply too valuable to explicity replicate work. An organisation would have to commit to this.

</comment><comment><USER35> This is great. It's an excellent idea for Rosetta Stone(s) for different JS frameworks - all side by side with minimal but working code. This could be a start.

<comment><USER36> [http://todomvc.com](http://todomvc.com)

<comment><USER37> Thanks for the link! I just played around with the React and Vue.js implementations. With the Vue.js implementation, there is a perceptible lag (maybe ~300ms) between pressing Enter and the new item appearing in the list. With the React version, the same action is essentially instantaneous. Curious if anyone else is experiencing the same and/or knows what might be the cause.

<comment><USER38> The Vue one creates new items on keyup while the React one creates them on keydown.

<comment><USER39> Most of them seem to be on keydown except Vue.

</comment></comment></comment></comment></comment><comment><USER40> Though the intent is good I'm not a huge fan of posts like these because no developer is equally proficient in two frameworks. One example is going to be more idiomatic, avoid more pitfalls, use better abstractions, etc. Were this a large production scale project it would be even more evident then a vanilla to-do app. I hope nobody sees this and goes "x is better!".

</comment><comment><USER41> However well written the article is for beginners, I'd love to a comparison where more real world concerns are part of the equation: authentication, authorization, internationilzation, API interaction, form validation etc.

</comment><comment><USER42> I've only been coding in React for a year, but this article feels like it is depending on state far more than a production app would. State is definitely a key part of react, but props are more the norm for moving data around. When you do change state, it often just makes an update to one small thing, which then re-renders everything downstream with new props.

<comment><USER43> props is more explicit to control the timing of rendering.

</comment></comment><comment><USER44> The react app looks more complicated and verbose.

<comment><USER45> Funny, I had the opposite impression. Vue outsourcing a lot of custom non-HTML compliant properties into the DOM code made me think it would be a harder job to get rid of it if I decided to switch. React's state updating does look a bit more circular, but at least it stays within the file.

</comment></comment><comment><USER46> >If you're not already aware, a CLI (short for Command Line Interface) is basically a thing that you can install via npm that allows you to terminal/command line commands that will quickly build a general Vue/React file structure for you

No, not really... Good work for doing this comparison though.

</comment><comment><USER47> As a backend dev (though I've been slinging jquery for years and do know enough javascript to dislike it), I've finally convinced my boss to let me write a small front-end app that's due in about a month.

It seems like most of the various teams are using React, but I've heard Vue is easier to pick up. Since I've only got a month, can someone with experience in both weigh in?

If all else fails, I wrote a small AngularJS app about 2 years ago, and will just reuse its base if both React and Vue seem too complex to pick up in a few weeks. The app I need is just a simple crud / tree app to add users to a hierarchy of groups.

<comment><USER48> If you're familiar with AngularJS, Vue would be easier and faster to pick up.

<comment><USER49> I second this. Vue is more declarative to me. Which I appreciate.

</comment></comment></comment><comment><USER50> Everytime a todo-list. Can we try implementing more reactive applications? Perhaps a tic-tac-toe game would provide more insight and understanding on the underlying powers of the frameworks.

</comment><comment><USER51> I just learned Vue.js and it seems he made it harder than it needs to be. Is he using Vue.js version 1? (I didn't recognize some of the paterns he was using from the documentation..._)

Also, from the comments it seems like React has "don't do it this way or you get an error" or "people get caught with this because they didn't know the side effect of xyz..."

Vue.js had almost not surprises once I learned how the system worked, maybe I am not deep enough into it yet, and it has similar gotchas as React?

</comment><comment><USER52> having just had to remove jquery from an angular application because it was flagged by static analysis i can say i do not want any frameworks. i just want to make them go away.

it is just extra stuff to learn to debug. the angular part fails even after i think i removed the jquery code. it fails silently, so i do not know where it fails. maybe i missed something. im just a stupid webdev who also works with ten other frameworks on our ten other applications we maintain for this client. but maybe angular/react/etc is just added complexity that was unnecessary in the first place for a simple crud app. framework code also uses arcane language constructs that further obscures things and there are quite a few of those tricks in JS. not to mention that you only use a few bits of it, but all the code is there for you to sift through when it breaks.

then corporate will likely decide they want Polymer and we have to learn to debug Polymer. then polymer fails the static analysis or the pentest and polymer needs to be fixed/thrown away.

frameworks are just parts that can go wrong. yes react can be pretty cool but it also introduces complications. unnecessary complications. unless there is a very good reason to have a framework and there will never be a reason to migrate and you never have to deal with higher-ups, i'd recommend sticking with vanilla javascript.

it is quite powerful these days. maybe include some small library to organise things. jquery was allright in the day, although i would not use it these days anymore because most of the stuff it did can be done easily in plain JS now.

there is something called the KISS principle. it deserves more credit than its getting.

<comment><USER53> I used to think vanilla JavaScript was the way to go, but then I rewrote a vanilla JavaScript SPA with a framework (Vue) and realized how many times I didn't have had to type element.querySelectorAll('x')||[] and element.addEventListener / removeEventListener anymore. Vanilla is good sometimes but it gets tedious on bigger stuff.

<comment><USER52> I don't mind writing stuff i know and understand. although if you are a framework expert and/or the framework code is very minimal (which is somehow never the case), i can understand choosing to remove the drudgery.

</comment></comment></comment><comment><USER54> I did similar to choose between the Big 3 frameworks, and I chose Vue. Was thinking about polishing the code to make the test "publishable".

</comment><comment><USER55> React reminds me of the good ol' PHP days. The days where it used to be an all out freedom of expression (pure hacking) doing whatever you want whenever you want. Sure code can get ugly as sin, but it does leave you with a liberating feeling.

It wasn't long ago where separating content from presentation was actually a thing. Now we are going the other way around and quite honestly, I like it.

<comment><USER56> Give me some code snippets that are ugly as sin ... seriously, Please!

</comment></comment><comment><USER57> I love react, I think it's extremely elegant and easy. It's a glimmer of sanity in the insanity that is javascript. I came from a non js programming background and just couldn't deal with the mess of a language that js was/is (especially pre ES6). Without React I would've never gotten interested in front-end development.

</comment><comment><USER58> I can't imagine writing a real-world Vue app without Vuex. As such, I can't help feeling like this article, despite the best of intentions, is probably misrepresenting things. The last several Vue apps I've written have not used `emit`; not one single time. (context: `emit` is shown/used in this article)

<comment><USER59> Well, not even Vuex is needed for that matter. It's funny that the author goes out of their way to comment on how you can mutate state directly in Vue, then doesn't take advantage of that.

Both components can share a single "plain old javascript" model object, which they just both freely update. The TodoListItem doesn't need to notify its parent of anything. In a small scale app, it's fine.

</comment></comment><comment><USER60> did the same for a take-home coding assignment. once i did one, it was pretty trivial to convert it over to the other. you can check out here:

[https://github.com/tmm-archive/front-end-code-test](https://github.com/tmm- archive/front-end-code-test)

</comment><comment><AUTHOR> A todo is a little too little to do. How about pair programming between to coders adept in two stacks?

For that matter, how about in Android and iOS?

</comment><comment> crooked-v The React example seems like it should really be using Emotion or a similar library to make the separate CSS files go away. While it is bringing an extra library into things, there's several that have an identical basic API, so it's a fairly generic approach for React apps now.

<comment><USER61> styled-components[0] or death.

0: [https://www.styled-components.com/](https://www.styled-components.com/)

<comment> crooked-v Why that particular one?

<comment><USER61> * CSS-in-JS

* Written as actual CSS

* Styles that are easily extended / composable

Would be my main reasons for liking it.

<comment> crooked-v You don't seem to have looked at Emotion, because the most basic parts of it are clones of those parts from styled-components functionality, with variance once you get into the extended API.

<comment><USER61> I haven't. Not really sure why that matters though? I was highlighting styled- components as a much better way of handling styling in React compared to inline JSX styles or CSS files.

<comment><USER62> It matters because you replied to a comment about Emotion saying "styled- components or death".

If you wanted to compare it to something other than what the parent comment was talking about, maybe you should have made your own comment thread, or been more clear, or something.

<comment><USER61> You're very right. I somehow missed the reference to Emotion in the OP.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER63> stevebmark's comment got me thinking about UI technology in general and computer science.

The thing about UI ... it's just, plain, _hard_.

There's not much more to it then that. "UI is hard". User interfaces, no matter if they're text based or graphical, are perhaps the most frustrating field of computer science. They look simple. "Oh, this is just a bunch of boxes and text. I can bang that out in an hour!" _three weeks later_. Sound familiar? It's that illusion of simplicity that drives programmers crazy. UI has, as far as I can tell, the highest ratio of perceived simplicity to actual difficulty of any other computer science field.

So here we are. We have several decades worth of computer science under our collective belts. Over the plethora of decades that our field has existed we've: invented the transistor, made it the size of a handful of atoms, flew to the moon and back, beat humans at chess and Go, can make video calls half way around the planet, and have crammed unthinkable amounts of technology into our pockets in the form of smart phones. My house bends to my very _voice_ thanks to modern computer science.

But in all that time ... UI is still hard.

I don't think a lot of programmers stop to think about that. Maybe, just maybe, all this thrashing about with UI libraries has more to do with the fact that UI, as a computer science problem, is perhaps one of the most complicated, impenetrable problems we've come across. The perceived simplicity of the problem so often blinds us to that fact.

I believe it stems from a shared "ancestor" with multi-threading: concurrency. Every programmer knows and fears the problem of multi-threading, but they don't fear UI in the same way. Yet, these two problems are more alike than not. A UI is a system that is filled with concurrent, unpredictable, events and threads that could happen in any order. That's a multi-threaded system.

So it's no surprise when viewed like this that UI is hard. It's very difficult for us to reason about a multi-threaded system. Even the best engineers in the world make "obvious" (in hindsight) mistakes when they build concurrent systems. Look at all the bugs that pop up when researchers attempt to do formal verification of concurrent primitives implementations.

So if it's impossible for us to reason about UI, as a concurrent system, then what do we do?

My time spent with Rust, the programming language, has given me some theories. Rust is most popularly known for its memory safety, but its true power lies in its type system. Rust is the first language I've encountered to expose to the user an advanced type system in a practical way. Languages like Haskell et al have of course had these advanced type systems for _decades_. But Rust offers them in a way that is digestible and ergonomic. For us common folk at least. It's perhaps the first chance that we as an industry will have at a widely used programming language with advanced typing and static analysis.

That advanced typing system is what gives Rust its true power. Most salient to this discussion is its usage of the traits Send and Sync. These two traits allow us to communicate to other engineers and the compiler that "this type is safe in these concurrent scenarios." Suddenly the frightening world of concurrency blows apart. Instead of being afraid, you can be fearless. Write whatever code you want and then the compiler will check it and prove (in a limited sense) that your program is correct and safe.

It's an incredible shift for programmers to have this power. Send and Sync are a small step in a new direction: being able to leverage static analysis by the compiler to assist programmers in designing their systems. Before, in e.g. C, it was up to the programmer to think about all the state of their program in their head. At best we suck at that, especially in complex scenarios like concurrent systems (and UI!).

Now we have tools that can augment our mental facilities. In the same way you don't have to think as hard about memory in Rust as you do in its ancestors, you don't have to think as hard about concurrent systems because the compiler and the libraries and types we build alleviate the number of problems we need to think about.

I believe that it's possible this road that is leading to a brighter story for concurrent programming is also leading to a brighter story for UI. Rather then having to think about _all_ the states that a UI and its backing state machines can be in, we instead build type systems that allow us to describe how we believe the system should look in our heads. And then the compiler will do the dirty work of proving our assumptions correct. Our compilers will be 1000x better then us at considering an exponential number of states that a UI could be in given its concurrent and unpredictable nature.

So just imagine a UI framework built on top of an advanced typing system. We could do insane things like using the typing system to say that certain View elements should only be visible given certain states in our model. For example, the Logout view should never be visible when the user isn't in the LoggedIn state. And the advanced typing system, combined with the compiler's static analysis, checks all of our state machines to prove that Logout will never be visible unless the LoggedIn state is active.

It's crazy, right? But I think it's possible. Just like Rust's lifetime analysis can prove when certain objects will be alive so that the borrow checker can check all your references are alive and safe. I don't think it's so crazy to imagine a future where the compiler can determine the lifetimes of a View and make sure they aren't referenced in certain states.

Anyway, the most important thing I wanted to communicate is that UI is hard. Really hard. And we shouldn't forget that. We should approach UI with the same caution and respect that we do multi-threaded programming. Perhaps with that mindset less programmers will fall into the trap of frustration. That trap that has led so many to believe that it is our libraries and frameworks that are broken, and to go off and build yet-another-framework in the vain attempt to "solve" UI without making any real attempts to innovate on the core computer science problem that is UI.

P.S. I'm not terribly good at communicating the strength of Rust's type system and underlying compiler. There's just something magical about Rust that makes it easy to write an API where A) it's obvious to users how to use it, and B) it's a compiler error to use it wrong. It's not any one thing and it's easy to compare Rust to other languages. So I'm not people will reply with "but language X has feature Y just like Rust; how dare you argue that Rust is some kind of revolution!" Oh well.

I'm also sure some will come along and take issue with my assertion that Rust makes memory management easier. Rust makes memory management easier only if you take the time to consider the full story. That is to say, it's quite easy to manage memory efficiently in, say, C. But to do it _without_ bugs? It takes _decades_ to write a C program with no memory bugs. Yet I can write the same program in Rust and the compiler will _ensure_ memory is managed correctly. (Within certain limits, it's possible to leak memory, etc, etc.)

<comment><USER64> There are ways to use state machines in web development [0]. Couple that with TypeScript and you maybe get something like that.

[0] [https://hackernoon.com/upgrade-your-react-ui-with-state- mach...](https://hackernoon.com/upgrade-your-react-ui-with-state- machines-30d1298e90be)

</comment></comment><comment><USER65> Am I the only one who recoils in horror reading this and hopes for the day when WebAssembly gets DOM support so we can put this language where it belongs -- the trashbin of history?

Obligatory [https://softwareengineering.stackexchange.com/a/221658/13510](https://softwareengineering.stackexchange.com/a/221658/13510)

<comment><USER66> I'm not particularly looking forward to that. There is an advantage of having the entire web in a single language, I mean, I still think SPAs are kind of stupid in concept, but we write them because the toolset for them is so good.

Do you really think there will be equal tool sets available for you in your favorite language when webassembly eventually makes it to the browser?

I'd say we're a good 20 years from it having any form of productivity, and from a human resource point of view, you won't see companies replacing staff over it, so JS is still the future.

I don't really understand the hate js gets though. Sure recursion is ridiculously slow, it's a little verbose, and you certainly need your team to agree on some standards (or you can decide for them), but I actually think it's kind of decent, once you get to know it.</comment></comment>