141–150 of 168 posts
We've transitioned from Angular to ReactJS with great success. Much smaller learning curve. Using Backbone to handle the models and React for the view is a great combination.
one thing React by itself can do that React+Backbone.Model can't, is handle oddly shaped state. Which is almost all of your state, once your application becomes nontrivial. http://jsfiddle.net/dustingetz/YUCBT/2/
A lot of people seem to think that Single Page App frameworks like Angular/Ember are suitable for use on the public facing client side. I've always believed that SPAs are meant to be behind a login, where you don't have to also deal with spiders and other sub-optimal browsing devices, and you have a little bit more wriggle room when it comes to routing and web history. Just look at Blogger...their client-side renderi…
I agree that things like blogger are a great example of what not to do, but I'd go further and say that treating something as a single page web app running on the client side throws away most of the advantages of the web: URLs which can be stored and shared and are idempotent Mostly stateless operation for anonymous use (fast to serve/load/cache) Document formats that anything (including dumb crawlers and future gadg…
This interface style does not require any visual page refreshes to load new content, but it also still can support routing and deep-linking.
Earlier quoted context omitted.
> URLs which can be stored and shared and are idempotent If you use a decent router, you get shareable idempotent URLs: https://solvers.io/projects/7GTeCKo7rGx5FsGkB > Document formats that anything (including dumb crawlers and future gadgets) can parse and reuse in unexpected ways As in the article, you can use phantomjs to serve up static HTML to crawlers. They are correct in that it does slow you down and add comp…
It's not really a single page application if you are serving separate pages is it? BTW, the page you linked to says 'Uh-oh! Couldn't find that page.' before loading and displaying the content... ouch. One of the things I love about the web is that it uses incredibly simple building blocks like simple html pages at defined stateless URLs, dumb servers and dumber clients, and builds complex systems through their intera…
I'm also not sure that rendering everything client-side is advantageous enough to warrant its current popularity (hype...), but I do see some advantages. Firstly, I think it is a better separation of concerns - the server is in charge of data discovery, persistence, consistency, and aggregation, while the client is in charge of determining how that data can be most useful in the current context. In practice, this means it is possible to have different front-ends for the same back-end. Admittedly, that is certainly not always a necessary or desired feature. The separation also makes it easier to build the front end and back end of an application separately from one another, and possibly even in whichever order you prefer. That can be a good thing, though I don't think it's really taken advantage of very often. I also think that true web applications can be made to feel much snappier and closer to native. The line between what should and shouldn't be considered an "application" is unfortunately blurry (the Blogger example is a good one).
I had the opportunity to work for a million dollar budget client project, about a year ago. (Obviously I'm bound by an NDA, so I won't go into specifics). You can think of this site like an oDesk/Freelancer competitor, but with some social features. We also had another team from California working on this project, who consistently insisted that we go with Angular for a project of such complexity. Back then, on HN, ev…
That said, I still go knockout for this sort of thing most of the time because their support for legacy browsers wins out, and in the industries I do work for old versions of IE are sadly common.
All these arguments seem like lowly excuses to not do proper work and instead blame the framework you are using. If you have any kind of interactiveness the feel of a fat client is so much better then template rendering. Look at the site: https://sourcegraph.com/github.com/tomchristie/django-rest-f... ? Is that the best interface you can get? In 2014 everything I click reloads the page? a tabbed interface that doesn'…
Is anyone aware of a solution to allow clients to validate a version of an SPA website (cryptographically), in the sense that once downloaded a signature is checked and then further visit, if they require an update, have to be validated and verified by the user?
I'm thinking of a way to allow user to trust their applications in the same way you would trust a dist-upgrade on Debian via the packager's PGP signature and chain of trust.
This would solve the current problem that sites can change user side code at will anytime without them knowing and thus making it quite impossible to develop proper security solutions where the user actually owns and is responsible for his own security.
With such a solution in place, we might start seeing proper p2p/webrtc security related apps, we could even imagine an in Browser (read js) Tor-like service...
Earlier quoted context omitted.
To answer that question -- for the same reason you'd prefer mobile apps on a smartphone. Even in resource-constrained hardware, it makes sense to do things client-side if that's less expensive: no need for server communication on some or all of the app, since it can be cached locally. Sometimes your app can be more expressive than a sequential history of documents loaded one page at a time. Now, do people really thin…
That said, I'll ignore my point above and get a bit technical here: Unless you're using Opera Mini, client-side rendering is indeed all we have for "textual document model rendering". Semantic nitpicking. It's obvious that the grandparent speaks about templating, which can be done both on client and server side. Honestly, I'm really tired of people who pretend there is no difference between serving up HTML and servin…