Hacker News Reader

Essentially every single aspect of the web is terrible. It was designed as a static document presentation system with hyperlinks. And for years and years and years, no matter how much interactivity was shoehorned into this system, the standards bodies absolutely refused to make any design decisions based on the absurd notion that it was an application platform. They have only changed this view very recently, and the consequences of their decisions made to optimize the creation of static documents with hyperlinks will continue to be felt for a decade probably.

Had the web been designed as a distributed application platform with HTML being a user interface layout language and such, things would have developed very differently. And because making it do anything interactive most often required misuse and abuse of the browser, it wasn't much pursued by bona fide software engineers who knew the pitfalls of ad hoc 'organic' development and 'just keep typing until something works' mindsets. So, that's what we got. Big ball of global mutable state, scripting languages designed to make it so you could have a button light up when the mouse hovered over it bent over and made to do real work, dependency webs so complex that they're generating novel unsolved problems for graph theorists at every turn, etc.

All of this because users want to be able to search vaguely for what they want and be using an application a moment later. Something that could be solved a trillion different ways but nobody realized at the time that it is what people really wanted. So now we oh-so-slowly move towards the web becoming an actual application platform, but hamstrung by companies that feel entitled to every data point we ever generate so they seek to insert latency into even the simplest interactions by requiring asking their machines for permission.

Had the web been designed that way it probably would have died an early death. Back then we didn't have gigabytes of RAM, fat pipes, and an abundance of cores to run interpreted code that is shipped from hundreds of kilometers away.

I don't think it's true that everyone seems happy with this. In the past 10 years culture has shifted dramatically towards encapsulating and minimizing JS state (modules, moving away from imperative jQuery code and toward MVC, React) and, to your other point, moderately towards more strict CSS organizational techniques (OOCSS, SMACSS, BEM).

I agree that the culture by default was to program everything against a giant mutable state bucket and I'm not sure why that happened.

But the idea of React is to have central application-level global mutable state, instead of jQuery's lots of fragments of local state attached to DOM nodes ($(...).data) or kept in callback closures, CPS-style.

IMHO, article does not explain in what cases it can be better to have a global mutable state (i.e. containing mutation in Redux) instead of lots of local mutable state.

I think the single state object in React/Redux is more an implementation detail than anything. Using regular js variables would allow free mutation for everyone at any place, so a new "variable system" must be created by encapsulating all state in an object.

You cannot avoid keeping state and mutating it, the point is to do so in a predictable and controlled way. It is not that relevant whether you refer to `state.value` or just `value` as long as you're able to keep track of all your mutation sources easily. Having a global object is just a way of conveniently do that in javascript.

For styling, I'd look into CSS in JS, specifically JSS. Not only are all selectors scoped, you can create functions that return the proper styling. Frankly I think web developers as a whole need to rethink CSS and/or any paradigm based on traditional CSS like SASS/SCSS. We shouldn't need messy global variables like classes and ids to change styling.

Not to mention the usual arguments for CSS just don't make sense. CSS isn't decoupled, in fact the reliance on HTML classes and ids is extremely coupled. JSS can just be left in a separate file and imported wherever it needs to be used.

Thanks for mentioning JSS. I'd never come across it before but it looks very interesting.

I'm currently using it in a pretty large project and it's been awesome. Having the CSS related to the component in the component is really nice (which is found in other frameworks). When refactoring you don't have to wonder what this class could be tied to since it's all right there. You also benefit from dead code elimination so unused CSS classes get removed.

Yes it's really quite amazing that browser development has gained the traction it has, considering what a terrible environment it is to work in. I think its a combination of a lot of devs never having done anything else, so they don't know better, and also that removing the friction of deploying and configuring native apps was worth all of that.

Definitely leaning towards the latter IMO. That stuff was a nightmare.

* lowest barrier to entry of any platform

* View Source of anything

* development tools that keep improving by the day

* non-proprietary, open standards

* completely sandboxed from host environment

* runs anywhere

* first-class GUI support

The list goes on...

Right... when was the last time you USED View Source on something done in JS and actually used on a production site? Sandboxing from the environment also has its upsides and its downsides. What people actually want applications to DO is deal with their information. And sandboxing the host means they lose any semblance of control over that data, leading to it getting monitored, mined, etc. And it doesn't solve any of the actual problems. It just changes the target while simultaneously making those targets SO much juicier. Want the personal info of 143 million Americans? Hack the web app of a credit company, no need to hunt down and break into 143 million different machines! And the users won't even know if the data was stolen unless a company volunteers the information! Sometimes they even do!

I really, really have to wonder about "first-class GUI support". Prior to the web applications used standard UI controls. Because that makes sense and makes computers easy to use. The web brought 'every single UI is different', which is horrendous. And when you can manage to put together a UI with web tech, then it's trapped in the browser. Which actively goes out of its way to make it as difficult as possible to manage running several different things at once.

