

(Web) Development Sucks, and It's Not Getting Any Better - d2p
http://blog.dantup.com/2014/05/web-development-sucks-and-its-not-getting-any-better/

======
sgrove
As someone on a team working very hard on cutting-edge techniques to improve
web development, I disagree entirely. While I complain more than anyone I know
about the underlying infrastructure, it's a salvageable situation.

In fact, because of the lack of standardization on a single toolset or
approach (e.g. Cocoa, WPF, etc.), we're in a position to improve well beyond
the current SoTA. Some examples:

React.js from IG/FB: One of the first opportunities in the browser to treat
rendering as a stateless canvas, freeing us from the complexity of time-
management.

ClojureScript[1] - and more importantly, the immutable data structures from
ClojureScript, let us simplify our UI programs conceptually. And combining it
with React (Om), we can make UI's both _fast_ and _simple_

Datascript & friends: Bringing entire in-memory databases client-side.

All of these, and the wide-open nature of the web as it exists today, means
we're in a position to experiment with radically new ideas and find a much
more efficient way of representing our goals. It's a really exciting time to
be working on this stuff.

Nevertheless, I upvoted because I do believe we're in a plato's-cave situation
with current practices in web-development. There's very little overlap between
the desktop and web world, so many of the lessons haven't carried over - how
to manage complexity, the important of tooling, etc. But we're making our way,
bit by bit (or more recently, leap upon leap)

[1] I'm admittedly biased as I've put considerable amounts of effort into the
project, and it's not without its warts. GC pressure can sometimes be very
tough, and the tooling needs a lot of work.

~~~
d2p
The fact that we have great web apps shows that things aren't totally broken;
that's not really my suggestion. I just think we need to be thinking forwards
and planning for future web apps. What we have is not going to do us for the
next 5, 10, 20 years :(

~~~
Turing_Machine
I'm not sure why bolting all that stuff on to machine language is conceptually
any better (or any less a "hack") than bolting it on to Javascript.

It's all Turing machines/lambda calculus at the bottom, right?

Javascript is slower, sure, but (with recent developments) not _that_ much
slower.

The porting issues involved with making something work cross-browser are
_much_ less than the porting issues we used to face in making something work
on (e.g.) MS-DOS and Mac. With JS the UI needs tweaking. With MS-DOS and
(classic) Mac OS you had to do a full rewrite from scratch.

Things are arguably getting a lot better.

~~~
thsealienbstrds
I think theres something to be said in favor of it. Not all programming
languages have js execution model. Does js even support true concurrency
already? Not last i checked: there goes a whole class of potentially useful
applications. We really do want support for these things. It is good for
creativity, therefore innovation, because we have more tools to work with.

~~~
Turing_Machine
What do you mean by "true" concurrency?

I _think_ web workers will use multiple cores, if you have them, but don't
quote me on that.

~~~
thsealienbstrds
True in the sense of multiple cores, instead of just asynchronous execution on
a single thread. Anyhow, it was just an example... What I'm trying to say is
that we want to really explore the capabilities of the web as a platform for
computing, as much as possible. Therefore we need as much flexibility,
tooling, languages, you name it, as possible. I'm actually suggesting the
'C++' way of creating a platform... i.e. stuff it with as much flexibility as
you possibly (reasonably) can and then let natural selection do its work.
JavaScript ain't it.

~~~
Turing_Machine
C++ can be compiled to Javascript that runs at reasonable speeds (not just toy
applications, either). See:

[https://github.com/kripken/emscripten/wiki](https://github.com/kripken/emscripten/wiki)

And yep, I was right. Web workers do make use of multiple cores, and there's
at least one parallel programming library that takes advantage of it:

[http://adambom.github.io/parallel.js/](http://adambom.github.io/parallel.js/)

~~~
thsealienbstrds
I ran the Quake 3 demo. It was frameskipping all over. Performance was not
acceptable for even playing. I think 10-15 fps. No, its not my laptop. My
laptop has no problems with real Quake 3. I want to ask you to take a step
back and look at it purely from a black box perspective. Forget about
JavaScript for a moment. Is it really your opinion this is reasonable
performance?

~~~
Turing_Machine
For playing Quake? Maybe not.

For running any application that spends 99% of its time waiting for the user
to press a key (which is most of them)? Sure. No problem at all.

~~~
thsealienbstrds
And maybe that is todays reality because JavaScript cant really do anything
else. Give a kid a hammer and all problems become nails.

------
azakai
> Tools That Convert to JavaScript are a HACK [..] they’re usually full of
> edge cases, varying browser support, inconsistent performance and other
> strangeness.

The second part is true of _any_ platform that has multiple independent
implementations, it isn't because compiling to JS is a hack (which it is; but
that's irrelevant here). If everyone used the same browser with the same
rendering engine and the same JS engine, we wouldn't have browser support
issues, inconsistent performance, etc.

It's not just compiled-to-JS languages that have browser incompatibilites
etc., it's also HTML and CSS, and non-compiled JS. The issue is the
fundamental tradeoff of the web being a spec that anyone can implement, which
keeps the web open. But it also means multiple implementations with different
performance characteristics and so forth.

The web was never designed to be an ultra-consistent platform that is super-
easy to develop for, which is what the article pines for. If you do want such
a thing, the closest is probably Flash - good developer tools, single
implementation. It was good for some things, but being a single implementation
was one reason why it is losing popularity.

With all that said, the web is actually gaining powerful low-level
capabilities these days. So you could build something more consistent on top
of those. Specifically, you could render UIs using pure WebGL and avoid much
of the overhead of the DOM and JS. And compile-to-JS languages can give you
more predictable performance than JS itself, because they can emit simpler
code (e.g., no garbage collection necessary). There is a big opportunity to
create a tool using those two which would give a much better developer
experience than the web currently has.

------
eldelshell
I've been doing this for 15 years and it sucks more and more. Now we have
complex as hell client-side frameworks like Angular. A framework on top of my
framework, great! More and more screen sizes/devices/browsers, but not a
freaking way of handling any of this information because, for some stupid
reason, the User-Agent header is useless. CSS media queries are useless.
JavaScript window.size is useless.

The problem is: HTML is not made for applications, it's made for documents,
linked documents. The day someone put a form in HTML hell broke loose and even
after 20 years, the web is seriously broken and things are just getting worst.
For example, date input fields; supported by Chrome and Safari, but not by
Firefox. You want to localize it? IT SUCKS! I thought Java's Calendar was
crap, but JavaScript's Date is pure mayhem... And I could go on and on about
why HTML/CSS/JS is all a bunch of crap which, instead of evolving, are making
things harder.

And now they want to add Future/Promise to JavaScript... HAHAHAHA!!!

