Blogging in Lisp


Feed Aggregator Page 510

Rendered on Sun, 19 Jan 2020 08:03:14 GMT  newer latest older 

Resolving Issue #1949 (how to build Elm) with improved dockerfiles?

via Elm - Latest posts by @jerith Matt McHenry on Sun, 19 Jan 2020 04:11:10 GMT

Nix is another technology that aims to provide reproducible builds from source. Its expression for building elm is here.

Review request for my toy elm project

via Elm - Latest posts by @choonkeat on Sun, 19 Jan 2020 02:24:12 GMT

The following is just my take.

The reuse of Turn for pieces on the board and whose turn is next bothered me. It caused naming issues Player and PlayerW, Computer and ComputerW. Also required awkward case like handling Unoccupied for case model.nextTurn of

I’d introduce type Party = Player | Computer upfront, which then allowed me to talk about

type Piece  = Occupied Party | Unoccupied
type Winner = Winner Party | Draw | Unknown

type alias Model =
    { pieces : Array Piece
    , nextTurn : Party
    , winner : Winner

i feel it clarified other areas of the code

case model.nextTurn of
    Player ->
    Computer ->
symbol : Piece -> String
symbol piece =
    case piece of
        Occupied Player ->
        Occupied Computer ->
        Unoccupied ->
case model.winner of
    Winner Player ->
        "Human won!"

    Winner Computer ->
        "Computer won!"

    Draw ->
        "It's a draw!"

    Unknown ->

Also, can be replaced with the very awesome elm-live

elm-live --start-page index.html src/Main.elm -- --output main.js

A Pure Elm Text Editor

via Elm - Latest posts by @jxxcarlson James Carlson on Sun, 19 Jan 2020 01:13:25 GMT

Some progress: I’ve replaced the funky slider with real scrolling in the text-editor: Demo

Review request for my toy elm project

via Elm - Latest posts by @kindlychung keenz on Sat, 18 Jan 2020 22:08:09 GMT

I am a beginner and made a tic-tac-toe with elm:, hoping to get some suggestions for improvement here.

Thanks in advance.

Joe Marshall: Unsyndicated blog

via Planet Lisp by on Sat, 18 Jan 2020 13:33:00 GMT

I've noticed that my blog posts are replicated in Planet Lisp and Planet Scheme, and here I am spamming them with random math stuff. So I'm creating a new blog, Jrm's Random Blog, where I can feel free to post about math, science, computers in general, and whatever else bugs me, without spamming the Lisp and Scheme readers. I'll keep posting to Abstract Heresies, but try to keep it more Lisp and computer language focused.

Exploration for Server-side Rendering

via Elm - Latest posts by @rupert Rupert Smith on Sat, 18 Jan 2020 11:17:44 GMT

Yes, that would be the disadvantage of doing things that way.

You would have to load the data outside of the Elm app and pass it in as a flag.

That is how elm-pages is working, but it has all the initial data for a view as meta data associated with the content it wants to render - so already it is imposing restrictions on how you structure your app for SSR. I still feel this is the best way though.

Exploration for Server-side Rendering

via Elm - Latest posts by @ktosiek Tomasz Kontusz on Sat, 18 Jan 2020 11:03:38 GMT

In my demo I’m mocking requestAnimationFrame to know when the rendering is over. Maybe that would work for you too? You could wait for the “settled” event from your update, and then run all pending RAF callbacks.

Exploration for Server-side Rendering

via Elm - Latest posts by @pdamoc Peter Damoc on Sat, 18 Jan 2020 11:02:33 GMT

As far as I see, there are 2 things that need to happen:

  1. A way to do the server sider render
  2. A new way to initialize the Elm app

The simplest model that comes to my mind for the server-side render is a Task that produces a String that is the rendered html. Alternatively it could produce the model and have the conversion to String happen automatically. All the commands that end up in init would have to be converted to a chain of tasks in order for this to work. I’m expecting that most of the init code could be converted to a Task.

The initialization part is a little bit trickier. I cannot figure out how to do it without adding yet another parameter to the Program type. In essence, the init needs to receive a new data type that would represent the payload to a message that would put the initial model in the “after the initial update” state.

Elm Japan 2020 conference

via Elm - Latest posts by @lucamug on Sat, 18 Jan 2020 01:07:22 GMT

Nice to hear that, thank you!

Exploration for Server-side Rendering

via Elm - Latest posts by @kevinyank Kevin Yank on Sat, 18 Jan 2020 00:28:48 GMT

I’d say that’s an untenable restriction. It is very common for Elm apps to init into a “Loading” state, which then fetches content from the server. Only once that content is loaded and the view updated is the view content-complete, and it’s that view that we want to send from the server, so that search engines and clients without JavaScript can access the content.

If the Elm runtime were going to attempt to pick a sensible moment to declare the view “stable”, I’d say it would be the first view after all of the commands triggered by init have run, the resulting updates processed, and the first view after that rendered. But even that would be full of edge-cases.

Server-side rendering an empty shell with a loading spinner is not very useful.

@rupert the “SVG canvas” type of application you’re thinking of doesn’t strike me as a particularly good candidate for server-side rendering. One local business that depends heavily on SSR, for example, is a job search website, which has category pages that initially list the newest jobs in that category, but which provide a rich set of filtering controls that you can apply and have the search results update (with each filter state having its own bookmarkable/shareable URL). That company considers it vital to have those job listing pages (as well as the individual job pages) load very fast (because search engines rank fast-loading pages higher), with complete accessibility to search engines and people with disabilities.

Make you a puzzle in Elm

via Elm - Latest posts by @mgree Michael Greenberg on Fri, 17 Jan 2020 20:45:04 GMT

This isn’t particularly Elm related, but I’ve found it very helpful to write a simulator for a given machine, especially when 18k RPM drill bits and $50k vacuum tables are involved.

Exploration for Server-side Rendering

via Elm - Latest posts by @rupert Rupert Smith on Fri, 17 Jan 2020 16:45:08 GMT

I think always taking settled as being on the first view has an advanatage though - it does not allow any effects to be run. This means that SSR doesn’t have to worry about say Browser effects that won’t work right in that context.

For example, often one of the first things my SVG apps do is to get the window size or an element size, to help set up an SVG canvas that is 1:1 with the pixels. In an SSR context there is no window size to know, since that doesn’t come in with the GET request for the static page. I might still render some framework for the page, and then do the SVG drawing after rehydration.

This would save on the need for some effects having to change their APIs to report that they are not available in an SSR context.

Exploration for Server-side Rendering

via Elm - Latest posts by @rupert Rupert Smith on Fri, 17 Jan 2020 16:40:00 GMT

Yes, I think you are right, that is where it needs to go. Its not after init its after the first view.

Using a port to signal when all necessary effects are completed is one way to do it. Means each SSR framework needs to define which port to use. So I guess this could be another built-in that the Elm runtime could provide.

module SSR exposing (..)

{-| Once this command has been run the `onViewComplete` event 
will have the `settled` flag set to true.
settled : Cmd msg

Exploration for Server-side Rendering

via Elm - Latest posts by @gampleman Jakub Hampl on Fri, 17 Jan 2020 16:03:32 GMT

A technique I’m using is to notify a port when all the necessary effects have been processed by update. Once the JS (running JSDOM in my case) receives that, it needs to know when the next view function has completed. Unfortunately there is no callback for that, so I set up a mutation observer and assume that the next mutation is the VirtualDOM done.

This works OK without too much manual work (basically a single out port), but feels a bit brittle. A callback after view rendering would be much nicer.

Exploration for Server-side Rendering

via Elm - Latest posts by @rupert Rupert Smith on Fri, 17 Jan 2020 15:59:30 GMT

One issue with static impressions of an Elm app is knowing when to do it - when to consider the page has settled. The one point it can be done deterministically is right after the init function; take the view that results from that first Model. Any other time could be non-deterministic since init could return a Cmd.batch and the order in which those hit the update cannot be guaranteed. Consider starting a timer and issuing an HTTP request, which will complete first?

There are SSR techniques that work with Elm already, I am trying to think of things it cannot do, and whether the Elm compiler or runtime could support them better.

Would having some event you can listen too, in order to know when init has completed (or even when update or view are being run) be something that needs to be added to the Elm runtime?

My first hours of Elm

via Elm - Latest posts by @system system on Fri, 17 Jan 2020 14:25:46 GMT

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.

Exploration for Server-side Rendering

via Elm - Latest posts by @kevinyank Kevin Yank on Fri, 17 Jan 2020 12:29:34 GMT

Server-side rendering of dynamic (user- or query-specific) responses is the gold standard that the React community here looks for in alternatives.

Exploration for Server-side Rendering

via Elm - Latest posts by @ChristophP Christoph P on Fri, 17 Jan 2020 12:23:14 GMT

I believe stuff like prerender IO doesn’t have a hot browser doing the prerendering, while the request happens. Rather it is more like a cron job crawling the page and caching the pages periodically. You then have a server in front of the prerender io cache that merely serves the cached pages IF it detects you are a search engine bot. Regular users will be served the regular index.html which then starts loading the JS bundle.

I think it makes sense to categarize the prerender approaches into 1) solutions that crawl and cache periodically and 2) solutions that do actual SSR upon request.

