1. 11

  2. [Comment removed by author]

    1. 8

      “it seems that it’s so difficult to make a web browser that there’s only really 3 or so fully implemented, up to date ones.”

      That’s a simple, great point. Obviously too complicated when it takes massive, development teams by large corporations to build and maintain them. The biggest ones also use codebases that go way back in time.

      1. 10

        Well, there’s also only 3 or so fully usable desktop operating systems. And whatever the web was originally intended to be, it is becoming an operating system.

        1. 4

          But the criterion that prevents a lot of operating systems from being “fully usable” is the lack of a fully functional web browser. Plan 9 for example falls short of being “fully usable” because the task of porting Firefox is too daunting.

          I think OpenBSD faces a similar issue, where today’s web requires HTML5 with hardware acceleration, which is apparently not simple enough for them to write themselves (maybe someone who knows more about this can weight in).

      2. 5

        The software necessary to function in society should be implementable by a handful of programmers. When the complexity of a core technology reaches the point where you need thousands of programmers just to maintain the software and keep up with “progress,” it poses severe threats to freedom and democracy.

        1. 1

          How to factor a full-featured web stack into simple, separate concerns is, itself, a very tough engineering challenge, but I think it’s fundamentally tractable. We would have to re-design the visual and programmatic elements of the modern web on much firmer theoretical foundations. This would mean getting rid of HTML/CSS, getting rid of javascript, etc.

          The JavaScript part we’ve probably figured out. There are all sorts of elegant memory-safe computation systems that can be compiled to efficient machine code. Something like a Spineless Tagless G-machine would probably work great, and be simple enough that many people could write a (slow) interpreter with little effort. Experts could write compilers to fast machine code while maintaining security guarantees by construction.

          The visual/media part I’m not so sure about. We have some clean ways of mixing UIs with code (like query algebras), but none of them stand out to me as particularly simple or elegant, and I can’t think of a graphics format that can do the kind of stuff we expect from HTML yet is theoretically sound. Such things may exist, but I’m unaware of them.

          1. 2

            We have some clean ways of mixing UIs with code (like query algebras)…

            What do you mean by that?

            1. 1

              I always wondered if something like WebAssembly + WebGL + Web Audio + Fetch API could work, with UI frameworks and layout engines delegated to CDN hosted libraries.

              Browsers still need to offer a bunch of APIs for various things, though. Stuff to inspect current context, open/close windows/tabs, manage passwords, etc.

          2. [Comment removed by author]

            1. 5

              But the whole thing is a bit crazy, and suboptimal, and, well, shit.

              This is very difficult to convey for a few reasons:

              1. This is the first platform for a lot of devs
              2. Many devs rely upon it to make a living
              3. There is a lot of momentum behind the web
              4. There are sort-of-correct perceptions about the openness of the web
              5. Big players are investing heavily in the web, mostly out of necessity

              My thesis: these points resonate less as you accrue more experience, especially with other platforms. I’ll pick on #5: why do multiple companies need to dump millions of dollars into making somewhat performant JS VMs? Because JS wasn’t really designed, and no one expected it to become as ubiquitous as it is now. Meanwhile, compare JS with LuaJIT, whose performance is close to V8’s at a fraction of the cost, and you start to see the cost of forcing round pegs into square holes, performance-wise.

              1. 6

                I’ll pick on #5: why do multiple companies need to dump millions of dollars into making somewhat performant JS VMs?

                The correct answer here is “why indeed?”.

                On the backend, we’ve had better tools than NodeJS for years–and while it did help people remember how good async programming can be, there are better and more mature contemporaries that did just fine (cough Java/C#/Python, etc.). But, the hype cycle kicked into overdrive, and soon large companies felt they needed to switch to stay current (read: for manager/veeps/CTOs to show progress). And so, they dumped gorillions of dollars into the ecosystem and propped up the cancer. And VCs dumped gorillions of dollars into other terrible tech based on it like Meteor.

                There is no reason to need a performant JS VM on the backend, because there is no reason to be doing performance-sensitive work in JS on the backend.

                On the frontend, the basic tasks have remained the same: click through a bunch of shit, ask the server something, get the answer back, update the DOM. Not super complicated in most cases–unless you’re doing games, A/V processing, heavy math (think Matlab), or 3D stuff. But again, some people decided that “no, no, we need to make complicated apps in the browser” and then some other folks decided to build tools for them and VCs dropped gorillions of dollars on them.

                And then some jackass decided “Man, I’m sick of wallowing in shit on the Web, why can’t I also wallow in shit on my phone and on my desktop apps?” and then we got Electron and all the rest.


                I guess what I’m saying is that those companies never needed to be in this place–developers somehow managed to put them there.

                1. 4

                  Didn’t Google start all of this? That’s how I remember it. The release of Gmail was roughly where it began. They’ve been trying to shoehorn everything into the web for 12-15 years now, because that’s where they can show their ads. Everybody else followed Google, perhaps due to the undeniable business benefits of the web as a platform.

                  NodeJS became popular as a (late) consequence, and fairly rationally I think: now that so much stuff is shoehorned into the web on the front end, why not unify the languages and write everything in JavaScript, especially after so much work’s already been poured into making it fast.

                  1. 2

                    Gmail most likely played a big role, but if it all started with webmail/groupware, it was before Gmail.

                    Sharing calendars and reading email anywhere used to be a big, enterprisey problem that Google tackled. Gmail is an excellent powertool, if only it didn’t come with extra baggage.

                    Still I find it jarring that now CAD applications and shit run on browsers as a direct evolution.

                    I have a game idea that’s almost useless on any mobile and still friends tell me I should take the WebGL route so people can play or their mobiles. Though it wouldn’t be a casual game.

                    A lack of self-moderation is what fucked it all up.

                    1. 2

                      There were definitely other web apps before (e.g. Yahoo! Mail) but I think Gmail was one of the first examples of a really complex single page web application that was directly analogous to desktop applications.

                      I don’t know if something so huge as the web can be reduced to a single cause. It’s more like thousands upon thousands decisions which had some justification in the moment led us all down a slippery slope.

                  2. 3

                    “I guess what I’m saying is that those companies never needed to be in this place–developers somehow managed to put them there.”

                    Managers more than developers. Those with a balance between conservative and innovafive approach to IT relying on well-paid combo of greybeards, veterans, and young people seem to do well. Need people spotting ideas thag might be good and people spotting bullshit well.

                    1. 3

                      Look, Javascript is pretty far from perfect. But so is basically everything, and if you’re going to write software you have to write it in some language, on top of some platform.

                      At Joyent, we’ve written large chunks of both our Triton and Manta software in Javascript on top of Node for a few pretty simple reasons:

                      • it’s a relatively thin wrapper around the asynchronous I/O primitives that our operating system provides
                      • we’ve been able to build truly first class post-mortem debugging support for Node and V8, enabling us to take core files and investigate bugs after the fact
                      • we’ve been able to harness first class support for DTrace – both USDT probes, and for profiling (using a DTrace stack helper) to get flamegraphs, etc
                      • though binary add-ons technically have to be written in C++, we’ve got a sane C-only layer for the times that we need to bind against system libraries – in stark contrast to the abhorrent leper colony attitude toward Cgo in the Go community, for instance

                      The single-threaded nature of Javascript is both a blessing and a curse, at times. You don’t have to worry about threads, but to get more parallelism you need to spin up multiple processes and use some kind of load balancing. As it turns out, we’re building horizontally scalable distributed systems, so we already needed to do that anyway.

                      I do miss static types. I have fond memories of Java. I still write a fair bit of C where it’s appropriate.

                      Deficiencies aside, it’s frankly exhausting to hear that we obviously couldn’t, or shouldn’t, have built what we did the way that we did. It works for us, and not because we don’t understand what we’re doing – rather, because with the tools that we have, we really do.

                      1. 2

                        As someone who uses Joyent and thinks I’d enjoy working there, I always wish they put that effort into making JavaScript/Node/V8 better into my pet language, Ocaml. It currently has a concurrency model just like Nodes, but it compiles native and has types etc.

                        I have nothing to offer in this comment other than dreams.

                        1. 3

                          I certainly appreciate dreams!

                          For what it’s worth, a colleague and I looked at OCaml over a weekend recently. It was pretty hard to get started on something that’s relatively simple in at least some other environments; e.g., writing a small client for a HTTPS API that uses JSON formatted messages.

                          We also had some serious concerns about the way exceptions are handled today in the OCaml compiler. In particular, we would want to abort the process immediately on an unhandled exception (without unwinding the stack), but it doesn’t seem like OCaml keeps enough information in the stack frame to know, a priori, whether a thrown exception will be caught. V8 does track this, enabling us to have the --abort-on-uncaught-exception flag for node.

                          1. 3

                            No one big, that I’m aware of, has chosen Ocaml for doing HTTP/REST services, so the situation will seem pretty anemic if you’re coming from the Node world. I’m doing my best to address some of the gaps as well as others, but not being paid to write Ocaml means it happens in my spare time. That being said, most of those components do exist. Specifically Async or Lwt, Cohttp, and yojson, and you’d probably want to use ppx_deriving.yojson as well. But I doubt there is any documentation out there that ties all that together for you. But, the reason I use Ocaml is the same reason I use Joyent and run FreeBSD: I believe in the way they solve problems even if it’s behind OS X and Linux and I’m willing to feel the pain a bit for the overall win I believe comes out of it. That being said, I think Ocaml is at the point where the issues you ran into are the type of thing a company could solve pretty quickly if they chose to use it. Mostly it’s picking your stack and writing some templates to bring everything together..

                            For your exception issue, I’m not entirely sure I grok what you mean. If an exception makes it all the way up to the program entry point it will end the program. And stackframes being recorded depends on a runtime option, by default they are off. I actually avoid exceptions for the most part, choosing instead to use a result monad almost everywhere combined with polymorphic variants. I find it significantly less surprising than exceptions.

                            I know there is only a small chance of you picking up Ocaml and applying it at work but if you feel the urge to look at it again and run into issues, feel free to direct message me with any questions.

                            P.S. I’d love to see native dtrace probe support in Ocaml.

                            1. 3

                              For your exception issue, I’m not entirely sure I grok what you mean. If an exception makes it all the way up to the program entry point it will end the program. And stackframes being recorded depends on a runtime option, by default they are off. I actually avoid exceptions for the most part, choosing instead to use a result monad almost everywhere combined with polymorphic variants. I find it significantly less surprising than exceptions.

                              Yes, in general I’m in favour of “errors as values” as well. I think exceptions make sense for what we would call a “programmer error” (as opposed to an “operational” error), specifically because I don’t want to handle them – because, frankly, you can’t. For a dynamic language like Javascript, these sorts of errors include misspelt property names or type errors that aren’t caught by linting; for a statically compiled and more strongly typed language I’d expect less (or none!) of these at runtime.

                              I’ll try to explain what I meant by way of example. In Javascript, you catch exceptions by wrapping the potentially throwing code inside a try block. You can’t escape the block, except by executing all the way to the end. Once you enter a try block, you’re in “handled exception” territory, no matter how many nested functions or other try blocks you subsequently enter – they just nest. V8 tracks whether you’re in a try block or not, and if you’re not, we’re able to abort() the process immediately (without unwinding the stack) and get an operating system core file. We can then look at this with the debugger later, as the state up to the panic-style failure was completely preserved. As such, we religiously avoid try except tightly around code which doesn’t stick to the “errors as values” principle (e.g., JSON.parse()), so that we can get core files for all of the programmer errors that arise at runtime.

                              My understanding of the current structure of the OCaml compiler is that it does not track (in the generated program text) whether you’re in the OCaml equivalent of a try block. Instead, when you raise an exception, it unwinds the stack one frame at a time, checking to see if the exception will be handled in that frame. To get full stack traces emitted to stderr, as you mention, you have to turn on the generation of the entire stack trace string into a global buffer for every exception just in case it turns out to be unhandled. We would rather get a core file at the point of the failure (without unwinding) iff it’s to be unhandled. It’s possible that there’s some property of the OCaml language that means you can’t know a priori if an exception will be caught or not – if so, please forgive my ignorance.

                              1. 1

                                Ohh ok I get the exception thing. I do not believe the Ocaml runtime supports this. Given my shallow understanding of how exceptions are implemented I think it might be possible. My understanding of exceptions in Ocaml is that they do not do stack unwinding but are implemented as an escape closure. This is why attempts to implement the Ocaml code generator in LLVM have been met with limited success: the exception implementation is not fast enough.

                                I don’t know how exceptions work in JavaScript, but does this abort thing if you are not in any try block? What about the case where you are in a try block but it doesn’t handle the exception being thrown? In Ocaml, like in Java, you can match on the type of exception.

                                IME, at least, though, my production programs only use exceptions for very exceptional cases such as out of memory.

                                1. 1

                                  If you’re not in a try block, the exception will bubble all the way out and be uncaught; the default behaviour (in Node, at least) is to emit a stack trace to stderr and exit non-zero. We added the --abort-on-uncaught-exception flag, so that instead of printing the stack trace it will abort() itself and the OS can generate a core file.

                                  It’s not possible to handle only a subset of thrown exceptions, unfortunately. It’s all-or-nothing, partly because it would be difficult to correctly ensure you’re matching on the same exception type – and partly because Javascript lets you throw anything, even a string.

                            2. 2

                              I’d offer up Scala as a decent ML-family (but I repeat myself) language with production-quality HTTP/REST server (and client) libraries. Also lets you achieve the “same code on the server and client” thing via Scala.js.

                              (It does have plenty of awkwardnesses where you just have to hold your nose and do this because of JVM compatibility or backward compatibility, but they’re all minor things with well-known workarounds. I find it adds up to the best experience going these days, though I’m sure everyone recommending a language feels the same way about their choice)

                              1. 2

                                What puts Scala in the ML-family?

                                1. 1

                                  Wikipedia description: “Features of ML include a call-by-value evaluation strategy, first-class functions, automatic memory management through garbage collection, parametric polymorphism, static typing, type inference, algebraic data types, pattern matching, and exception handling. ML uses static scoping rules.” Scala has all of that.

                                  (One could argue it doesn’t quite have first-class sum types, but its sealed traits go beyond what most non-ML languages offer and it’s very much idiomatic to use them as sum types)

                          2. 2

                            Look, Javascript is pretty far from perfect. But so is basically everything, and if you’re going to write software you have to write it in some language, on top of some platform…. it’s a relatively thin wrapper around the asynchronous I/O primitives that our operating system provides”

                            In this nice justification, I try to zoom in on what makes JavaScript the language you “have” to use. You saying “build” and “harness” makes me thing your team added that to a platform. If so, I’m ignoring it since you could’ve added it to other language’s libraries w/ combo of that + a better language resulting. The quote above is the one thing Node already brings. So, was there no support for simple, asynchronous execution in any of the better languages? I’ve seen hobbyists and FOSS projects using async in various languages but didn’t realize it was complex or unstable enough to switch languages.

                            “but to get more parallelism you need to spin up multiple processes and use some kind of load balancing.”

                            This one is a disadvantage of JavaScript engines vs smaller, leaner runtimes.

                            1. 2

                              Lua coroutines make it easy to use asynchronous I/O and make it seem like normal procedural code. You have a blocking call? No problem, just yield to another coroutine. I use that method at work and the main processing code is easy to understand and modify.

                              So, how does NodeJS work again?

                              1. 1

                                Lua came to mind when I was writing that since an embedded application server uses it: Barracuda.

                              2. 2

                                You saying “build” and “harness” makes me thing your team added that to a platform.

                                We definitely built mdb_v8, but I chose “harness” to reflect that we did not build node-dtrace-provider.

                                If so, I’m ignoring it since you could’ve added it to other language’s libraries w/ combo of that + a better language resulting.

                                Except that you can’t ignore it. V8 hit an important sweet spot in terms of the way it generates code and represents objects and program text in the heap that enabled us to build a DTrace stack helper and a post mortem debugging tool that works on operating system core files. I’m not convinced it would be as easy (or even as possible) to build similar tooling for every other language and platform out there. Building a DTrace stack helper, for instance, requires that the identity of the routine in an activation record be something we can load from the process image with a D routine (which does not provide for loops or backwards branches).

                                I need to stress, again, that at the end of the day you have to pick something and put your back into it. We did that with Node, and it’s been good for us. You may not like Javascript – it’s definitely full of warts! – but frankly every language and every platform has deficiencies. Software sucks, as they say.

                                So, was there no support for simple, asynchronous execution in any of the better languages?

                                Better is frankly pretty subjective. There are definitely other languages that provide for this, but again, we were interested in the entirety of a programming system for engineering software, not just one or two of the things on the list.

                                This one is a disadvantage of JavaScript engines vs smaller, leaner runtimes.

                                No, it’s a disadvantage of any language and/or runtime environment that operates in a single-threaded fashion. Javascript is just one of these, but many or most of the other dynamic languages are basically the same in this respect.

                          3. 2

                            The need for easily-deployed cross-platform apps was 100% real. It’s pathetic that the industry never came up with a good way to do that (something like Java Web Start is objectively a lot more sensible than making your app run in the web browser, but it never got deployed widely and permissively enough that the typical user could just click a link and have the app run) but that’s an indictment of industry politics (and possibly of the complete inattention the Java folks displayed to startup latency), not of the people who found ways to make the only deployment platform that actually works slightly less terrible to develop for.

                        2. 1

                          They can’t fix insane browser incompatibilities.

                          I wish the Mozilla foundation would regain their balls and create HTML6 with all the obvious brokenness fixed.

                          M$ would eventually catch up as they always have.

                          The trouble is Mozilla and W3 has been trying to play nice and M$ and Apple have just been pretending to play nice.

                          All those things are out of their hands. Some of the tricky things web devs do border on genius,

                          All those things are out of their hands. Some of the tricky things web devs do cross the border on of evil genius,


                          1. 2

                            Mozilla no longer controls significant browser market share so they can’t do it unilaterally. Hell, even Google, which makes Chrome - now the most popular browser - hasn’t been able to get DART adopted widely, so I am quite certain any changes made will need to be done by at least 3 browser makers working in concert. And even then, you can’t just ignore backwards compatibility so it’ll take years for any major changes to be adopted.

                            1. 1

                              The longest journey is the one never started.

                              1. 1

                                Google didn’t try to make dart widely adopted. They decided not to include a dart interpreter in all builds of chrome on purpose.

                          2. 7

                            I wish I was less contrarian about the web, honestly. I just don’t find it to be an inspiring medium at all. I’ve done lots of web stuff in the early days with Perl, HTML, and ES3, even made a chunk of change off of web advertising! But now it just seems…different somehow. Maybe I’m over it, or maybe I’m too stuck to the idea that the platform I build on has to be nice. I think what bothers me most is I see what native apps are capable of and how far web apps are from getting there and I just can’t compromise on the user experience even if it means reaching fewer users.

                            That plus the fact that I’ve never used a backend framework that I felt like I really liked; most of them still seem conceptually huge somehow for what they do and put me off from using them.

                            All this to say: as much as we like to talk about making the web open for everyone to be a basic web dev, the complexity probably puts off a lot more people than we care to admit.

                            1. [Comment removed by author]

                              1. 4

                                Native apps with cross-platform or native GUI’s packed as standalones linked against a stdlib. These already exist by various developers. They download, install, and run fast even on older machines. They’re also easier to sandbox.

                                They’re just not the worse thing that was better and tof momentum. Result of political bickering and lockin attempts among platform vendors. One can still deploy this way, though, if the customer is fine with it not being a web app.

                              2. 17

                                I don’t really agree with this, in basically any meaningful way, mostly because the writer has their head up their ass.

                                Expectations for what a web site should be able to do have evolved enormously. […list of bullshit follows…]

                                And they want a pony and a snow cone and anything else devs are stupid enough to claim they support. And frankly, I’d argue that devs are projecting on users quite a bit: devs want to build fast apps with instant loading service workers and spiffy SPA stuff and all the rest, not users.

                                You know how I know this? Go look at “boring” but huge-traffic sites. Go look at 4chan, at Reddit, at Stack Overflow (notice that the tabs load a new page, every time), at Craigslist. And then come back and tell me that somehow users are clamoring for anything more complicated.

                                The functional and popular web only needs basic things.

                                The web as a platform, as ever, lags behind its developers. They want ES6 syntax, they want modular JavaScript, modular CSS and modular HTML. Browsers provide none of these things, so they are hacked together in frameworks.

                                The browsers provide none of those things because they aren’t necessary–no more required than say stabby lambdas in ES6. Hell, if you want “modular” things, consider just using different script tags and IIFE. We had those for ages and they worked fine.

                                Devs aren’t adopting all this new tech just because it’s new and fun (though it’s a bad idea to dismiss fun as a valuable quality in a development tool). They are doing it because they have to in order to survive.

                                Bullshit. Most new tech comes out because of one or more of:

                                • Learning how to use existing tech/APIs is hard.
                                • Making your own new APIs is fun work that isn’t as boring as delivering customer value. (see also yakshaving)
                                • It’s harder to sell product than it is to sell consulting–and you get street cred for being the dev who made X/Y/Z (the new hotness)
                                • It’s harder to build a reputation for building solid applications than to give conference talks.

                                Are there some people using a huge pile of JavaScript and a monstrous build chain to throw together a single-pager web site with one box that collects an email address? For sure. And that’s silly and unnecessary. But so what? The misuse of technology does not invalidate it.

                                How many billions (BILLIONS!) have been wasted by companies trying to have mudball jQuery applications cleaned up? How many man-centuries have been wasted waiting for an over-built “web app” to load to display a static document? How many gigawatts (and fuel and so on) are wasted on processors crunching spurious bullshit JS that never needed to be there?

                                This is a fucking plague. This is ludicrous spendthrift garbage. This culture of ignored externalities is killing us, folks.

                                Over the next 5 years I expect there will be a lot of consolidation in technologies and in tools.

                                No, because web assembly is going to let every chucklefuck use their pet language and framework(s). It’s going to be the goddamn tower of babel. Things are going to get so much worse.

                                jQuery was a performance problem at scale, and sometimes over- or mis-applied, or used superfluously by newbies who didn’t know there was a simpler way. Big deal.

                                Again, author clearly has no empathy for the poor schmucks who have had to actually deal with solving the messes left by other developers who shared the author’s philosophy–or the people signing their paychecks.

                                Nobody but nobody loves the web more than I do. It’s my baby. And like a child, it’s frustrating to watch it struggle and make mistakes. But it’s amazing to watch it grow up.

                                The author’s child is the little shit that runs around and sets fire to squirrels and breaks things and the author is a shitty parent for celebrating that behavior and telling other parents to let their kids do the same.


                                And then I saw that the author is an exec at npm, and it all makes sense.

                                Of course the author shills for the “evolving” web, because their business is predicated on that growing cancer and shitty development. Of course they’re going to insist “This is fine, this is the way things’re supposed to be”–their livelihood depends on it!

                                Author: You write shitty software. Your company writes shitty software. Your views on engineering are a net negative on the web. You are a bad person and you should feel bad.

                                1. 5

                                  Personal attacks are not acceptable here.

                                  1. 12

                                    Was I attacking another user of this site? No.

                                    Was I pointing out that the author knowingly supports bad software that directly impacts in a negative way thousands of developers? Yes.

                                    Look, saying that “@gambogi you’re a goddamned carebear and your face is ugly and you stink” is a personal attack. Pointing out that somebody online in a position of power is making the world a worse place by their actions is not.

                                    Now, perhaps “you are a bad person” should be person-first language “you are a person with bad thoughts and actions”–mea culpa.


                                    Let me make vent a little more on this point.

                                    A few years ago I had to deal with the stupidity of npm. I had to deal with npm’s decision to just use nested dependencies, with their derpy version management (shrinkwrap having been eventually introduced). Others had to deal with the entire left-pad debacle, but I personally along with my team wasted man-days on this.

                                    That was time I didn’t get to spend with my family. That was time I didn’t get to spend exercising. That was time I didn’t get to spend posting online. That was time I didn’t get to spend eating, fucking, singing, playing, cycling, dancing, or anything else that makes me a human being.

                                    That is time I’m never getting back.

                                    And this bozo? This is the person responsible for the engineering that caused those problems.

                                    We have to hold engineers accountable for their actions.

                                    1. 0


                                      1. 1

                                        That doesn’t make it morally correct, especially when the package is being shoved down people’s throats with VC marketing money.

                                    2. 4

                                      If people can’t interpret text at all, they shouldn’t be online.

                                      Nothing is as frustrating to read as apologetic “I’m sure you are a nice person with your family, and even Hitler painted roses, but when it comes to your position in the public eye and the way you exert power, I find your actions disagreaable to say the least, and if political correctness had not won, I’d call them outright evil!”

                                      It’s ok to say someone’s bad every once in a while and let the reader figure it out.

                                    3. 2

                                      I agree with you. I just want to point out that mobile reddit is complete and utter JS-laden abomination. They probably know how bad it is, because they heavily advertise their mobile application. I even think it is intentionally bad, to push the app down their users throats.

                                      1. 2

                                        It used to be so simple too…

                                        1. 2

                                          I’m a fan of their .compact view: https://www.reddit.com/.compact

                                    4. 4

                                      I have a tendency to disagree with the spirit of the entire article, but there is one specific point he makes that I specifically don’t like:

                                      Users expect snappy, desktop-like responsiveness and rich presentation in web apps.

                                      I really don’t know about rich presentation and I’d like to see more user-testing to see if that is actually true. Are users upset that Wikipedia’s logo doesn’t spin in circles? Are they upset that Craigslist’s page doesn’t jump around halfway after loading the page?

                                      Website garbage isn’t just annoying, it’s damaging. Anyone with a limited phone plan knows that the wrong website can eat through half of your data plan for the month. Opera is still very popular because the browser sidesteps all of the “innovation”. I have missed out on deadlines because a webmaster decided that button wasn’t enough and made it into a JS div that didn’t work.

                                      I appreciate that he is acknowledging that this new web tech has problems, but I don’t appreciate how he makes them out to be minor bugs rather than serious issues that cost people a lot of money.

                                      It is of course important to acknowledge that Slack, Facebook Messenger, and other walled-garden web apps are a different conversation separate from the animations, ads, etc. that are added to typical websites people view every day.