The problem is that just the theory, reality if often times different.

>Going back to the server for 100kb of HTML and reloading the entire page...

This implies that 1) you don't go "back to the server" to load your bit of JSON. and 2) the JSON loaded doesn't require any extra templates, images or more JSON to be loaded. See the problem? It's all assumptions.

Another thing, what about browser caching? I can see how the next page loads _only_ the html, as all the js, css and images were loaded already. I think you are falling for the exaggerated speed benefits from making a website with a JS framework.

To be clear, I am talking about a web page, an HTML document, static content. Maybe that's where the confusion happens in discussions like this. (I said "sites", not "webapps" in my original comment)

A history lesson, we did this with Flash years ago (no more page refreshes!), and everyone ultimately learned to hate it. Just because the flashy crap is spread over the entire "webapp/site" to every button, mouseover and click doesn't mean it's useful or better. (I think many devs think they need to build basic site features with big frameworks just to "stay modern".) Look at Youtube, it's slower now that they implemented their "webapp" experience, but the page doesn't "refresh", so that is somehow better... (is youtube really a webapp? Or a bunch of pages with videos on them?)

* https://news.ycombinator.com/item?id=16052558

* https://hn.svelte.technology/item/16052558

Bear in mind that HN itself has a huge advantage over HN clones, yet — for me at least, sitting here — the Sapper version is significantly snappier.

Yes, the svelte is generally faster on my phone as well. (I am not sure I see the need for a framework for this specific feature though, it's just a js tabs sort of interface. It doesn't seem like a good argument piece for or against this framework)

I did get a possible error, the pages didn't match up after a while. Is the svelte data was being cached in a way that can't refresh properly? I can't debug this as a normal user, does hitting refresh do anything to reload the site content on the svelte site?

Try this, open both sites in different tabs, and navigate around on them a few times, and after awhile, the news.ycombinator will show new content, and the other one will be different. (I am guessing older content, server cache issue? I didn't compare carefully, maybe they started off different and I didn't notice)

So basically the added complexity gives you the same load time when done extremely well (as Sapper is). In terms of bang for your buck, the service worker is biggest improvement. Which you can implement in your server-rendered app.

