2016 will be the year of concurrency on the web | Hacker News Reader

2016 will be the year of concurrency on the web

medium.com

66 pointscramforce34 comments

I honestly really hate it when "concurrency is hard" is trotted out as a reason for not using it when using it would very obviously make life better for the end-user.

Is it as straightforward as non-concurrent code? No, obviously it isn't. Is it so mind-bendingly difficult that we need to be paralyzed by fear at the mere mention of concurrency? No, it isn't that either.

There are things you can do to make concurrency easier. Dispatch queues for one eliminate a lot of bugs. Being thoughtful about when and how we use concurrency is another. Race condition bugs are sometimes difficult to track down and cure, but if you understand the basic concepts around concurrency and controls around that they're generally fairly easy to avoid.

The biggest problem I've run into with people is they don't even understand what mutexes, semaphores, condition variables, or atomic variables are or when you'd use each. People don't know what joining a thread is. I ran into a bug at a previous job where they were spawning and destroying threads very quickly (which is a problem, but not their main problem) and instead of using a join to block until a thread's completion they were using sleep(1). Switching to a join sped up their code immensely and improved a data processing operation that previously took months to now taking days.

tl;dr people need to a) read up on how to do concurrency and b) be more thoughtful about the code they're writing when doing it. It's not so scary we should just avoid it altogether, especially when the user experience can be greatly improved by using it. Concurrency is another tool in the toolbag, even if it's a chainsaw without a cover.

It seems to me you don't have a good understanding of the amount and kind of people doing web development.

Either that or your comment is not in regard to web development at all?

I'm not really involved in web development much, my comment was more general though. It's surprising the number of people in an environment where threading is a real option that don't really understand it very well.

Is there not a wide range of web developer talent available in the marketplace?

Certainly some teams are more sophisticated than others and can achieve a higher level of site design.

Concurrency is even easier when you use something like Erlang or Elixir, or apply their principles to other languages.

The "web" for a long time was Perl/Python/PHP/Ruby. I had never done real concurrency work until I started doing C#/Java. But most web devs I've worked with, especially the ones with an interpreted language background, have no idea or even interest to do any kind of concurrency. NodeJS isn't making things better either.

AFAIK, the only "easy" and pleasant language to do concurrency in is Go and maybe Clojure if you can get past the LISP. C# is nice but is (for now) still too MS-centric, and Java is ...well...Java.

Until we move away from the intercepted languages and frameworks of the 1990's, this won't get any better anytime soon.

> AFAIK, the only "easy" and pleasant language to do concurrency in is Go and maybe Clojure if you can get past the LISP.

Have you looked into Elixir? It's a language that compiles to Erlang's VM and thus has the same concurrency model as Erlang's, which is one of the simplest ones.

Pulsar is also a great Actor Model Concurrency library for Python. It gives you Erlang/Elixir style actor concurrency in Python!

> a) read up on how to do concurrency

Can you suggest a few resources to further this cause? I'd love to write more concurrent code but outside of an OS class, I don't have much experience.

Thanks!

You could probably read this decade old book:

http://www.amazon.com/Java-Concurrency-Practice-Brian-Goetz/...

and it'd be a good start. It's in "boring" old Java, but it goes over a lot of the meat and potatoes concepts.

I can recommend this book as well. I don't write a lot of Java, but this is great for the general topic.

Go write a producer-consumer queue

Also understand this code: http://en.cppreference.com/w/cpp/thread/condition_variable

I just hope, that all the javascript anywhere!, everywhere! will stop. Otherwise, I think I will move away from programming. Not a rust, but, boy I do dislike javascript!

So don't use it

I have to use it. There no other way. Please don't tell me coffee script/typescript, future script. Also, I feel tired, fatigue I will say, every 2 month there a new way of doing stuff. And you know how difficult is to grab a junior and explain that now react is the shit and not more angular?

Also, do you know how difficult is for the company to hire people and we have to tell them: "we are a bored company, we just use jquery, rails and ajax."

I do not have anything with the language. Is becoming better, but I really hate the noise, the billions of libraries, and every two month the `correct way of doing stuff`

end of rant :)

Tons of software is not web software and does not use JavaScript. You can be happily employed as a programmer and never touch JS.

I have to add this:

As a Junior developer, JavaScript scares the shit out of me. I have been trying to find some basic JavaScript testing framework so we could test if we broke anything when we commit some code changes, and as soon as I tried building PhantomJS/CasperJS (I had to do that on the spare server because compiling them on my machine takes hours), it scared the hell out of me.

Have you looked at Karma?

> Please don't tell me coffee script/typescript, future script.

Why not? You are already doing a build step for Babel mostly likely. Might as well do ClojureScript, which has simple syntax and one tool that does it all.

> This actually happens: You thought it was a cool hack someone wrote a H264 decoder in pure JavaScript? Ads use that to implement auto play video where it would be not allowed by the browser.

