In fact SPA in general are suppose to work around a single issue, sending a request will lose all your state and reload the whole page(If different content, downlaod whole html). Since most website have multiple routes this is an actual issue. You need to sync state with server for example. I think the solution will be able to say "all this route are the same site" to the browser and now browser can be able to allow delta update or store some variables. This will be perfect with html imports.
Second-Guessing the Modern Web
391–400 of 467 posts
Re: Second-Guessing the Modern Web
#392There was a recent article on having your website be entirely statically regenerated except for a select few components that require interactivity: shopping carts, comments, etc.
That way, your entire site is basically live just on a CDN, infinitely scalable. Even if your API server goes down, only the small subset actively engaging with interactive content would know! With client side persisting technology like service workers, you can pair down which interactive content matters for that.
Really seems like the direction I'd want for my next project. And, again, Svelte and Sapper support exporting static sites... Really I'm continually impressed by their position I'm supporting great patterns out of the box.
Re: Second-Guessing the Modern Web
#393I empathize with the author but client-side technologies like React have a pretty clear advantage that explains why they're popular: for the people that are tasked to make websites (i.e. us, HN readers), they're easier to work with and they save us time. It outweighs all the end-user-facing cons by a lot, because companies need us, and our salaries are expensive. It's true that they are largely more complex than O.G.…
It sounds like excuses companies make when they pollute the or exploit their employees. Solution for them to stop is to level the playing field by law. I think that one day the same will happen with software, and we'll all be sorry.
Re: Second-Guessing the Modern Web
#394You guys should give Svelte a try. It's a breath of fresh air for modern JavaScript. Your codebase becomes much simpler. It's much faster and lighter than React. It doesn't give you absolute flexibility like React + JSX does, but it solves your most common problems much more pragmatically.
what flexibility does it lack compared to React? I've played with Svelte and love it, but I'm cautious that momentum with React is so great.
So far I've only encountered some annoyances, no real deal breakers.
See this for example: https://stackoverflow.com/questions/60934557/how-to-bind-eve...
Re: Second-Guessing the Modern Web
#395Earlier quoted context omitted.
Swelte has exactly the same problems author mentions about React.
Not all of them. Without the overhead of rendering everything to a virtual DOM and then doing a diff, performance can get pretty close to native javascript--the sweet spot the author mentions gets bigger. Plus since the framework is mostly just a compiler, the bundle issue is less of a big deal.
Virtual DOM actually has some efficiency benefits. So it is not as easy as no Vdom = better. Also React, Angular or Ember does not add a lots of code to the project. I am 100% sure real world app written in each of major frameworks including Svelte has almost exactly the same size. Svelte has the same problems like React or any othe framework.
Re: Second-Guessing the Modern Web
#396Earlier quoted context omitted.
Swelte has exactly the same problems author mentions about React.
Obviously Svelte can't do nothing about the misuse of Svelte (which is one the major points of the article) but: > The level of abstraction that React works on is too high, and the cost of using React - in payload, parse time, and so on - is too high for any company to include it as part of an SDK. Svelte is just a simple way for you to write vanilla instructions. There is no runtime and practically no framework. Oth…
Real World application written in Svelte requires a lots more libraries and code to supplement parts Svelte does not provide. So in the end you still have a big chunk of data.
Svelte does not make the problem dissapear. Svelte does not provide a solution. Svelte has exactly the same problem like React.
Re: Second-Guessing the Modern Web
#397Earlier quoted context omitted.
Doing things with react is mutually exclusive with SPAs. You could even do a purely server-rendered website using react on the server if you wanted to, and all the benefits of functional component design can still be utilized.
You probably meant "orthogonal" (a smarter-sounding way of saying "perpendicular", in the sense of "linearly independent"). A framework made and used primarily for doing SPAs can't be "mutually exclusive" with doing SPAs.
Maybe they just wanted to say "isn't"
Re: Second-Guessing the Modern Web
#398Earlier quoted context omitted.
I think the problem/frustration is simply this: there are a lot of web sites out there that are, well, web sites, not web applications. Looking back at the linked article, it goes out of its way to talk about many ways that React is "pretty great" and "for a particular scope of use cases it's the best tool you can find," but then goes on: > There are a lot of problems for which I can't see any concrete benefit to usi…
Serious question: Is this really a problem with web developers? Or is it with product managers who demand SPA like behavior?
I suspect a little of both. Developers do like to play with cool new technologies, and product managers do like to see how spiffy they can make their products.
Having said that, though, I do not think it's a universal truth that all web sites must expand to fill all available functionality, which seems to be implicit in a lot of arguments here and in the highest-rated rebuttal to me.
Re: Second-Guessing the Modern Web
#399Earlier quoted context omitted.
> There is no runtime and practically no framework As a fan of Svelte, I really wish people would stop repeating this. There _is_ a runtime in the form of repeating patterns of code, which are objectively less ideal than the not-so-revolutionary approach of just having a runtime. Newer libraries do have centralized runtimes (e.g. Solid.js) and perform better, so there's no real correlation between "no runtime" and ha…
> There _is_ a runtime in the form of repeating patterns of code Obviously there has to be some running code at the end, and technically you are right, but I think you're splitting hairs and for a brief introduction it makes more sense to say that there is no runtime. Also I think I implied your point with "Svelte is just a simple way for you to write vanilla instructions". > Newer libraries do have centralized runti…
I'm mostly worried about the _optics_ of saying there's no runtime, because if people think "hey Svelte looks cool BUT I'm scared my bundle size will be humongous", then they won't convert. And Svelte sure could use some more adoption to get the adoption snowball going. That's all that it boils down to.
Re: Second-Guessing the Modern Web
#400I empathize with the author but client-side technologies like React have a pretty clear advantage that explains why they're popular: for the people that are tasked to make websites (i.e. us, HN readers), they're easier to work with and they save us time. It outweighs all the end-user-facing cons by a lot, because companies need us, and our salaries are expensive. It's true that they are largely more complex than O.G.…
for the people that are tasked to make websites (i.e. us, HN readers), they're easier to work with and they save us time The premise of the article is that they are not easier to work with and do not save time in most situations. I agree. Most websites are fundamentally documents, even those that think of themselves as apps. You could even build gmail quite easily as a document based app with some limited use of fetc…
Gmail has a HTML app which requires a reload whenever you click stuff and still manages to be faster than the JS app.