Incidentally, 'cheating' is a bit of a silly word to use for a feature designed to improve UX that people spend a lot of time trying to implement (see e.g. http://instantclick.io/)

How fast would it load if every entry had an image? Maybe then it wouldn't seem so different? (edit: this is from a desktop/Firefox)

It's 80% more effort for the 20% last performance/richness points.

it's over, people want/expect these kinds of apps, e.g feels as good as native apps but on the web.

But you're also right some people misuse that kind of technology to a ridiculous extent. Downloading a 3MB angular app just to display a crappy site without any rich interactions is really infuriating but that's just bad engineering and people who make choices based on what's popular, disregarding context.

The difference between streaming 100kb and 10kb is small when compared to the connection latency itself. Even on a low-end LTE connection (5mbps), 100kb is 20ms, whereas the latency of a cross-country (US) transit is realistically ~50-100ms. The difference decreases further when you enable server-side compression and start doing fragment rendering, which tends to remove the penalty for HTML payloads.

The argument for react-like technologies is not connection latency, but rather, the hope that you can avoid synchronous connections in the first place by moving your view logic client-side. And truthfully, few client-side apps are written in a way that would minimize payloads anyway. Most people are doing it because they hate working with the DOM and AJAX and server-side frameworks in a mishmash of web technologies, and perceive these client-side frameworks as easier.

    is a very 2002 way of doing things

I think the question is, who do you write the site for, for others or to satisfy your ego and show off?

This comment is a prime example.

So, when someone says they have a JS framework that replaces the core of the browser's display, the DOM, my response to that is sigh, this again.

Shadow DOM is around the corner, what then?

The reason this stuff gets popular is not because it's a good idea, it's because big companies have tons of cash and man power and can't wait for browsers to get updated. Well, a lot of us code monkey vets are done chasing "shiny crappolla", and we can wait a bit until the dust settles.

How many JS frameworks are there now? I saw all of them come, where is ember, knockout, etc...? Vue just popped up, and I can't even recall the other 5 I tried out at the same time. Which will succeed? When you have to put real money into a project and the framework matters to your clients budget, and your profitability, you can't make a risky bet and expect your client to pay for it later if you are wrong.

I am all for the long term now. Show me how a 1 year old framework is a good investment, I am willing to learn something. (keep in mind React is only about 4.5 years old, Angular is only 15 months old (AngularJS is 7 just years old and already being phased out!))

Nothing changes. DOM remains a slow monstrosity impossible to code for. For goodness sakes, reading certain properties in a DOM tree causes a full page reflow [1]

To beat virtual DOM frameworks you have to write extremely specific vanilla JS+DOM code that basically ends up doing the same thing: re-using DOM nodes, event delegation etc. See [2]

Shadow DOM was never meant to be an answer to that. Honestly, I have no idea what it was supposed to be an answer to.

[1] https://gist.github.com/paulirish/5d52fb081b3570c81e3a

[2] https://medium.com/@localvoid/how-to-win-in-web-framework-be...

React will likely be around longer than/as long as any framework, but whatever replaces it will use a lot of the same concepts.

(edit: this is partly a joke comment, fyi)

"No framework" generally means "poorly-written custom framework". Do you have any code samples to share from your vanilla JS apps?

This thinking is part of the problem: the idea that not-using a framework almost necessarily means you're writing garbage.

>Do you have any code samples to share from your vanilla JS apps?

I can show you bad code from popular frameworks too--in particular, hacks to get around the "magic" that frameworks offer.

And, invariably, we move on from the framework because now there's "something better". And, we say "that's just progress". No one wants to admit that the last framework was just bad.

It's a trend that's been going on for decades in programming, and not just with JS frameworks. Stick around long enough and you'll see exactly how predictable it is.

That is not generally true at all. It might be true if you've got a very inexperienced and unskilled team of developers who don't know how to build a non-trivial application without the structure that a framework brings. However, there must be millions of developers in the world who do have sufficient skill and experience to do that, and these days plenty of those people work in web development. I imagine they can still remember how to do things like basic software design and using libraries, which have been working since long before any of these modern frameworks existed.

Even so, the idea that not using a framework automatically means you'll produce some poor imitation instead is laughable. The history of software development is replete with examples of people succeeding without those frameworks. We've built countless UIs that way that were much bigger and more complicated than anyone has ever built with Angular or whatever this week's flavour of JS framework is.

Maybe there are only thousands of developers working in the web industry who could do it rather than millions. I'm not sure that undermines my real point, since you'd only need a handful of decent devs to make and maintain almost any web front-end I've ever seen.

I suspect the true problem is that for various reasons we lose a lot of that experience and skill from the industry far earlier than we should, and then yet another young generation of developers who haven't studied history are doomed to repeat it, badly.

I like the idea of universal code, maybe Sapper will be the solution that comes out winning. I'll let the community be the judges and hop on the train a year later if that's the case.

Not everything has to be an SPA, but React is 30kb gzipped and Preact et al are in the single digits.

>What's the value of being modern if it makes user experience objectively worse?

The point is they don’t inherently make user experience objectively worse.

>Sure client side render may prevent you from reloading the entire page. And who cares that this rerender actually takes longer than reload?

This isn’t how it works. Rerenders can be incredibly fast.

>Did I really need to waste 200KB of my mobile data to load scripts all I wanted to see were 5 pages each weigthing 5KB? What did I gain from trading full reload for the a-la-SPA kind of deal?

What did you lose? You lost nothing because SSR provided the initial page load as quickly as any other HTML.

It sounds like you’ve generalized the entirety of modern SPA development from your experience of a few terribly developed sites with poor user experience.

You probably only notice the poorly-built SPAs because the UX gets in the way. i.e., confirmation bias.

Ah, but they do. Browsers are very mature and predictable in their management of html pages and SPA's break that behavior in subtle, uncanny-valley ways.

For instance, click into the Sapper HN page https://hn.svelte.technology/item/16052558, scroll down to a post with a random link and click into it. Click on another page in that link. Now click the back button in your browser to get back to the sapper page. You find that you will be at the top of the page as it re-renders. You lose the place you were scrolled to.

This does not happen with standard cached html pages in the browser.

One of the worst offenders is google's home page. When clicking into the links looking for something, clicking back will take you to top, again and again, losing your place. This is a big step back in usability that people are not even aware is happening. It is a small thing individually, but in aggregate it adds up to a large thing.

What browser is that happening in? In Chrome it works correctly — Sapper uses `history.scrollRestoration = 'manual'` for this exact reason, but maybe it fails elsewhere? It's a bug, and we should fix it. (This is pre-1.0 software, your forbearance is appreciated.)

Maybe you are too young to remember Youtube before it was turned into a webapp. It was _considerably_ faster. Todays version requires all sorts of odd refreshing bits and pieces. The old one just loaded right away and showed the video.

If I was paranoid, I'd think that Google did it on purpose to push Youtube Red ads at us.

PS: It downloads that crappy polymer that weights more than 1.5MB... ffs

There are sites that indeed are applications, with lots of updates occurring dynamically on a page: a chat, a dashboard, any type of control interface. They do benefit from the libraries that make highly dynamic things efficient.

There are sites that are best served as static pages. This includes the server component, too, BTW. A static site generator producing plain HTML + CSS is often a good replacement to something like Wordpress.

Some people use latest trending tech for no good reason, just to show off. But the problem here lies not in the tech used.

Computer science programs really need to introduce something like a "History of Computing Ideas" course as a mandatory element. Maybe we can get away from rehashing the same cycle of trends every five years and move onto some different wheels.

Isn't that the whole programme?

In my final year I had a couple of more advanced courses in which we could just about get our heads around results published by the lecturer four years ago when we started the programme. Everything else is just working up to that, from Boole's ideas; through Turing's and von Neumann's.

There is a lot of practical implementation history that people are often woefully ignorant of, and it leads them to tread the same paths over and over and over.

    - Here are the core GNU command line utilities; make, sed, grep, etc.  They are battle-tested, use them, don't rewrite them a dozen times in JavaScript
    - Here is the progression of version control tools that people have used over time, and some reasons why we've moved on from SourceSafe and rcs to Git.
    - Here's the history of how people have done databases, flat-file, vs sql vs nosql
    - etc, etc, etc.

Alan Kay frequently laments the direction of the computer industry, calling computing "not-quite-a-field" and "pop culture". From an interview in 2012:

Quote:

----

> Kay: [...] [I] happen to believe in history. The lack of interest, the disdain for history is what makes computing not-quite-a-field.

> Binstock [interviewer]: You once referred to computing as pop culture.

> Kay: It is. Complete pop culture. I'm not against pop culture. Developed music, for instance, needs a pop culture. [...] The big problem with our culture is that it's being dominated [more by] pop-culture content than it is for high-culture content. I consider jazz to be a developed part of high culture. Anything that's been worked on and developed and you [can] [sic] go to the next couple levels.

[...]

> [Kay continues]: [P]op culture holds a disdain for history. Pop culture is all about identity and feeling like you're participating. It has nothing to do with cooperation, the past or the future — it's living in the present. I think the same is true of most people who write code for money. They have no idea where [their culture came from]. [sic - brackets in original]

---

It's a great summary of the programming fads that have come to characterize tech culture and how disappointing it is for anyone who is trying to navigate this field with some intent and presence of mind higher than fitting in with the crowd or cashing in on a perceived gold rush.

It's also just a great memorialization of the concept of pop culture in general; pop culture is about a feeling of belonging and community, and engaging positive biological responses associated with social approval and community. It's something that people do to give themselves that rush of praise, and then retroactively try to justify. After a couple of years, no one can understand what anyone was thinking because they were just rationalizing riding the tide.

And, IMO, it aptly describes not only the React phenomenon, but also Kubernetes (aka "shared hosting"), Docker (aka "static linking"), etc. Also IMO, big dollar players stoke this negative culture because it's profitable for them.

It's not necessarily that these technologies won't leave their mark, it's just that they're not the revelations people pretend they are.

Regardless, suspicion is always warranted when people insist that the contemporary is novel, in computing or practically anything else.

[0] http://www.drdobbs.com/architecture-and-design/interview-wit... \ archive: https://archive.fo/DkQOc

Moreover, the notion that because FB or whoever went "hmm nothing solves our domain problem, we have the resources to solve it ourselves" that suddenly they solved every domain problem is equally naive. It's likely that people quoting react stacks are solving issues that never existed for them with libraries they don't need.

When was a model like React + Redux (or Elm) used previously, and why did it fail? The combination of factors (browser advances and iteration on existing models) is unlike anything before. This tech stack did not exist in 1999, it did not exist in 2005, and it did not exist in 2012. It is driven by real problems.

What do you mean "a model like React + Redux"?

Programmers have been separating underlying state, rendering and interactions since at least the earliest days of MVC in the '70s.

We've been diffing model states to identify changes to act on for as long as we've had explicit isolated state management, which again is several decades.

We've been identifying specific parts of a display to rerender fully because doing the whole thing was too expensive since the earliest graphical video games.

We've been using markup languages to describe UI layouts declaratively for a long time too.

Adopting similar techniques in browsers was likely as soon as serious front-end coding to build larger client-side web apps became viable, and they have much the same pros and cons now as they did in other UI development before. React and its surrounding ecosystem may have been the first JS libraries to popularise the ideas for a new generation, and IMHO those early versions of React were well done and useful, but let's not pretend the underlying concepts are radical and new in themselves.

But like you said, those are good ideas, they didn't fail.

If it was a good model for building UIs in 1970 and it proved itself then, we should be taking advantage of that on the frontend as well, instead of ignoring it.

That isn't to say some concerns might not have merit, but SEO/SSR/shared routing/state/templates are problems with production-ready OOTB solutions.

If someone isn't familiar with the basic SoTA then they should refrain from commenting so harshly on it.