
2016 will be the year of concurrency on the web - cramforce
https://medium.com/@cramforce/2016-will-be-the-year-of-concurrency-on-the-web-c39b1e99b30f#.htpwozhqv
======
jgh
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.

~~~
sorenbs
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?

~~~
jgh
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.

------
claudiug
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!

~~~
CyberDildonics
So don't use it

~~~
claudiug
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 :)

~~~
r3bl
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.

~~~
bmm6o
Have you looked at Karma?

------
ploxiln
> 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".

------
amelius
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).

------
gengstrand
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.

------
BuckRogers
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.

~~~
jwmerrill
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.

~~~
BuckRogers
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.

------
frozenport
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.

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

------
discreteevent
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.

~~~
ehsanu1
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.

------
TheAceOfHearts
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/](https://treasure-
data.github.io/redux-search/)

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

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

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

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

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