See, the problem is just bloat. Things will just get bigger until you push back. If you enable "bigger" with various optimizations (15 analytics trackers are now just as heavy as 1!) then they'll just get even bigger (33000 analytics trackers !?) because that's just what happens in business settings. Things will just get worse until it's a problem again, and then maybe you'll have justification to do something about it. We're always stuck on the edge of "not quite so bad I swear off news and product websites entirely".

I hope that by concurrency, the author also means "shared address space". Because that is what concurrent programs need (especially for the immutable-data structures, that need to be passed cheaply from one thread to another).

I have run into the same "multi-threading is hard" attitude among younger programmers. I believe that kind of attitude to be a career limiting mistake. In the interests of scalability, you may have to accommodate multi-process oriented concurrency anyway with such as techniques as message brokering, or CAS style counters available in various databases; however, it is always going to be cheaper to manage a pool of threads in a single process than to manage a pool of processes. In the data center, most bare metal servers have lots of cores where multi-threading really shines. I have noticed a trend in AWS to offer more single vCPU EC2 instance types for those unwilling to learn the joys of thread pool executors and linked blocking queues.

Trying to make it a native platform rather than it's original intended purpose (document sharing and simple data input/retrieval) is where all the issues arise from.

A pretty good read other than all bullet points. I kind of enjoyed the part where he said the initial solution was to not use any Javascript. I think the simple way to make the web great again, you'd have to just use JS sparingly.

Everyone has their own opinion on the web but I tend to think it shines in simplicity, sites such as HN are a good example of that. Let the browser do what it can and forget the rest.

The rise of web apps and app stores show that distribution is everything.

You can complain that this isn't what a browser is for, but it won't really matter until you can distribute your favorite kind of software in a way that requires (nearly) zero effort and zero risk for your end users to get started with.

An appstore program that costs nothing up front is the same amount of effort as opening a webpage, but with less risk.

Open browser->type in appname->hit enter

Open appstore->type in appname->tap install (with what is likely to be less risk since it's not only sandboxed but also at least Apple's appstore is inspected)

If distribution is king, you're going to get more eyeballs from people browsing in an appstore than sitting out there at www.urlhere.com. Where you'd have to actively advertise in some fashion.

I stand by the viewpoint that all these issues that arise from misusing a tool. And the author isn't too far offbase either. As noted, a 10MB page is ridiculous and it sounds to me that should be in an appstore somewhere. That's just misuse of the platform and far off what was the intended purpose.

On one hand the author thinks 2016 is the year of concurrency on the web, on the other hand half the article explains the problems with concurrency on the web.

I think "X is the year of Y" headlines are wrong about as often as the answer to "Is Z?" headlines is "no".

Unfortunately the proposal doesn't solve one of the main problems with the mobile web: Battery usage. It doesn't matter if you run all that extraneous js on background threads. It still uses power.

It can be an energy win if the background threads allow work to be completed much faster. That's because finishing earlier will allow CPUs to throttle down as soon as the work is done, thus cutting power usage.

Web workers can win you huge performance boosts. In my work we implemented auto-indexing of client-side resources so you can search without lag or hiccups, and we published a library [0] so that others could use it. Pushing stuff as much stuff as you can to web workers is definitely something that needs to get more love.

This isn't a particularly new idea. Here's a short writeup about this in react-future [1]. Roughly one month ago someone published react-worker-dom [2] and wrote a blog post [3] about it.

But this is ultimately just a workaround for terrible DOM APIs. Maybe I've been living under a rock, but I haven't seen any new DOM API proposals to help deal with these problems. The only new DOM API I've heard about is web components, which still runs in the UI thread. Does shadow DOM win us any huge performance boosts?

In the last few weeks I've looked through the source for a lot of elements in the polymer catalogue [4]. This is probably going to come off as a bit rant-y and negative, and it's totally tangential to the topic, but I'm totally unconvinced that web components are the way forward. These APIs are too complicated and they rely on side-effects which are very difficult to trace and debug. It's code that says: Execute this side-effect and I'm going to hope that now my environment is in an expected state. Oh, you screwed up with a typo? Don't worry, I'll just fail silently, good luck debugging me! You import files and then you pray that it polluted your namespace with the correct globals. This is not an acceptable way for building web apps in 2016.

In contrast, I've been using css-modules [5] for the last few months, and although it has its own shortcomings and problems, I love that it makes it makes your usage very explicit and easy to trace. If you look at the css-modules link, you'll see why it's so great: You're explicitly saying you want to pull in that stylesheet and reference that specific class.

The same goes when you're using React: You import a component and you put it in the render function's return value. If you try rendering something invalid, it'll scream as you. You can debug this much more easily because you know the file that was referenced and the specific export that's being used.

[0] https://treasure-data.github.io/redux-search/

[1] https://github.com/reactjs/react-future/tree/master/05%20-%2...

[2] https://github.com/web-perf/react-worker-dom

[3] http://blog.nparashuram.com/2015/12/react-web-worker-rendere...

[4] https://elements.polymer-project.org/

[5] https://github.com/css-modules/css-modules#css-modules

Reply on news.ycombinator.com