I think the answer to the webs success boils down to delivering what users actually want. Despite all the other warts, its valuable enough to convince them to not care. They want to search for something they want, vaguely, and be using an application one second later. All other considerations be damned. They'll wrestle with confusing UIs that change all the time without warning. They'll accept not having a lick of control over their data. They'll deal with being aggressively advertised to and companies trying to hound them into subscriptions because the 'service' of working around the sandboxing by keeping their data together needs ongoing cash infusions when the user only wanted a single product they could use for long periods of time. Like if people who made hammers started making ones that would only work with nails gotten from the hammer manufacturer and they didn't permit you to get enough to last, requiring a subscription so they could sell the information about what kind of nails and how often you were using them to a nail company.

> when was the last time you USED View Source on something done in JS and actually used on a production site

I don't disagree with most of your post but I am confused why you brought this up as a point of contention. Viewing source is pretty common?

My understanding of this argument, as best as I'm able to state it, is approximately: Claims that view-source is a significant virtue of the web are nostalgic and misguided, as demonstrated by the fact that it's difficult and rare today to find anything usable or valuable by reading the javascript source of major websites like facebook, especially by amateurs.

It's possible that I've misunderstood some nuances about the claim, and I apologize if I've misrepresented the comment you're replying to.

Sure large sites with extraordinarily valuable IP make it hard to view source and learn anything. However other smaller sites are a wealth of wisdom. Just the other day for example I inspected the new KIKK website to see how they managed to keep their website silky smooth on mobile whilst cramming quite a few transitions/animations in.

And for that matter I learned a heap inspecting (whilst attempting to reverse) Google's culture project. Specifically how they protected their image assets using a novel technique (since this was in pre-web-DRM world).

The other thing is as sites know their code is in the open I suspect it's easier for devs to get internal approval to do write ups of particular techniques.

The discussion was about why the web became a successful platform in the first place. There is no doubt "view-source" was a very significant factor in this. This is basically how the first generation of web devs learned the craft.

> Right... when was the last time you USED View Source on something done in JS and actually used on a production site?

I tweaked Discord's scrollback limit a few times by hunting down the appropriate constant, setting a breakpoint where it was used, and modifying the value then, to make it work better on my portrait 4k monitors. Couldn't be bothered to proxy the javascript (or otherwise do something persistent to modify the JS) to make the change stick though. Something I did make stick was the removal of "Blocked Message" notifications which I use to filter out particularly noisy bots in poorly moderated channels. That's certainly been within the past few months.

I've got javascriptlets which, while not dependent on the actual source of a website, will speed up HTML5 video to 2/3/4x speed. Past year or so?

I wrote a browser extension that abused the Trello DOM for a bunch of minor UI things and added some nifty time tracking stuff. A few years ago now, admittedly.

Oh sure, the minified sources are terrible to parse through these days, but it's still an option. Meanwhile, I still can't deal with x86 disassembly fluidly enough to reasonably modify other people's programs, despite staring at such disassembly for longer...

Why is it amazing? A new platform delivers enormously simpler and cheaper development and deployment of cross-platform applications. Why is is surprising people adopt this platform?

