4 ms·

I used to feel that way, then I met a one javascript developer in particular who really made me see it differently. I won't get into those here, I just want to

I used to feel that way, then I met a one javascript developer in particular who really made me see it differently. I won't get into those here, I just want to tone down the "probably don't need" into a "don't necessarily need". As a predominant back end developer, I do feel that the complaints from the article are due to inexperience or misunderstanding: 1. stateless requests: You don't have to cache any state by default, just like server side. You start caching to improve performance and caching is always one of the big 2 problems of computer science. Don't cache if you don't have to: stateless has benefits. 2. Reinvent browser features: use your framework! This is a solved problem. I am not sure what the Angular or React solutions are but with vue just use the vue router. 3. More mature tools: backend suffers from this as well, I know a lot of mid level software engineers that are always chasing the latest fads. Microservices, containers, serverless, etc. The biggest issue I had when I tried to do serious frontend development is just not being aware of the tooling and how it works. 4. SEO: Google can crawl your webapp: https://searchengineland.com/tested-googlebot-crawls-javascript-heres-learned-220157 https://searchengineland.com/tested-googlebot-crawls-javascr..., I would prefer if the person making the claim (that an SPA does not get crawled) would be the one providing the evidence... Don't get me wrong though. Sometimes an SPA is the wrong choice but it would be hard for me to say if that is usually, rarely or a toss up. I think many places that go from server-side rendered to client-side rendered SPAs do not hire a bunch of front end experts when they do so. Then people experience a bunch of problems because of the fact I point out in 3: lack of awareness of the ecosystem. On the other hand, there sure are a lot of diva developers who don't like working with old technology (for example, PHP), and this probably causes a lot of the front end framework churn. Just like picking up a new language, it takes time to produce idiomatic code. Of course, for a new framework it takes time for the idioms to develop...

devmunchies 8y ago
Google isn't the only search engine. But even if that is the only one you care about, Google said themselves in last years IO conference that it takes them several more days to index a client rendered interface, since they have to send it to a rendering queue, and the line is really long. Here is the talk: https://www.youtube.com/watch?v=PFwUbgvpdaQ https://www.youtube.com/watch?v=PFwUbgvpdaQ
crooked-v 8y ago
> I am not sure what the Angular or React solutions are but with vue just use the vue router. For React there's a couple, but most of them boil down to the same basic idea that you've got switch statements that decide which components to render based on router state (rather than there being anything "special" about routing entry points), and then something like a <Link> component that just acts like an <a> tag but triggers the client routing change instead.
- ThePhysicist 8y ago
  I used react-router before but absolutely hated how it mixes presentational logic with URL matching. For new projects I just use a small routing helper that’s written using React context and that performs URL matching the old fashioned way (a list of pattern with parameters that are routed to specific components). Works really well on all modern browsers and is less than 200 lines of code. It even allows for reverse routing (use a view name and parameters to generate a URL) which to my knowledge isn’t implemented in react-router.
  - crooked-v 8y ago
    > I used react-router before but absolutely hated how it mixes presentational logic with URL matching. You may like redux-first-router, which has the URL literals as part of a routemap attached to the Redux store, and then has all routing in the app actually just be the dispatching of Redux actions. Your navigational components then end up with stuff like: <Link to={{ type: THAT_PAGE_WITH_THE_STUFF }}>Link text here</Link> ...where the Link is actually just a convenience helper component wrapping <a> that dispatches the action and provides a browser-friendly href reverse-engineered from the routemap if possible.
WA 8y ago
Regarding 3: The Browser does a bit more than routing and no framework (as far as I know) handles these simple cases by default: - Timeout error / no network connection - Ability to stop requests - Show that the browser is sending a request
- BlackFly 8y ago
  Those are excellent points to consider. Also, in the favor of SPA's you can consider the horrible state of repeating post requests when users press the back button on server rendered multi-stage forms (like purchasing a flight ticket). Of course, you can just avoid implementing multi-stage forms via POSTs like this and I wish airlines would stop. If you implement your SPA with a service worker and use cacheable GET's properly, your SPA can work offline and survive temporary network glitches (like on a train) in a way that server rendered apps never can.

devmunchies 8y ago

Google isn't the only search engine. But even if that is the only one you care about, Google said themselves in last years IO conference that it takes them several more days to index a client rendered interface, since they have to send it to a rendering queue, and the line is really long. Here is the talk: https://www.youtube.com/watch?v=PFwUbgvpdaQ https://www.youtube.com/watch?v=PFwUbgvpdaQ

crooked-v 8y ago

> I am not sure what the Angular or React solutions are but with vue just use the vue router. For React there's a couple, but most of them boil down to the same basic idea that you've got switch statements that decide which components to render based on router state (rather than there being anything "special" about routing entry points), and then something like a <Link> component that just acts like an <a> tag but triggers the client routing change instead.

ThePhysicist 8y ago
I used react-router before but absolutely hated how it mixes presentational logic with URL matching. For new projects I just use a small routing helper that’s written using React context and that performs URL matching the old fashioned way (a list of pattern with parameters that are routed to specific components). Works really well on all modern browsers and is less than 200 lines of code. It even allows for reverse routing (use a view name and parameters to generate a URL) which to my knowledge isn’t implemented in react-router.
- crooked-v 8y ago
  > I used react-router before but absolutely hated how it mixes presentational logic with URL matching. You may like redux-first-router, which has the URL literals as part of a routemap attached to the Redux store, and then has all routing in the app actually just be the dispatching of Redux actions. Your navigational components then end up with stuff like: <Link to={{ type: THAT_PAGE_WITH_THE_STUFF }}>Link text here</Link> ...where the Link is actually just a convenience helper component wrapping <a> that dispatches the action and provides a browser-friendly href reverse-engineered from the routemap if possible.

WA 8y ago

Regarding 3: The Browser does a bit more than routing and no framework (as far as I know) handles these simple cases by default: - Timeout error / no network connection - Ability to stop requests - Show that the browser is sending a request

BlackFly 8y ago
Those are excellent points to consider. Also, in the favor of SPA's you can consider the horrible state of repeating post requests when users press the back button on server rendered multi-stage forms (like purchasing a flight ticket). Of course, you can just avoid implementing multi-stage forms via POSTs like this and I wish airlines would stop. If you implement your SPA with a service worker and use cacheable GET's properly, your SPA can work offline and survive temporary network glitches (like on a train) in a way that server rendered apps never can.