101–110 of 168 posts
Earlier quoted context omitted.
"node.js + express + jade" is a fairly common stack, you can even try to move an existing complex angular.js code there because it's written in the same language
Is node really a good choice for static non-real time sites? I'm thinking something like Django or Ruby on Rails is better.
Earlier quoted context omitted.
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'd be very wary of solutions that drop those advantages." They are called native applications. I can think of some useful ones over the years, particularly for people who produce rather than consume. I notice that my Bosch drill isn't available for seo and mashing :) Seriously though, it depends on your perspective. What's wrong with saying I'd like to make a native app but use the web as a delivery/installation m…
I suspect the concept of native APIs (desktop or mobile) will eventually disappear, but it'll be an interesting journey if we ever do reach that point and would take decades.
Earlier quoted context omitted.
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…
> 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…
I need to stop clicking on the "why we left x for y" articles on HN. Mostly people have picked the wrong tool for the particular job and the articles are just an embarrassment. Obviously SPAs take a lot of extra work to make search engine friendly and are probably going to be the wrong tool for the job for any site which requires that. Much of the web isn't searchable and doesn't want to be searchable. If you are wri…
Most articles are so optimistic (because it is new, cool, make fun), that is hard to understand if the "tool" is the right one or not, you see it when you use it.
So i am glad to see when people / companies write about their expierence with the "new" technologies. Everybody can then verify if the tool is the right tool for a project/problem or not.
E. g. you write "If you are writing a web app to solve some business problem which sits behind a login angular really isn't a problem". When somebody read this, this person thinks "cool, angular is the right tool for a login backend application".
This is really a case of picking the wrong tool for the job. __This is in no way a slight of the author__...b/c I have done worse on more than one occasion, so thanks for sharing. To anyone reading, you really should understand your workload before picking tools. And, you need to understand the difference between Web Application vs. Web Site: Which are you building? Server-side rending is the winner for content sites…
> "Client-side rending (such as Angular/Backbone/etc) really shine when you need a web application (not web site)." This, 1000x over. I have static landing pages and about pages for search engines, but the app itself is a single page Angular app. The data does not have to be indexed.
Though Google is cheating here, of course. They use plenty of JS frameworks to serve content, yet those Google+ posts do show up in my search results. Though every G+ post does have its own URL, so I guess that's the way to do it.
just a case of using the right tools for the right job...move along
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…
Here's a link with all the nginx config you need to make it work: https://phantomjscloud.com/site/docs.html#advanced_seo
Earlier quoted context omitted.
What would you use for a public facing application?
I recommend PJAX. It degrades gracefully for search engine indexing.
We added PJAX rendering to a Django site in under an hour. All the benefits of SPA's and few of the downsides.
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, everybody was writing about how awesome Angular is, and how you must use it for your next project and so on. It reminded me of the early MongoDB days here.
I was under constant pressure from my client too, since he was also reading a lot about Angular everywhere and the Californian company had him almost brainwashed in favor of angular. After already falling trap for the MongoDB buzz (I used MongoDB for the wrong use-case and suffered the consequences), I decided to carefully evaluate the decision to go with Angular for the project.
After about 6 months of using Angular for a different medium-scale project, I decided against it for my client. I realized that Angular is the all powerful Battle Tank. It can do everything you want it to. But it's very tempting to choose a battle tank when all you need is a sedan to get you from home to office.
Angular has it's own use-cases, but for the most part what I observed was that you could get a lot of mileage without using Angular, with just plain Jquery+Knockout (or any other similar framework of your choice) for most of the front-end.
In a simple calculation that I made (to pitch to my client), I estimated about easily 25% of time (and thus money) savings by not going with Angular for our project. (YMMV)
Usually I tend not to open my mouth about/against angular here because most HNers seem to like Angular a lot and they downvote without a reason just for having a different opinion. But, I am really glad someone wrote a blog post about this.