> One of the most confusing things I find with web development (which I'm mostly new to, coming from a backend background) is that everyone seems entirely happy with JS (or more accurately the DOM?) and CSS being giant mutable state buckets.

Actually, as you guessed, lots of people in the modern web community are unhappy with the mess of mutable state, and have done something about it! Redux [1] is all about using immutable state to tame the mess into a simple model involving application state expressed as an immutable object, the ui produces events, which get piped through a reducer, yielding a new state. If you skim over the "redux motivation" link below you'll see it talks all about the issues you're raising.

There are tons of variants of this theme, including NGRX which is the same concept applied to Angular 2. [2]

> CSS especially is a nightmare. It's near impossible in complex projects to work out if your change is going to change other things adversely...

I feel your pain, and have struggled with this endlessly in the past. However, this is a mostly a well-solved problem in modern environments. For example in Angular 2, the css is automatically scoped for you down to the component level in a sane way[3].

Try React with Redux, or Angular2 with NGRX and see if it solves the issues you're concerned with.

It's enough different options to make your head spin, I know. Just try out Angular 2 or Redux and see what you think.

[1] http://redux.js.org/docs/introduction/Motivation.html [2] http://onehungrymind.com/build-better-angular-2-application-... [3] http://blog.ng-book.com/css-isolation-in-angular-2-component...

I don't think people are (were) actually happy with it: Hence the immutable/FRP-ish UIs of React and similar frameworks. Of course they still have to cope with the realities of web browsers so there's still some ugliness in there, but the awfulness is mostly contained.

(Though, you're absolutely right about CSS. It works fine for global state. The only problem is that "components", i.e. small bits of UI, aren't global.)

> CSS especially is a nightmare. It's near impossible in complex projects to work out if your change is going to change other things adversely.

This is solved with shadow DOM.

> In Javascript it seems normal to (at least in angular) push to global scope, and so it can be really unclear where values come from, or how they get set.

Well, nobody forces you to do it in JavaScript. I think newer frameworks (and culture around them) discourages this.

> Testing any of this stuff is also pretty nightmarish. Knowing the web I'm almost certainly behind the curve and there is new hotness out to solve this, but I've never much luck with automated browser testing. Things like Protractor tests are incredibly onerous to write, and inevitably end up as flakey slow messes that fail builds due to flake more often than they find issues.

I agree that testing the whole application is tricky, but testing components is easy enough these days.

> This is solved with shadow DOM.

http://caniuse.com/#feat=shadowdom

You can use a polyfill.

> One of the most confusing things I find with web development (which I'm mostly new to, coming from a backend background) is that everyone seems entirely happy with JS (or more accurately the DOM?) and CSS being giant mutable state buckets.

Why is it surprising that people are working within the constraints of what is practical right now? What are you going to use instead that is so much better? If you want to do web development, you have to use CSS and JavaScript in some form. Just with backend work, there are good and bad ways of doing frontend coding.

Check out Tachyons and similar CSS libraries which use CSS classes to essentially define inline styles efficiently. When you are making components, this can work out well in containing potential interactions of CSS. http://tachyons.io/

Combined with a lightweight vdom library like Mithril.js using the HyperScript API and maintaining state in plain old JavaScript objects (updating on any user interaction, network events, timers, or some few other events), this makes web single-page application development quite pleasant and scalable. You can also test much of such vdom-based UIs without creating real DOM nodes. https://mithril.js.org/

Here is one example FOSS project I wrote in that style: https://github.com/pdfernhout/Twirlip7

Of course, few web developers grok this yet because most affirm "best practices" from years ago (e.g. semantic CSS, HTML-first design, JavaScript as a progressive afterthought) -- and also are used to coding in non-standard HTML-ish templating systems (e.g. Angular, Vue, JSX) which give them a false sense of security they can maintain more complex apps that are mostly about JavaScript. React has helped a lot of developers begin to move past some of that, but it has its own licensing issues and also baggage (including JSX) from being only half-way to the new paradigm outlined above.

Its difficult to get front-end developers to scope their CSS properly and separate UI components into non-conflicting separate modules.

Without the insight of having ever kept a back-end applications various functions isolated and grouped logically they always just lump everything together.

Define a grid system to handle rough layout, then hang your widgets inside each cell, if you have to use !important, ever, you have failed.

Are there best practices for scoping CSS correctly? I seem to reinvent the wheel every time I make a new website.

https://github.com/css-modules/css-modules takes care of it all for you.

BEM -> CSS modules -> CSS-in-JS

https://twitter.com/markdalgleish/status/910281166128791553

You're mostly right.

Just know that things are fantastically much better than 10 years ago!

It's unfortunate that mutable global state is the default approach to web development, but it's certainly not true that everybody is happy with it. We're actually in a golden age of web development right now driven mostly by functional approaches to web development that adhere to the principles of minimizing global state, sensibly managing what global state is necessary by means of treating it effectively as an immutable collection, and defaulting to pure functions where-ever possible and limiting in-place mutation to hot code paths, while still being mindful of containing those side-effects to within lower-level function boundaries.

On the JS side, we have projects like Redux that effectively forbid direct mutation of global state by a pattern of describing state mutations using data (Actions), and handling those mutation descriptions in pure functions that take existing state, along with the aforementioned state change descriptions, and return the expected next state without any observable side effects (Reducers). This approach leads to a codebase that is simple to test and to reason about, and enables certain development and debugging workflows that would not be possible otherwise, such as component-level, state-preserving hot-reloading, server-side state hydration and pre-rendering, and time-travelling debugging (See Redux Devtools). The popularity of Redux in production React apps today is a testament to how well this approach scales in terms of app complexity and team size.

In terms of CSS, definitely take a look at styled-components and Glamorous. They are AFAIK the state of the art in component-oriented CSS libraries, and can do anything you can in standard CSS (media-queries, pseudo-selectors, etc), unlike earlier CSS in JS libraries that come with all sorts of tradeoffs and limitations. The major win you get with these libraries is that styles are locally scoped by default and do not extend past component boundaries, so you can ensure each component is solely responsible for styling everything within their own borders, and will be styled consistently regardless of the surrounding context. The global-by-default, specificity-based-overriding, and recklessly-cascading aspects of CSS have long been considered harmful in component oriented architectures (rightfully so, in my experience), and tools like these allow you to opt-out of those properties by default, while still allowing you the opportunity to apply them mindfully and sparingly only when they happen to be the right tools for the job. Also, with Glamorous, which uses JS objects to represent CSS rules, you can programmatically manipulate your styles with everything in JavaScript available at your disposal (no more struggling with crappy DSLs like SCSS and LESS), and can make use of JS variables and modules to enable style reuse and take advantage of Webpack tree shaking to ensure only used CSS rules are included in your final bundle.