Is there a way to have a blog directly integrated into my HTML/javascript-only website, without having to have something like a SQL-database and a dynamic engine like PHP or MySQL?
Maybe there is some service in the web that offers this (hopefully without ads :) ). Or maybe I can have a blog engine entirely written in javasript?
Entirely written in JavaScript? Surely that defeats the entire point of having a "blog-engine" in the first place? The point being that the data is stored somewhere and dynamically retrieved. To avoid using anything server-side (which seems to be your intent), and only use HTML/JavaScript, you'd have to store all the data for the blog in files that are served up to each visitor, and then retrieve the data from the particular, local, locations using JavaScript.
Sorry if I'm misunderstanding the point here... but this seems to be an utterly useless way of trying to go about things. Blogs are, in general, either written statically (in HTML [even though this is rare]), or are dynamically generated from a database by a server-side scripting language (most common).
Edit: As an additional point, I suppose you could include some third-party blog feed, or service, in your page, via use of JavaScript... but I'm unsure as to which (if any) blogging services would directly support this method of working. Additionally, this is quite an unreliable way of including third-party data in a page...
Here's a thought. It's not really a blog engine - but a wiki.
Entirely javascript/html/css. All lives in a single html file:
http://www.tiddlywiki.com/
not sure how it would work on a real live site, but their site is using it:
* A personal notebook
* A GTD ("Getting Things Done") productivity tool
* A collaboration tool
* For building websites (this site is a TiddlyWiki file!)
* For rapid prototyping
* ...and much more!
You could use github pages. You will get a generated blog with version control.
Other option is to use a Desktop blog tool and then update your site.
You can user iWeb if you have a Mac or CityDesk on Windows or you may try this open source tool
Edit Today I came across this tool: Zeta producer that may help.
http://code.google.com/p/showdown-blog/
Blog engine written in just JS and XML [v0.6] {JavaScript, XML}
So, what you want is to have a blog where you're website provider doesn't provide a way to serve dynamic content?
The only way I see that you can do it in that case is writing html-files (or text-files if you prefer) and adding them to the site. After that you can have some JavaScript to add them to your "blog-page".
You of course need to upload them to the website in the same way as you do for the other files, and then have a way for the JavaScript to know which pages it should fetch.
I am not aware of any JavaScript blog-engines, but you can have a look at the templating functions in for instance Prototype
Of course, that means that you will have to fetch both the template and the content through Ajax and let the client do all the processing (could be slow and possibly insecure), and you still need to have a place to upload the content and update it.
Your best bet is going to be using a generator to create the HTML/CSS/JS to upload to your server, take a look at Webby: http://webby.rubyforge.org/
IF you really need to you can use a public api for a service that lets you post small bits of info and retrieve it using javascript.
for example if you only need small posts you can make a blog in html.javascript that utilizes twitter as the engine. of course you will be limited to 140 chars. I am sure there are other services that will allow a similar idea but with less restrictions.
And of course the best option - Get a blog software or host your blog with a service provider and link to it from you site.
Good luck
One solution would be to use some application that generates the static web pages of your blog, and uploads them to your web server. This way you'd have a blog with static content that could all be managed in javascript alongside your existing site, without needing to install database, daemon software, or additional dynamic web programming languages on your server. The static content generation could happen directly on your server if possible, or you could run the html generation tool locally and upload the output.
MoveableType has a tool like this. You still need somewhere to store the content of your blog, and for this MoveableType uses MySQL by default, so you'd still need to install a database somewhere, but the database could simply be one your local desktop.
MoveableType also has support via plugins or older versions that can retrieve data from a sqlite or other database. The advantage of sqlite is that it doesn't require installing daemons like MySQL does, you can just put a sqlite file on disk somewhere, give MoveableType the path to the file, and run the script to generate your static content.
There are likely other tools like MoveableType, and I have in the past generated blog-like web pages simply by writing small scripts to generate HTML. The main issue is just that you need somewhere for these scripts to fetch data from.
Another option might be to develop your blog using XSLT, ... with XSLT, you'd put the content of your pages in XML files, and then write a template in XSL that converts your XML to HTML.
If you google for 'static blog site generation' you might find other ideas/options, including Jekyll/github mentioned in one of the other responses.
Related
I'm working on a Quizz with Html/JS on Github and which will be dedicated to my comrades.
I would like to be able to read everyone’s answers so I thought about creating a text or csv file with their answers that would be saved in a specific directory of the github project.
But I’m a beginner and I don’t know if that’s possible, i’ve seen tracks that use PHP or NodeJs with FileSaver.js, but I haven’t managed any of them because i would like it to be automatic, not to ask the user to download his answers.
If some people knwo how to do it or explain me why it’s impossible and how to do it otherwise it’ll be cool.
Thanks ! ;)
Unless you want to make every person using the quiz a contributor to your Github project (which will require that they sign up for Github accounts and tell you their account name so you can manually grant them permission) and then use the API to read the CSV file, modify it, then commit the change (and resolve any merge conflicts caused by race conditions): This is not possible (and if you are willing to do that, then it is among the most complex approach that you could take).
If you want to store and aggregate data submitted by visitors to a website then write some server-side code (using whatever language and frameworks you like, PHP and Node.js are both options) and use a web hosting service designed to support them. Github Pages is designed only for static pages and doesn't support any form of server-side programming.
Once you store the data in a file, just use git commands to commit and push it.
I am using react-markdown (escaped) to load markdown from a JSON file.
I utilize a static site delivers on CloudFront to cut cost and remove the need of operations costs on servers.
Currently all posts get compiled into a posts.json file that get read by react-markdown in a react-based static site.
Beyond maybe chunking this to into multiple files to prevent a huge json file needing downloading, is there any kind of issue from this method?
Is this a bad idea?
EDIT; react-snap is being used to "prebuild" or whatever the term may be. I however am unsure if this is doing anything in regards the json that gets loaded on the page, for example if its getting output in build as plain HTML. Will have to confirm.
Your approach does take on some overhead and latency since there are several dependencies that must be satisfied before your content reaches the user.
The browser must load and parse the script
The script must fetch the JSON from the server
react-markdown has to parse the markdown strings
React has to render the components
None of these are likely to be particularly slow, but we can't do any of it concurrently, and it adds up.
But since your markdown is static and doesn't require re-rendering, you can get some efficiency from moving the render to the server, possibly even to the build step itself. If the markdown string is compiled to HTML via react-markdown at build time, then the client receives the markup that much more quickly.
Frameworks like Next.js do this by design - it allows you to specify async functions that fetch the data needed to render the page at build time. The data can of course be anything that is representable as React props, including JSON.
It may be neither your reponsibility nor your preference to change your project to use a new framework, but I hope the general ideas are useful on their own.
I think server-side rendering will help in your case as most of the resources need to be compiled on the client machine. you can also use a chrome puppeteer that is headless chrome that can be used to transpile resources on the server and then send it client to reduce the latency. Refer https://developers.google.com/web/tools/puppeteer
It looks like you have everything you need to use a static site generator like Gatsby. A static site generator will allow you to keep your big JSON file which will only be read on build time. A static site generator like GatsBy will help you generate stand alone static HTML documents for each of your blog post.
You also can host your static site for free on any the popular CDNs free tiers like Nelify and Surge
A little info:
When 'inspected' (Google Chrome), the website displays the information I need (namely, a simple link to a .pdf).
When I cURL the website, only a part of it gets saved. This coupled with the fact that there are functions and <script> tags leads me to believe that javascript is the culprit (I'm honestly not 100% sure, as I'm pretty new at this).
I need to pull this link periodically, and it changes each time.
The question:
Is there a way for me, in bash, to run this javascript and save the new HTML code it generates to a file?
Not trivially.
Typically, for that approach, you need to:
Construct a DOM from the HTML
Execute the JavaScript in the context of that DOM while resolving URLs relative to the URL you fetched the HTML from
There are tools which can help with this, such as Puppeteer, PhantomJS, and Selenium, but they generally lend themselves to being driven with beefier programming languages than bash.
As an alternative, you can look at reverse engineering the page. It gets the data from somewhere. You can probably work out the URLs (the Network tab of a browser's developer tools is helpful there) and access them directly.
If you want to download a web page that generates itself with JavaScript, you'll need to execute this JavaScript in order to load the page. To achieve this you can use libraries that do this like puppeteer with NodeJS. There's a lot of other libraries, but that's the most popular.
If you're wondering why does this happens, it's because web developers often use frameworks like React, Vue or Angular to quote the most popular ones which only generates a JavaScript output that's not executed by common HTTP requesting libraries.
I'm an android developer and about two years and recently I've been thinking about building web applications. So I started researching about spring boot and everything is great. Then, I came across this thing called template engines (thymeleaf) which by definition separate your code from presentation.
What is confusing me is how can a backend server have html? should the presentation be handled by html, css and javascript in the front end? I even saw tutorials where they actually type in html code in their controller as return values.
My understanding is that the backend server exposes APIs for the frontend to use by using AJAX and the frontend will manipulate this data and present the information on the screen, why would a backend provide html code?
THank you
the frontend will manipulate this data
What front end? You mean the JavaScript code in the HTML page? Where did that come from? Oh yeah, the server.
It is the server that serves the HTML pages to the client, as well as any .js and .css files.
The server could provide static pages, and anything dynamic is handled by JavaScript. Or, the server could dynamically build the HTML page, using ... you guessed it ... a template engine.
You generally don't want JavaScript to build the page initially, just to use JavaScript for handling any dynamic behavior. Some pages don't even need any dynamic behavior.
Unless of course you're thinking about single-page applications (SPA), where there is only one root HTML page, and everything else is built client-side with JavaScript and AJAX calls, but most web applications are not SPAs.
Thymeleaf replaces JSP by providing HTML pages using a template engine. The controller requests the HTML file and Spring Boot provides that template after building it using the Model provided.
Thymeleaf is great because it allows you to rebuild templates on the fly. Lets say for example you're showing a users points to them on the front end, but maybe the points increase or decrease.
What you can do is build the template in the background using a Model. The Model reference is magically provided to the template provided which parses it.
#RequestMapping(...)
public String request(Model model) {
model.put("points", 5);
return "my-template.html"
}
Then use the Thymeleaf language to provide your object to the HTML file to be processed in the engine during runtime.
<html..>
<head>...</head>
<body>
<h1 th:text="${points}"></h1>
</html>
Spring Boots Template engine will build this in the background and present it to the user, but it will show the actual points to the end user! Hope this helps a tiny bit.
I know this question has been answered pretty effectively so far, but I want to add my two cents in as I work with Thymeleaf often.
The easiest way to think about a template engine is that it allows some dynamic development of html based on information passed to it by the controller method. This allows you to put logic in that normally wouldn't exist, or say display a certain section if a user is perhaps logged into admin.
If web pages were houses, html is the frame, css is the walls, Javascript is the lights and electricity, and a template engine would pretty much just be the architect designing the plans on the fly before the frame was built based on desires of the buyer of the house (user inputs).
OK, newer Apps and websites may just load/boot/open once and then pull or push data via AJAX requests, this is good, it saves traffic and it is fast.
But it has not always been like this and some Frameworks still don't build everything on small requests. Spring in Java or Symfony in PHP are MVC Frameworks and use template engines to build pages. This may sound a little outdated but there is still a lot of websites using this.
And if you build a web app for a customer with slow PCs or other devices and the page contents are performance heavy you might want to do as much work as possible on the server so that the user does not have to wait for long. And also you can cache the rendered pages. There is even server side rendering of react pages to e.g. make the initial page load faster...
With Java and Spring I did just use JSP I don't know thymeleaf. Just use what you like and maybe what is most supported/documented.
And building websites like this does not mean you cannot use AJAX, but if you use templates you need to think about what makes sense.
What is confusing me is how can a backend server have html?
The "back end" must have HTML, because that's what's delivered to, and rendered by, the client.
It may just be that the back end "server" is just a CDN delivering, say, an HTML/JS SPA, but there's still something delivering content to the browser.
That said: server-side rendering is still a thing, and has had a resurgence lately--a React app may have its initial rendering done on the server so again the client gets a page rendered with both HTML and associated data, and then starts acting like a normal SPA.
My understanding is that the backend server exposes APIs for the frontend to use by using AJAX and the frontend will manipulate this data and present the information on the screen, why would a backend provide html code?
Because something needs to run the JS to access those APIs.
Some history:
Browsers used to suck. JS used to be a neat add-on, sites were relatively static, and essentially all rendering was done on the server. The back end would get data from wherever it got data from and generate complete HTML pages, and there was little happening on the client side other than some form fields, maybe some validation, and that was about the extent of it.
I'm considering using GitHub Pages to implement a blog and I am kind of in the mood to reinvent the wheel. I've built my website from scratch and I don't want to use Jekyll because it doesn't seem like it can be integrated into an existing website with your own theme (correct me if I'm wrong). I want the following functionalities:
Blog with articles but without the need to constantly update the html myself
Ability to write in plain text on my computer and have my website parse the data and integrate into the website's html when I push to the git repository
A feature on the website which shows a preview of the last three blog posts
The ability to search for specific blog posts hosted on my page through google
I am considering both a static and dynamic solution. The static solution would be to write a python script that reads my blog in text format and updates the blog page to include this new article by adding more html to the blog html page. The dynamic solution would have my blog page fetch articles from the github repository and integrate them into my blog live. This would also allow for fetching more articles on demand (as the user scrolls down my page for example). Is this ridiculously over complicated or does this make sense to do as a little project? Any opinions would be appreciated!
I wrote a static site generator as a Grunt plugin a few years back, so I can probably offer some good advice here.
A static site generator will convert source files (typically Markdown or a similar format for the posts and pages and templates in your templating language of choice) into flat HTML which can then be pushed up to the server. It may also include scripts for pushing it to the place where the site is hosted. If you want to do this in Python there's plenty of appropriate modules - Jinja would be a good example of an appropriate templating system, there's several Markdown implementations, and if you need syntax highlighting Pygments is a solid choice.
It's actually possible to search on the client side. My site uses Lunr.js for this - during the build process it generates an index file for the search, and then that is loaded using jQuery with the rest of the page.
Infinite scroll should also be possible without server-side scripting as it just fetches the same content using Javascript anyway. Paul Irish's Infinite Scroll plugin is no longer maintained, but it would in theory be capable of this and there are probably alternatives.
You might want to check out the article I wrote about it for ideas. The static solution works well for me - it's cheap to host and easy to deploy. You can use Disqus or Facebook comments if need be too.
A simple static site generator is a practical weekend project, and it should be a good way of achieving what you want.