EJS Support

[SowinskiBraeden]

Create support for EJS for more manipulatable front end support. For example:

package main

import (
  "github.com/gofiber/fiber/v2"
  "github.com/gofiber/fiber/v2/template/ejs"
)

func main() {
  app := fiber.New(fiber.Config{
        Views: ejs.New("./views", ".ejs"),
  })

  app.Post("/", func (c *fiber.Ctx) error {
    return c.Render("index", fiber.Map{
          "myVariable": someRandomVariable,
      })
  })
}

Similar to how the regular html works, but enabling it for EJS

[5amch3n]

It might not be a good idea to embed EJS in a language different from JavaScript, although there are Golang JavaScript runtimes like Goja. Goja is an ES5 interpreter written in pure Go, but when it comes to node.js features, such as requiring the fs module, things get tricky...

I just managed to make Golang and Node.js work together. It's simple and easy to write a local HTTP server powered by express, which does one thing and does it well - it just renders views using the EJS engine. The Golang program sends an HTTP request to the express server, telling it to render a specified view using model data contained in the payload, and the express server responds with the rendered HTML, which will be in turn returned to the front end by the Golang program. That said, the express server serves as the hero behind the scenes, and this hero runs in a stand-alone node.js runtime, rather than being implemented using a runtime rewritten in Golang - Why reinvent the wheel when we already have one?

[gaby]

@5amch3n Performance, that's the reason to implement it in Golang.

[5amch3n]

@5amch3n Performance, that's the reason to implement it in Golang.

Actually there's no performance hit as it takes only a couple of milliseconds to send the rendering request and get the rendered HTML response. That's acceptable for me.

[gaby]

@5amch3n Yes, depends on the use-case.

[grivera64]

Creating and managing a separate standalone ExpressJS server might be a bit cumbersome to manage within Fiber (e.g. choosing/finding JS runtime, choosing an available port, etc).

From the looks of it, we have these options to choose from:

• Use ejs.co’s EJS CLI
• Parse the JavaScript from the template files and evaluate using a pure-Go interpreter (e.g. Goja, Otto)
• Use a separate JS server, as previously mentioned, but provide a config to provide port/JS runtime/etc information to give users control over the setup.

The CLI feels to be the simplest solution, but still requires external setup that Fiber cannot directly control. The second option is to interpret JS code within Fiber, but it would take time to write the extraction code (and overall, the performance may be lower than a non-Go JS runtime). The third option is also okay, though requires external setup too.

What are your thoughts?