A programmer I know has a website that is fully Standards Compliant. It uses Unicode-encoded fully-validated XHTML 1.1 with CSS. The pages are frames-free, table-free and JavaScript-free.
He would like to be directed to a blogging tool that does not demand any particular database system or web server, but does create static pages that comply with the above standards and best practices and is itself a professionally finished native Windows application.
...and it should be able to produce an RSS feed as well.
Is there anything out there that comes close to this?
I've never heard of a standalone professional-quality Windows application that acts as a blog HTTP server. I think your best bet is something like WordPress with a good, standards-compliant theme (they exist) and some kind of blog-updating tool (I know they exist, and WordPress supports them, though I have only used a Linux one).
It may be worth investigating MetaWeblog for the Windows app portion, if you decide a single, stand-alone program doesn't exist that meets your requirements.
I wonder why you wouldn't want it to use a database, I can't think of any blogging engine that doesn't use one. It prevents you from having to change all your static files if you replace one thing in your template for example.
WordPress is probably the easiest to set up and integrates nicely with desktop Windows clients such as Windows Live Writer (http://windowslivewriter.spaces.live.com/)
Related
What is the architecture difference between working with razor vs blazor?
Documentation suggest that I have to write an Web Api when using blazor - is it still possible to pass model objects like in traditional razor ?
0 Video with visual explanation
I decided to make a video, since several questions about Blazor were asked (also on other forums) and this format seems much better for me to visualize the differences - instead of reding my (longer) explanation. The video contains a bit improved version, compared to my first post (the text post is also updated) It's one of my first videos in this format, so any feedback is welcome. If you prefer to read a classic text without much visualization, you'll find it's content in the following sections. Of course without the demos, which I made to lighten the content up, but the basic information content is the same.
1. What is a traditional multi-page site or application?
First you need to have a basic understanding how traditional websites/apps works: For every call/request, you send a request to the server and the server responds with the complete HTML of the entire page. This can be dynamically generated like with ASP.NET Core MVC and Razor templates or Razor Pages or even some other technique like PHP, Java, Python and so on. Let's say you have a list of articles showing a preview.
To illustrate this, let's say you have a list of articles (for example blog posts) showing a preview. When the user clicks on read all, you usually have two ways to realize this in traditional web apps:
Load a page like /view-article?id=123 where the above happens again: Loading the entire HTML DOM of the article page
Using JavaScript to make an Ajax-Request, which loads the desired content from an API like /api/get-article?id=123 and manipulate the DOM to display it at the desired position
Without JavaScript, traditional sites are not interactive. This means: After the page is loaded and rendered, nothing happens any more – except the user load another page (with the entire DOM) by clicking on a link – for that reason, it’s called „multi-page“ application.
You'll propably prefer the second approach, cause it's faster and saves ressources: Instead of rendering the entire page again (where only a part of it has changed), you stay on that page and just load the new information you need (the article content in this example). Especially on large pages with many ressources to load and render, the JavaScript approach feels much faster to the user.
If you like traditional pages to be interactive, you need JavaScript. For example you can add an ajax call to some API that displays some data when the user clicks a button, without having to reload the entire page.
In short we can say, that most of the work happens here on the server side.
2. Where is the difference to single-page applications (SPA)?
SPAs have just a single page, in terms of a full rendered html page. If you navigate there like by clicking on article, they load a JavaScript application. It handles everything interactive there. If the user clicks on an article, there is NO complete HTML document fetched from the server! Instead, it only fetches the parts who are changed, in this case the article. Everything else (e.g. navigation bar, footer, widgets etc) will remain - in opposite th multi-page apps, where this may be reloaded if no js/ajax is used.
You often have modulary components there and two-way data binding. This means, a variable is linked to some HTML element. When the variable changes, the element automatically displays the new value. In traditional apps, you'd have to create event handlers manually to handle this. It can be seen as continued development of a single page application with vanilla JavaScript, where you need more manual work to archive things like data-binding.
For the user, a SPA normally is much faster than navigating through pages on multi-page apps.
In short we can say, that most of the work happens here on the client side in the browser of the user. The server just serves static stuff (html, js, css) and provides APIs for e.g. fetching entries from the DB or save them.
3. What has Blazor to do with that?
A Blazor app actually is a SPA. But the main difference to other frameworks is, that Blazor lets you control both the client and server side with C# code. To show that benefit, let's look at other SPA frameworks like Angular: You can build an Angular SPA with ASP.NET Core. In this case, you write your client side in Angular with TypeScript. If you need to access data, it will make API calls to the ASP.NET Core server, which is C#. It will be similar with other frameworks like React, but here with JavaScript instead of TypeScript.
This make it hard to share code between those two: If you have an article model, it needs to be defined in C# on the server and in TypeScript on the client as well. With Blazor you just define it once in C# and re-use it on both sites. In other words: You just write C# without having to care about JavaScript*
*That’s the basic idea behind Blazor: Use C# everywhere, without the need for JavaScript as second technology. But it’s worth mentioning that you need to work with Blazor components to accomplish this. If you need some library not being ported to Blazor yet, you still have to handle a bit of JS. However, there are still benefits like the data binding. Using it on an entire plain JS stack would be some work, so I’d recommend to start with an UI library that offers Blazor components.
3.1 Blazor WebAssembly and Blazor Server
Now you know the basics and you need to decide between two flavours:
Blazor WebAssembly
As the name suggests, it basically uses WebAssembly to run your C# browser directly in the browser. It requires a relatively recent Browser and is not yet supported on all platforms/browsers. Also major engines like Chromium or Safari doesn't support all standardized features yet.
Let's say you have a button with C# code as handler like this:
<button class="btn btn-primary" #onclick="IncrementCount">Click me</button>
IncrementCount is a C# method. The code got transfered to the client and would be executed in the browser. Imagine it as .NET Core runtime inside the browser, like Silverlight BUT without any external plugins. There is no need to even have ASP.NET Core on the server-side! It can be served from any webserver, as long as you don't need things like DBs from the server side. This makes the app larger (and slower, at least on the first load).
The example Visual Studio template has a size of more than 17 Megabyte! With compression this can be reduced to 7 Megabyte – still a lot for a hello world application. By publishing the application in release mode, this goes down to about 7 MB and 2.4 MB with gzip.
At least subsequent requests are faster. Those DLL files are stored in the browser cache, which avoids further requests.
But it can be used offline (at least the main logic without API calls). For that reason, it's sometimes called real SPA – it’s compareable to Angular, React and other client-side frameworks.
Because of the WebAssembly-Usage, Debugging can be harder here, currently it just support Chromium based browsers.
Don’t know WebAssembly? It’s a relatively new, open standard that generates bytecode to improve loading and execution time to realize more powerfull web-applications – independent of the language. You’re not forced to use specific languages like JavaScript: Since Bytecode is generated, also other languages like C++ or Rust can be used.
In a nutshell, WebAssembly can be seen as next generation JavaScript for feature-rich webapps, where Blazor WebAssembly is the C# implementation. Because of the browser runtime, there are some APIs which can’t be used here. For example sockets or I/O access, like File.Open or File.Write.
Blazor Server
The app runs on the server and just transfers the output (like the result of a click event, that increases some counter in another HTML element) to the browser using SignalR Websockets. This makes the app smaller and faster, but requires more ressources on the server-side cause you have a SignalR connection and it's virtual DOM also on your server - making it harder to scale in large setups.
On the other side, this reduces the requirements on the clients: They don't need to support WASM, so it could run on older browsers or browsers with restricted WASM support as well as low-end devices. But since every action ends in a SignalR call, the app won't work offline - if this is a requirement, choose Blazor WebAssembly over Blazor Server.
What to choose?
It depends on your needs, as pointed out above. For example, if you need offline support, Blazor server wouldn't be a good choice. If you're unsure I'd prefer Blazor Server and only really worry about this if you're planning to deploy a very large application.
Imho, Blazor server is currently smoother and more flexible. Blazor Server also got stable before WebAssembly. This recommendation may changes in the future, when WebAssembly has developed further and got more widely supported.
But in this case, you can migrate later!
Both Blazor WebAssembly and Server use Razor components. This means: You can change between both, without re-writing your entire code. Some migration work is only required for things like data-calls outside the browser when migrating from Blazor Server to Blazor WebAssembly. The reason is, that Blazor WASM runs entirely in the browser, so you need a server part like an ASP.NET Core API projekt to handle them.
Further information
I recommend the Introduction to ASP.NET Core Blazor in the official documentation. Also the other chapter describing a lot of information about the platform and offers tutorials. They go deepter in detail to topics like data binding or event-handling to just name a few, and illustrating them with examples. I tried to kept it shorter here for a basic overview.
See also: Blazor WebAssembly 3.2.0 and ASP.NET Core 5
Instead of using server side MVC like Ruby, Python, PHP to build very complex websites, why should not we split our website into multiple modules, and build each with client side MVC like backboneJS, EmberJS. In this case, we will use PHP / Ruby for creating webservices alone, which will serve data only.
Each module now act as small web app. If we link each other, they will perfectly look like a complex web app.
I visit many websites (like github, groupon, stackoverflow etc...) and they can be built or adopted to this approach. But i am not seeing this kind of approach. Does this approach has any problem on this kind of websites?
Was to long for a comment
I guess the tricky part is indeed the point you mentioned
f we link each other, they will perfectly look like a complex web app.
Because each MVC framework uses a different approach to tackle usual problems you have in modern web-apps, like routing, data binding, application state and rendering DOM elements, so I think you would end up having multiple frameworks doing tasks that overlap substantially, thus forcing you to deactivate or disable some of the built-in functionality of one or the other framework making your frankenstein-app :) very difficult to maintain.
A good example is jQuery-mobile & ember.js, both have a routing system, jQuery uses the DOM to hold state ember.js holds it's state completely in javascript which is much faster. I had a similar problem with a project using jQuery-mobile & ember.js and this forced me to decide for one of the routing systems, I took ember's and deactivated jQuery's wich then let with just a bunch of custom mobile-looking components on the side of jQuery-mobile. Finally I removed jQuery-mobile using ember.js only and CSS for the mobile-looking app.
If not because of a concrete requirement, IMHO your best bet is to have just one very good, flexible and opinionated framework (personally I prefer ember.js) and create the modules you mentioned with your only choice.
Hope it helps.
As of now we can say that most of the applications are forced to put in more effort in its UI/UX and hence the dependancy on server side is becoming very less.
I have personally used backbone for my latest work and this has been great. The speed of the entire application can be noticed from the beginning. Ive been using PHP for the past 3 years and i can definitely vouch that backbone and other MV* frameworks are better.
Combined with CSS frameworks such as bootstrap, backbone can be an extremely organised and elegant applications.
All said, getting your head around models,views,routers,collections can be a headache. This is something which has vast possibilities and its only getting started.
Ive compiled a tutorial based on lots of tutorials present and has published at http://goo.gl/nJumC.
So many video tutorials are also available.
Only per-requisite is that one should have good knowledge of javascript and jquery methods and functions. Beginner knowledge in these will only make your task of learning backbone difficult.
Oh yes. I got my answer.
From google groups:
I think one of the reasons is javascriptless user-agents — i.e. search
engine crawlers and users with NoScript turned on.
I hope, these are real problems why websites still using Server Side MVCs.
When websites don't know target audience, they can't predict how well it will run on client side. So they should rely server to build much of their content.
And think, if stackoverflow was designed using client side MVC's to build much thier content, no one can't reach stackoverflow posts using google search.
From wikipedia under "Search engine optimization" section:
Because of the lack of JavaScript execution on crawlers of all popular
Web search engines, SEO has historically presented a problem for
public facing websites wishing to adopt the SPA model.
I think that is the shift we are heading now; I am not really sure about you but I noticed far more Client Side MVC Web sites. Anyways, you can also take a look at this ....
http://backbonejs.org/#examples
in my view, except the learning curve, it is pretty neat to develop using Client MVC and Web APIs using JSON/REST
I'm looking at building a simple login-based iOS application that needs secure access to create, read, updated and delete data from a MySQL database - with certain actions available to specific users based on roles.
I've done some research and it looks like I need to build a RESTful Web service which provides Web Services which the iPhone app calls to access the data.
I have very little experience of web services development, are there any books/tutorials that are worth checking out? Is it worth looking at a web framework, rather than start from sractch?
I've done some basic web development in PHP/Python so would prefer to build in that I think..given that hosting it would be relatively cheap..
Have done some basic C#/Java; would it be worth looking at these instead? I tried creating a simple ASMX webservice but most of the examples cite using a MSSQL server, not sure if that is the way to go though.
Use a framework. No point reinventing the wheel and giving yourself a headache. A good PHP based solution would be to use Drupal to build the backend using the Services module to provide data via webservices. Drupal is so flexible and so popular now, that you can get a lot of what you want done without any code at all.
Roughly:
Install Drupal 7 on a webserver according to the instructions
Install the Services module
Design the entities that will make up your MySQL database
Tell the services module how you want to expose things
Some examples of API calls are here.
A case study of someone else who has used Drupal as the backend for iPhone/Android is here.
You will have a learning curve to get your head round Drupal, but you'll have one anyway to get your head around webservices and the benefits you gain from having everything else Drupal offers are enormous, e.g.
The difficult bits are already done for you, so the amount of code will be massively reduced, if you even need any at all
Using Drupal's hugely flexible entities system, you can design a flexible and extensible mysql database scheme using the web based UI, which will be ready to work with any of Drupal's other modules, so you can expand add features with minimal effort in the future
There's an enormous community of people who can help you and the forums on drupal.org are very active
You would have a great UI for users, in case you ever need to give them access to their data through a normal website interface. Drupal has loads of pre-built themes (I recommend Omega) which look awesome and again, little to no code is needed to get a whole site ready made along with HTML5, standards compliance etc.
Drupal provides you with ready-made modules to provide access control via roles, as well as everything else you can imagine e.g. managing a mailing list for your users, providing you with usage statistics, admin interface for user and role management etc.
Drupal use is exploding globally and there's a serious skills shortage, so you'd be even more employable :)
First, it's not compulsory that you use a REST web service. It's just that WS si more or less standard for web-based applications.
I'm not really familiar with PHP, but in python you have django-piston. On the IOS side you have restkit to pair the server with.
What I could say from my experience is that writing a prototype in django is quite easy and you can definitely use this to develop your app.
Whenever I come across a cute website, I am always curious to know which web framework was used by its developers?
Being a novice in web development, a look at the page source doesn't give any clue.
Any way(s) to get this information? If possible, may be with a bit of Ruby magic, I can figure out things like: which is the most/least used framework for my favorite sites, audio/video heavy sites, etc.
Sometimes you can based on the URL patterns, or which scripts are included in the site ... but it's not a 100% predictor. You can write a site that completely masks the framework and simply delivers HTML/JS to the browser
Its time to rebuild my portfolio site, and I am thinking of either using Silverlight (still have to learn the basics but would be fun) or use MVC.NET.
I would like to use Silverlight since its something I am really interested in learning, and building up a small portfolio site should not be an out of this world task. However I do not know if its advisable, since I want my portfolio to be viewed and accessed by everyone, platform independent.
What do you guys think?
Thanks
From an SEO and ease of page bookmarking point of view you might want to go with traditional HTML, i.e. ASP.NET MVC.
The downside of building an entire site in Flash or Silverlight is that users can't bookmark a specific page within it, and search engine bots can't by default follow links or parse the text.
The following page deals with SEO and Silverlight sites.
http://silverlight.net/learn/whitepapers/seo-for-silverlight/
If really want platform independence you should avoid Silverlight, users on Linux especially won't get a good experience at the moment.
However if you want reasonable access by people in general then Silverlight is do-able.
You might ask yourself whether coupling your important portfolio site with your own personal improvement plan is a good idea.
Utlimately then develop your site with ASP.NET-MVC then spend some time with Silverlight without impacting your site, or perhaps include some content via Silverlight.
You can build both of them. It will allow you to see the differences between them and compare them.
I think your portfolio site should show your works also with its structure. If you are doing design, It would be nicer to make your site with Silverlight!
Those are actually not two techonologies that are related in any way or say that you should use one over another. You can have a ASP.NET MVC site (which I prefer and suggest to you) and then use Silverlight parts in it.
I prefer using Silverlight (or Flash for the same matter) only for animations, maybe parts of a website but not for entire website. If only portfolio will be built in Silverlight you should definitely do it in classic HTML too for users that lack Silverlight support.
May be it's too late about answering.
Now, Silverlight seems to go to its end. Microsoft wants to stop supporting it after 2021.
But, since Microsoft says they will ever support OOB mode, I think you could continue to developp to Silverlight today.
So I think, it's up not for animations. It's up to users of the application :
Silverlight has some good avaibilities to simulate windows like application.
After loading data in cache, you can have better user reactivity.
And, you get an other good point : user can easily cancel data they write.
At the end, with RIA services technology, for developpers, this is pretty easy to simulate entities like in client development.
As it says before, you can have mvc web application with silverlight inside.