I am trying to get my head around Next.js and the docs talk about a range of data fetching methods. They suggest static generation is ideal for a simple blog, with benefits over client-side rendering and server-side rendering. I was wondering how to add a comments section to a blog. I would like to hear the thoughts of those more familiar with Next.js.
Could a blog post still be rendered statically and then a comments section component within the page fetches comments data on the client-side or server-side at the time the page is requested? Or would the whole page (post+comments) have to be rendered using either the server-side or client-side rendering strategy?
Related
At the moment we have a solution which is Web forms ASP.Net 4.0. We do a number of things such as using web methods and services either calling them using the standard web forms way or sometimes to reduce the footprint directly calling them with jQuery ajax posts and gets.
We are looking to improve the way we work but we have heavy constricts regarding how the solution is at the moment and not being able to completely rewrite it.
Updating the page using Ajaxs for data, forms and for example pulling "the next 20" items and displaying them on the page it what I would like to heavily stream line.
Using template's due as PURE and jQuery Templates is fantastic way to produce fast calls back and forth between the servers but results in having two copies of the html. (the template for the jQuery and the code in the actual first render of the page)
We have thought about possible producing a empty template and then always populating it via json data we post down to the server but I feel this isn't how things should be done...
can anyone reckoned the best way we can do this without having two copies of our 'template' (e.g. a row of a table)
You mean you have a template in asp and the same template in javascript, but you'd rather just have 1 or the other?
I think that is really subjective. It is always different based on use case. That being said I'd do it by modifying my views and templates. My views (non-js) would simply have containers for that dynamic content. In other words I'd never load the dynamic portions of content into the views initially. Rather, on page load I would simply load up the template and the json that fills it in.
If you think about it that's 2 more requests, but it makes your life easier. The user also is able to see something on the page sooner.
This is one of those questions that really depends on what you are doing. There are trade-offs to be analyzed with every solution.
Using ASP.NET MVC: I am caught in the middle between rendering my views on the server vs in the client (say jquery templates). I do not like the idea of mixing the two as I hear some people say. For example, some have said they will render the initial page (say a list of a bunch of comments) server side, and then when a new comment is added they use client side templating. The requirement to have the same rendering logic in two different areas of your code makes me wonder how people convince themselves it is worth it.
What are the reasons you use to decide which to use where?
How does your argument change when using ASP.NET Web Forms?
One reason that people do that is because they want their sites to get indexed by search engines but also want to have the best user experience, so are writing client code for that. You have to decide what makes sense given the constraints and goals you have. Unfortunately, what makes the most business sense won't always seem to make the most sense from a technical perspective.
One advantage to server-side rendering is that your clients don't have to use javascript in order for your pages to be functional. If you're relying on JQuery templates, you pretty much have to assume that your page won't have any content when rendered without javascript. For some people this is important.
As you say, I would prefer not to use the same rendering logic twice, since you run the risk of letting it get out of sync.
I generally prefer to just leverage partial views to generate most content server-side. Pages with straight HTML tend to render a bit faster than pages that have to be "built" after they've loaded, making the initial load a little speedier.
We've developed an event-based AJAX architecture for our application which allows us to generate a piece of content in response to the result of an action, and essentially send back any number of commands to the client-side code to say "Use the results of this rendered partial view to replace the element with ID 'X'", or "Open a new modal popup dialog with this as the content." This is beneficial because the server-side code can have a lot more control over the results of an AJAX request, without having to write client-side code to handle every contingency for every action.
On the other hand, putting the server in control like this means that the request has to return before the client-side knows what to do. If your view rendering was largely client-based, you could make something "happen" in the UI (like inserting the new comment where it goes) immediately, thereby improving the "perceived speed" of your site. Also, the internet connection is generally the real speed bottleneck of most websites, so just having less data (JSON) to send over the wire can often make things more speedy. So for elements that I want to respond very smoothly to user interaction, I often use client-side rendering.
In the past, search-engine optimization was a big issue here as well, as Jarrett Widman says. But my understanding is that most modern search engines are smart enough to evaluate the initial javascript for pages they visit, and figure out what the page would actually look like after it loads. Google even recommends the use of the "shebang" in your URLs to help them know how to index pages that are dynamically loaded by AJAX.
I've built a full ajax site using jQuery and asp.net. All database data are loaded dynamically via client-side ajax calls. There are no html forms or postbacks, just ajax calls to a web service returning (xml) data.
Now, I need to make the site SEO friendly with emphasis to google. What is the least time expensive way to do it? Is there a way jQuery or asp.net can help me with out-of-the-box solutions/components etc? On the other hand, there is the google specification but is it standard or easy to implement in my case?
Any help or ideas much appreciated.
your question is kinda unspecific.
jquery is javascript - based on how it's implemented can be very bad for SEO
asp.net is server side - can be anything, what counts is the HTML you have on page.
for a start i would recommend googling your site, then click on the "cached" link below it, then "text only version" ... this is what google sees. if you can makes sense of it, then google can make sense of it. if there is nothing there (possible for a very very ajaxy site) then well you are in trouble. then go to your competitiors site and do the same. if he is doing a better job look at his HTML sourcecode and think about ways you can get in this direction.
you would maybe also like to take a look at http://code.google.com/web/ajaxcrawling/docs/getting-started.html
you must have seen widgets like code which people place inside their HTML and it starts showing a small widget in there, how we can we do it in ASP.net, for example if i want to show some specific data of my site to anywhere some specific code is placed, how can i generate that embeddable code that can start showing my specific block of data to anywhere from any site?
Here are a few methods used by various people to embed a snippet of content on an external website.
1) An iframe!
iframe's can be a right old pest, but are quite good at displaying a bit of external content. They have been added back into the HTML standards in the HTML 5 draft specification, so you should get futureproof support for them in the future.
<iframe src="http://www.widget-address.com/Widgets/SomeWidget/" title="Some Widget"></iframe>
You can style your iframe (give it a width and height) and all that jazz.
2) External Image
This is largely used by advertising engines. You pop an image on the page and the image is dynamically created to display some advert - each time it appears it is different. This isn't great if you want information to be screen-readable (i.e. accessible).
<img src="http://www.widget-addrees.com/Widgets/SomeWidget.jpg" alt="Some Widget">
3) Server Side API
You could make an API available so people can call a "service" on your site that supplies them with the information for the widget. For example, their ASP.NET code or PHP code (or whatever language) calls http://www.widget-address.com/Widgets/WidgetService/ and it returns some data that they can format and display on their page. This would give you the benefit of inline HTML, which is the most accessible and valid way of displaying the data.
There are lots of other methods, so if you don't fancy one of these, I'm sure more suggestions will flood in - including (be careful...) JavaScript / AJAX.
I'm not quite sure I understand the question, so I'm sorry if I'm way off here. But I guess you are using the webforms framework for asp.net? If you are there is something called server controls. Those can be used to create widgets like calenders for example (that is already included in the framework, so no need to build it again).
If you are looking for code block, similar to <?php [[code]] ?> in php (if you have used that), then the answer is <% %>. Those are code blocks in the .net world. If you want to write something out you use Response.Write("string to write"); inside the code block. Or you can use the faster way: <%="string to write"%> that will render the same think (string to write).
If you are using the webforms framework you can also take advantage of the built in server controls in the framework. You can read more about the framework here or simply google asp.net webforms.
There are implementations for history.back in Micrososft AJAX and jQuery (http://www.asual.com/jquery/address/).
I already have jQuery and asp.net ajax included in my project but I am not sure which implementation of history.back is better.
Better for me is:
Already used by some large projects
Wide browser support
Easy to implement
Little footprint
Does anybody know which one is better?
EDIT:
Another jquery plugin is http://plugins.jquery.com/project/history It is recommmended in the book JQuery Cookbook. This one worked well so far.
One alternative to jQuery Address is the nice jQuery history plugin. There are also URL Utils.
Reference: AJAX History and Bookmarks.
If you are building an ASP.NET application then using ASP.NET Ajax Framework gives you many advantages and a nice-simple API to use server-side.
Below you can find an example that uses Browser History with ASP.NET Ajax
Create a Facebook-like AJAX image gallery
Both have a wide range support in browsers.
For me is easier to integrate Microsoft AJAX Framework in an ASP.NET page so again if you have an .aspx page it might be easier to work with ASP.NET AJAX
If you don't need exactly AJAX, i.e. updating only parts of the site on request is sufficient for you, then you can use invisible iframe as target for loading generated HTML file containing only JS script that updates/resets "updateable" parts of the site. This is cross-browser solution and doesn't need address polling.
Example, but not in ASP: kociszkowo.pl (Polish site)
When you click there in the section icon and your browser supports javascript, link is modified before being fetched - target is changed to iframe and href is suffixed with .dhtml to inform server, that we're interested in a special version of the page. If you press Back in your js-equipped browser, then previously fetched iframe page is loaded from the cache. Simple, but requires some decisions at architectural level.
This link modification is irrelevant here, it's just the result of combining JS/non-JS world.
In my experience, your best bet is using the same one that you have doing most (if not all) of your ajax calls. For instance, if you're using asp:UpdatePanel's, use the MS one - if you're using jQuery.ajax, use the jQuery history plugin. If you're doing a mix (which I've tried to avoid in my projects), I'd personally test with both and see which behaves better - if they both test fine, then it's a bit of preference. Some may argue the Microsoft one would have better support, but jQuery's history plugin may get more use and more mature.
http://msdn.microsoft.com/en-us/library/system.web.ui.updatepanel.aspx
http://docs.jquery.com/Ajax/jQuery.ajax#options