Hacker News Reader

Comment by robgibbons | Hacker News Reader

Not to be too negative, but I'm seeing a lot of purely anecdotal comments on HN with lots of fuzzy gut feelings and very little to back up what seemingly amounts to elitism against JavaScript.

It's very easy to write fast JavaScript, with React or pick-your-framework. I would argue that these frameworks go out of their way to help you do that. But carelessly throwing modules at your problem is not going to get you that.

There are many reasons why SPAs can be slow. Whether that is due to truly lazy developers, overly tight deadlines, or management that just doesn't care is often left out of these discussions.

Everyone likes to complain about SPAs, as if terrible load times are a fundamental trait of frontend frameworks. That is not at all the case.

View on HN

> Everyone likes to complain about SPAs, as if terrible load times are a fundamental trait of frontend frameworks. That is not at all the case.

I disagree. SPA frameworks attempt to re-implement browser UI and DOM within Javascript. Of course the result is buggy and slow.

The browser already has a UI and DOM framework. Use it. (Yes, I know it's ugly. Such is life.)

Depends on the target audience. Many customers will be sold on how pretty an app is, sometimes to the point of overlooking missing features. Having a good looking app becomes a competitive advantage, and therefore important to spend time on. Such is life.

Your point is orthogonal, even if true. My point is that SPA frameworks are necessarily buggy and inefficient - after all, their whole point is to reimplement in a bespoke fashion the stuff that the browser already implemented.

Buggy and inefficient stuff sometimes makes sense to a business, this is true.

That’s a common misunderstanding and absolutely not true. They are abstractions and not reimplementation, and in practice can help achieve way better performance than what would naively come out. React is not a particularly good example of that.

They also solve problems like state synchronization and mutations that the browser has zero facilities for. As mentioned in another comment above, in any medium sized project you’ll have implemented more than half a framework abstracting the DOM already.

Trying to remember the last bug I encountered in React. I’ll be a while.

That can be achievable with designers that actually know their way around HTML and CSS.

The problem with UI/DOM is the mental model of working with it. For me I think SPA frameworks need to provide an abstraction layer that makes it easy to work with.

Thus React. I can think of it in a functional pattern and let it abstract the DOM/UI for me, ofc I understand there's a cost to it but that cost will greatly be overshadowed development & maintenance costs.

Whatever happened to the "think of the user experience first". I am sad this shift to "it's easier for me to develop, who cares about the users" happened.

a developer who doesn't think of that is going to do that with react or without react. freeing up development time to focus on better user experience is more possible by using a framework such as react.

This is because Front-end web developement has been taken over by back-end developers.

Few developers complained about JavaScript until Back-end developers became 'Fullstack' and had to start working with it and tried to apply the same mental model they had used with Java or Python etc.

CSS was always something you had to dedicate time to, to master and learn the quirks of the current and past browsers, until Back-end developers decided it was 'terrible' and a race to the bottom of CSS frameworks was created and nobody remembered proper selection or specicifity as BEM was adopted.

HTML was a tool for layout which developers made good choices for thoughtful semantic code, so that it was easily readable, for both man and machine, yet it was a manual process. Then Back-end developers didn't have the time to learn something new and everything is a div and if you're lucky it will have a role.

As a "fullstack" i disagree with this view.

This is the "if all you have is a hammer, everything looks like a nail" kind of view.

What i believe is, the complexity of developing software has been increasing and we have a lot of pressure specially due to time constraints that we are always reinventing the wheel in order to meet deadlines and try to make things easier.

And the result is always the same: bloat.

I'm not convinced that software has been increasing in complexity, I just think that more complex sites are being created now than in the past, and there are less capable developers having to work on these sites.

I agree that pressure is high and time constraints are tight and this forces people to look for an answer outside of themselves.

Complains and jokes about JavaScript have been here from the first time JavaScript was released. Many of them fully rightful. There are even years old memes about it like thousands of variants for this https://img.devrant.com/devrant/rant/r_1585_DY1Kk.jpg

The complains about CSS being something that is hard to learn and remember and about its shortcomings and hard maintenance have been here also for years. The thing people acknowledged was that it was improvement over writing it all into html.

Original HTML contained everything that CSS contains now - unseparated. And for that matter, everything is DIV because CSS people and designers like it so. It has nothing to do with backend people who would happily use table everywhere if only they were allowed to. Then again, css people and designers did not pushed for divs out of whim - they want it that way because it is practical for them.

Yes people acknowledged that CSS was an improvement, but most of the shortcomings were not because CSS was at fault but that browser vendor implementation was slow and inconsistent.

CSS has always been relatively simple, the complexity came about by having to juggle workarounds and hacks to support all the different browsers.

I completeley disagree with your last statement, divs had been around for a long time before they became a one-hit wonder for all elements, nobody needed or wanted them.

Once CSS 2.1 was adopted and table layout was no longer required semantic html ruled.

Divs have only become ubiquitous since CSS and front-end frameworks have become so popular

Pure css is not comfortably maintennable. It lacks variables for example. That is massive shortcoming - inability to say that this color is same as that color. Or alternatively that this selector here is same as the one over there.

Also, even things like making stuff same height were absurdly difficult with css even absent browser differences. It is oddly inconsistent language with hard to remember rules.

And it often ends with house of card constructions that break the moment anything changes.

Unless you're still supporting IE, CSS variables are now available:

https://caniuse.com/#search=css%20variables

I use less or sass. Both have even more goodies in them.

Actually, pure CSS can be comfortably maintained--if you're willing to limit your project to specific parameters or, simply, use a well-defined methodology (i.e. BEM, OOCSS, ITCSS, etc).

I've read some developers limit their CSS file(s) to 50 lines (max.) while other developers build their CSS on a page-by-page basis dependent on a primary global style sheet (ex: content-sidebar.css is loaded on every static page and post while content-page.css is only loaded on static pages).

Where I currently work at, every static page gets its own CSS if it meets the following two parameters: (1) accessible from the root and (2) not part of a larger (or "nested") set of pages--two rules becomes necessary when you have a team who hates nested pages and prefers an internal taxonomy system. The styles are encapsulated by adding an additional HTML class (usually a sanitized version of the page title and its ID) to the body tag.

For pure CSS websites, OOCSS will be your best friend as it forces serious thought into how you define your style rules. Additional rules also include limiting the use of CSS vars only to elements that have an ID attribute (which is also limited as well).

That's a helluva broad brush you are using there.

Yeah, I know. Felt good to get it off my chest though.

Sorry that is a crazy thing to say. With node (front end tech at heart made by front end people) programmability invaded the frontend. Which gave myriads of new ways to solve problems and given that all the front end problems are new and the community is fairly young the whole thing is pretty wild currently. No backend dev would care about SPA madness is he had the choice.

If it's easier for me, I can care for more users.

> I disagree. SPA frameworks attempt to re-implement browser UI and DOM within Javascript. Of course the result is buggy and slow.

SPA frameworks don't re-implement the DOM, they provide an interface to the DOM that is more usable. That may or may not have significant overhead, but it's not a given.

You have these benchmarks to show that "vanilla JS" is faster, but that's not real-world application code. Because of the usability issues, application authors are way more likely to not write optimal vanilla code. In particular, any DOM modification is extremely slow, so redundant modifications are very wasteful. Avoiding those is something that a framework/virtual-dom can do for you, to let you write simpler code.

Furthermore, anybody who writes a real application ends up abstracting the DOM interface, so they're already halfway at an ad-hoc framework. Not abstracting the DOM would result in an insane amount of boilerplate code, which would hamper developer productivity, which would result in even less time spent considering performance.

Disclaimer: All of this is true for applications, not for simple websites with minimal dynamic interaction. You're likely better off rendering those server-side and then attaching a couple of event handlers on page load.

The imperative DOM “framework” available is far more error-prone than the state->view, declarative model of React. It’s ugliness is more than skin deep.

I agree entirely, except for the necessarily ugly part.

You can use intercooler.js to wire in very usable modern UX with very little overhead, relying on the native, screaming fast DOM implementation.

I'd argue most of the modern frameworks with all the bells and whistles (Redux, Hooks, ...) are even more ugly, and actually harder to master.

https://medium.com/re-dom/master-the-dom-bc1a2a06089b

A SPA is predictive of a web application that has substantial performance, UX, and accessibility issues. A high schooler can build a page with some simple HTML and some jQuery sprinkled in that makes for a substantially more pleasant experience than teams of professional developers regularly manage to do with SPAs. I'm sure there are SPAs that are pleasant and add value above the alternative, but they are clearly very hard to build correctly, as evidenced by how many multi-million dollar SPAs are pieces of shit. It's kind of besides the point whether that's an organizational or engineering failing, because the very fact that SPAs lend themselves to those kinds of failings is an indictment of them.

The fact that very large SPAs are harder to build and maintain and thus easier to mess up isn’t a very compelling argument for the people who have the ambition to build great SPAs. More ambitious projects are easier to mess up, of course.

Before I was a professional developer, I made a really small application using just HTML, CSS and some jQuery: just a site that listed about ten recipes. When you selected the next recipe, it would change the page's background colour, doing a full repaint in the process. It was terribly slow.

As a user of different websites, I have to say. I get extremely annoyed a SPA websites that should be server rendered sites. Over a 3G connection they are extremely slow and annoying. Especially when it should just be a simple page. And I know that it isn't the SPA itself that is the problem, since gmail loads its website extremely fast. I think the issue is poor practices in caching etc. But really, they don't need to worry about all those good practices if they would just render on the back end to begin with. Just give me simple pages with little unnecessary content so I can get on the page, get what I need and be off without having to wait 10 seconds between each page load (and yes, that is with the SPA).

It's elitism against low quality. Webdev inflated dramatically and cuts the costs to absolute minimum, so quality drops severely. It's not only javascript, everything in webdev is low quality, it's not a fundamental trait, it's a real life trait. Turing complete part is just more sensitive to low quality. Flash is what web 2.0 really wants, but has to emulate it with enormous hacks, while having similar security implications, it repeats history.

Browsers already have a full-featured Flash alternative: canvas

Reply on news.ycombinator.com