When you need an SPA it’s great. JQuery noodles are a past time and I’m not going back. If you need a blog or something just render it all sever-side and sprinkle some JS.
Single Page Application Is Not a Silver Bullet
71–80 of 111 posts
Re: Single Page Application Is Not a Silver Bullet
#72When you need an SPA it’s great. JQuery noodles are a past time and I’m not going back. If you need a blog or something just render it all sever-side and sprinkle some JS.
> JQuery noodles are a past time and I’m not going back
I love me some jQuery noodles! For some sites it becomes unwieldy i'll agree, but when sprinkled it provides a lot of enhancement.
Re: Single Page Application Is Not a Silver Bullet
#73Some of the arguments the author mentions are not really good arguments. Basically it boils down to how much you care about the user experience. I designed and developed a SPA for a large real-estate portal in - Initial request is rendered server-side, so TTI is extremely low. Even if the JS hasn't kicked in, the website is already usable. - Back button works perfectly fine. We use the HTML5 `history.pushState` metho…
Do you mind telling which stack you're using?
Re: Single Page Application Is Not a Silver Bullet
#74I have mixed feelings about SPAs. I'm mostly a back end developer but do have some front end experience. On one hand, I think life is a lot simpler with server side rendering. On the other hand, I like the purity of REST APIs and front end rendering.
For technical reasons not worth getting into, on my current project, a SPA would be overkill and hard to implement. But I did take the lessons I learned from my time with Angular to create a poor man's model view framework with a combination of HandlebarsJS+JQuery.
After my experience doing it, I understand why a framework would be better. I'm reinventing the wheel (out of necessity), it wouldn't scale to multiple developers without becoming an ungodly mess without a framework to keep people on the rails and it would be harder to ramp people up. When I got thrust into my first Angular project it was easy just to read a few articles and watch some PluralSight videos.
As the dev lead, I will definitely choose a SPA framework when my next front end project comes up. For all of the reasons above and because it's easier to recruit and retain people when you're doing the new and shiny that can add to someone's resume - including mine.
It doesn't matter how I feel about the most popular frameworks, if I want to be employable, I need to keep up to date.
Re: Single Page Application Is Not a Silver Bullet
#75We built one of our products as an SPA ( https://usebx.com/app ). I have to say it was a fairly enjoyable experience, and our users like it too (they often add it to their home screen and comment that it feels totally native). The only annoying thing was ios Safari, which has it's own little quirks in certain areas (but those are not limited to just SPAs but any kind of website).
That's a very cool app. I gave it a try when you first posted it on HN and now I'm a regular user! I find it much better than similar native apps, especially because of the offline mode (most invoicing apps seem to lack this). Anyway, thank you for the free tier - works a treat for my needs!
Re: Single Page Application Is Not a Silver Bullet
#76As an avid developer of SPAs (currently working on one for my own blog frontend) I'd say a lot if this stems from people being convinced SPAs 1) provide a faster development cycle, 2) they believe that they've offloaded all need for optimization on the framework they use and 3) "serious" development teams build SPAs. Anecdotally I find SPAs, while I'm more comfortable developing them, will take longer to build. You n…
Not sure many people think SPAs provide a faster development cycle, individual pages are always going to be more simple. You'll get code reuse but that's trivial to get working elsewhere, you just save on redownloading shared code.
Missing out of this conversation is the operational side. Moving beyond localhost, analytics, seo, content mgmt that create a whole different set of challenges vs non-spa.
Likes others have mentioned, it's about the UX that you want to provide that dictates the SPA path.
Re: Single Page Application Is Not a Silver Bullet
#77Earlier quoted context omitted.
And all of that work is already done for you in all modern major SPA frameworks.
Server side too? Client side routing? Have you seen the huge chapter dedicated to routing for angular? You make it sound like it's no work
> Server side too?
Yes
> Client side routing? Have you seen the huge chapter dedicated to routing for angular? You make it sound like it's no work
Haven't seen angular's, they were late to the SSR party.
Re: Single Page Application Is Not a Silver Bullet
#78For the problem of bundle size, it saddens me that Google's Closure Compiler (specifically the advanced mode) hasn't gained much traction. This provides fine-grained tree-shaking to minimize the bundle size. But this requires static analysis of the whole program, which is at odds with the dynamism of JavaScript. Maybe now that static typing is coming back into fashion, the Closure Compiler or something like it will g…
There's a number of projects out there working to reuse closure compiler bits on top of typescript. e.g. https://github.com/angular/tsickle
Re: Single Page Application Is Not a Silver Bullet
#79Earlier quoted context omitted.
And all of that work is already done for you in all modern major SPA frameworks.
Server side too? Client side routing? Have you seen the huge chapter dedicated to routing for angular? You make it sound like it's no work
Server side is as simple as taking /app/* and having it hit your SPA
Re: Single Page Application Is Not a Silver Bullet
#80Earlier quoted context omitted.
The point is that browsers already have built-in code to interact with links and such in a predictable and straightforward manner, and your suggestion that "a lack of basic engineering practices", implying all SPAs need to reimplement that functionality, shows just how absurd the situation is.
There's nothing to reimplement. Browsers navigate based on URLs, so if the URL for a page in an SPA isn't enough to load the full state on a fresh pageview, then it won't work. So it's absolutely about proper engineering to make sure pages have working direct URLs rather than just relying on other navigation while the app is already open.
Sure there’s something to reimplement. Ensuring that changes to the view state are represented in the URL bar isn’t trivial. Should a popup dialog be reflected in the URL state? Should a confirmation prompt? What about browsing a hierarchy of menus?
With web pages as documents that only use JavaScript to “decorate” things, you get this for free. And it’s likely aligned with what users expect.