For the latter I agree it would likely too slow to do it with a headless browser.

Exploration for Server-side Rendering

via Elm - Latest posts by @joakin Joaquin on Fri, 17 Jan 2020 11:59:18 GMT

I can vouch that for this approach, it is a very hard problem to tackle. Securing and sandboxing the browsers (because they are running what could potentially be malicious user input, and the last thing you want is a compromised server), and doing the proper queueing and resource balancing is a very hard problem. Chromium and puppeteer under load can have very unpredicable behavior.

At work we have something like this for rendering PDFs from web content, and it was a long and challenging project to get sufficiently right for production usage. And now on the maintenance stage, keeping up with the chromium upgrades and the OS upgrades of the servers is also a non-trivial amount of ongoing work.

YMMV, but I advise caution with this approach for any non-trivial use cases.

Exploration for Server-side Rendering

via Elm - Latest posts by @kevinyank Kevin Yank on Fri, 17 Jan 2020 11:47:30 GMT

See “reasons for wanting this” in my original post above. In short: performance, SEO and accessibility.

Spinning up a full (headless) browser on the server is needlessly resource-intensive, and not especially fast unless you’re maintaining a fleet of “hot” browsers waiting to render things.

Yes, but it’s a case of “why not both?” Rendering with Elm is faster than React (say), and doing the initial render on the server is faster than doing it on the client. Combine the two for maximum speed.

Again, these are all beneficial performance measures. One does not preclude the usefulness of another.

That said, there would be value in measuring their relative benefits in real-world scenarios to see which should be the priority if people need to choose one to focus efforts on.

 newer latest older