I saw this trick mentioned by Wes Bos on YouTube and wanted to share it because I thought it was pretty cool.

Did you know that the style tag can be used as any other HTML tag? That means if you display is as a block, it will display your CSS as text on your website.

That also means that you can add contenteditable to the tag so that you can edit the CSS and see the changes in real time. Nifty, right?

You can see and edit the CSS in the CodePen below

I've added some white-space styling and some javascript to hinder the browser from adding <div>s to the style tag when you hit enter, but other than that you can pretty much edit, add or remove whatever CSS you want. A transition is also added to all elements so that you can better see the changes. Try for example adding a font-size or color.

While I don't think this has any real world applications, I never thoght about how all HTML tags actually are HTML tags and can be used in the same way as all the others.

The <style> tag is like any other HTML tag

Uutilsynet deler brukere med nedsatt funksjonsevne inn i 4 grupper: motorikk, syn, hørsel og kognisjon. Brukere med kognitive funksjonsnedsettelser har problemer med å ta til seg og bearbeide informasjon, og vil typisk slite med å

konsentrere seg

huske (korttidsminne)

lære seg hvordan noe virker

fullføre oppgaver

Oftest ser man på kognitiv funksjonsnedsettelse som permanent (autisme, ADHD, dysleksi osv.), men har du tenkt på at en midlertidig hjernerystelse, en fyllesyke eller en hektisk småbarnshverdag også kan skape tilsvarende utfordringer?



Hvordan kan du bidra?

Det kan være veldig vanskelig å vite nøyaktig hvilke utfordringer en løsning skaper for brukere med kognitiv funksjonsnedsettelse, men her er et par tips som kan være fint å huske på:

Tydeliggjør hva som er viktig funksjonalitet og i hvilken rekkefølge de eventuelt skal benyttes

Bruk bilder, illustrasjoner, video og lyd i tillegg til tekst da tekstlig innhold ofte kan være vanskelig å forstå alene

Bruk et enkelt og forståelig språk (https://www.sprakradet.no/Klarsprak)

Del opp lang og/eller komplisert informasjon i mindre biter

Nummerer stegene i en lengre prosess slik at brukeren enkelt kan se hvor hen befinner seg

Begrens hvor mye informasjon brukeren må oppgi



Har du lyst til å lese mer om dette?

https://www.uutilsynet.no/brukerutfordringer/kognisjon/160

https://www.kunnskapsbanken.net/kognisjon/

Ta hensyn til kognitive funksjonsnedsettelser!

Flux is a tool that enables continuous delivery of things like Helm Apps and your applications. While the suggested method of installation is using the Flux CLI tool, is this the way to go in a world of IaC? Let's take a look at how we can install Flux using Bicep, the IaC language for Azure!

So, what's Flux?

To quote the Flux website:

Flux is a set of continuous and progressive delivery solutions for Kubernetes that are open and extensible.

Cool, it enables continuous delivery, a staple of modern software development! It works by keeping track of various configurations and acting accordingly to the declared configurations. The configurations are stored as custom resources in Kubernetes, which in practical terms, just means a new ApiVersion and Kind in the Kubernetes manifests.

One example of a custom resource is a GitRepository, where Flux stores information such as the URL, authentication, retry interval, and what to use for git commit verification. A GitRepository can then be used as a basis for other resources - like a Kustomization resource that says where to look for Helm apps, or how your application is deployed. For an in-depth introduction to Flux, see their pages on Core Concepts, Getting Started, or Flux from End-to-End.

Note also that it's a set of solutions, so you can use just one of the Flux controllers it if that's your wish. One example would be to use the Helm Controller to install Helm apps by applying HelmRelease manifests to the cluster, instead of running helm install!

And how do you install Flux?

To summarize the Flux docs, you;

Install the Flux CLI tool

Run the relevant flux bootstrap command

And that's it! Now, the bootstrap command does multiple things to make all of this work. If we take GitHub as an example, it..

.. adds the Flux manifests at the specified path in the repository

.. installs the Flux components to the Kubernetes cluster

.. configures a deploy key in the repository for read access

.. configures Flux in the cluster to sync against the given repository

So after the bootstrap command is done, you have a cluster capable of continuous delivery by pulling configuration. The alternative is to push the configuration with commands like kubectl apply or helm install.

 While a pull-based approach adds a little complexity it also has some advantages, such as;

Security, there's less permanent access to the cluster needed

Consistency, it regularly pulls the configuration and checks for configuration drift

History, the benefit of Git also applies to your k8s configuration

So, what's the catch?

It does sound good, especially the Flux components and the ease of installation. But, infrastructure should be managed as code, so using a CLI tool for installation? Of central infrastructure components?

Also, there's the question about how to run the CLI tool. From your machine against production? Eh, rather not. Let's avoid that privilege as much as possible. How about the CI system? Sure, it does so already, but wouldn't it be nice if you could cut off that access to the cluster? Taking Github Actions as an example, they use 2584 IP blocks. That's a pretty big door to leave open to your cluster.

Another thing - how long does it take after your IaC run is finished before you remember to trigger the job that installs Flux? 😏

The AKS IaC solution

If you're working in Azure, there's a good chance you're using Bicep to manage your IaC. To enable Flux in your cluster, all you need is to add these lines of code to your relevant Bicep file;

And with that, your cluster has Flux! It now supports pull-based declarative configuration of your cluster configuration, your applications and Helm apps. You can also configure it to send notifications when necessary. No manual steps, and minimal downtime between the readiness of the AKS cluster ready and Flux.

But we're not done. While all of the above is possible in theory, we still haven't told it what configurations to sync. However, with a few more lines of Bicep, we can also kick of syncing immediately once it's installed;

This adds your Git repository as a source in Flux, and Flux will read your initial cluster configuration from the environment-specific path ./clusters/${environment}. From there, you can branch out to other sources and/or configurations for your cluster as normal for Flux. A few notes to be explicit;

sshPrivateKey: Base64 encoded pem key. This means base64 encoding the entire content of the pem key, headers and all

sshKnownHosts: One Base64 encoded string with all public keys that the remote might present

gitOpsBootstrappingRepoSSHUrl and gitOpsBootstrappingRepoBranch are parameters sent in to the Bicep file

As you might have understood, it's a small downside to this over the CLI version; you have to manage the access for Flux to the Git repository manually. If we use Github as an example(again), this can be as simple as a read-only deploy key already installed on the repository.

Deploying Flux as part of the AKS IaC

Teamet mitt startet nylig å skrive CSS. Vi er ferdig med superspråk som kompilerer ned til CSS. Vi bruker ikke noen rammeverk, men skriver gode, gamle CSS-regler. Det er på tide å forenkle hvordan vi tenker på styling.

Utenom tradisjonelle CSS-filer, har vi hovedsakelig tre ulike måter å skrive CSS på:

Du kan bruke en preprocessor som Less eller Sass, som utvider språket med ny syntaks som variabler og nøstede selectorer. I byggsteget kompileres syntaksen til vanlig CSS.

Du kan skrive CSS sammen med JavaScript-koden din (CSS-in-JS). Styled components, Stitches og Emotion er tre ulike biblioteker som tilbyr akkurat dette.

Du kan bruke et CSS-rammeverk, som frister med ulike abstraksjonslag hvis du ikke har lyst til å skrive CSS i det hele tatt. I sistnevnte kategori finner vi alt fra Bootstrap til up-and-coming Tailwind CSS.

Alle disse variantene kommer med enkelte ulemper. Preprocessors tilfører et nytt steg i byggeprosessen. Med CSS-in-JS mister du ofte syntaks-highlighting, og du går glipp av ytelsesgevinsten med separate CSS-filer. Tailwind tilfører mye ekstra markup til HTML-koden din, og du er avhengig av å lære deg et nytt språk.

Nå skal jeg skal innrømme at vi bruker en variant av preprocessors, nemlig CSS modules. Det er et knøttlite verktøy som sørger for at klassenavn blir helt unike, og passer perfekt sammen med komponent-tankegangen til React. Ellers skriver vi nå helt vanlig CSS, i egne filer som lever side om side med React-komponentene våre.

En enklere byggeprosess

Uten noe kompileringssteg får du ett mindre steg i byggeprosessen, og vet nøyaktig hva du leverer i produksjonsbygget. Tailwind hevder de lar deg skrive styling mye raskere enn med vanlig CSS. Men hvis noe skjærer seg, er det fort opp med utviklerverktøyene. Da er det veldig praktisk at nettleseren viser akkurat samme CSS-regler som du skrev i koden din.

En annen fordel med en lettere byggeprosess er at koden blir enkel å vedlikeholde. Hvis du ønsker å prøve ut et moderne frontend-rammeverk som Gatsby eller Remix, slipper du å lure på om de støtter din foretrukne CSS-abstraksjon.

Et abstraksjonslag kommer alltid på bekostning av noe annet. Hvis du bruker Tailwind eller skriver styling med JavaScript, kan det ofte være knotete å skrive “At-rules”, eller betinget styling. Moderne CSS støtter for eksempel media queries, slik at du enkelt kan tilpasse nettsiden til ulike flater og preferanser. Snart får vi container queries, som lar deg style en komponent basert på sin egen størrelse. Nytt i CSS er også feature queries, som lar deg skrive tilpasset CSS for nettlesere som støtter nye konvensjoner. Det betyr at du kan bruke Subgrids i dag, selv om det foreløpig kun er Firefox og Safari som støtter dette.

Men CSS er da fryktelig vanskelig?

Det virker som mange velger rammeverk som Tailwind, eller alternativer som Sass fordi de skyr, er redd for eller hater vanlig CSS. Og det er kanskje ikke så rart. Det er ikke så mange år siden styling var fryktelig vanskelig. Men hvis du fremdeles forbinder styling med CSS-tabeller og float: right, er det kanskje på tide å lese seg opp. CSS har endret seg ganske dramatisk de siste årene, og er nå mye enklere enn mange tror!

Alle moderne nettlesere støtter nå Flexbox for organisering i to dimensjoner, Grids for organisering i tre dimensjoner, og Gaps for luft mellom elementene inni disse. Hvis du i tillegg lærer deg litt om spesifisitet og box-modellen, vil jeg påstå du klarer å håndtere de aller, aller fleste skissene designeren sender deg.

To problemer folk ofte nevner om CSS handler om scoping og nøsting. Scoping kan løses med enkle verktøy som CSS modules, eller ved å bruke BEM-konvensjonen. Og hvis CSS-en din er godt scopet, har du kanskje ikke så stort behov for å nøste reglene dine. Hvis du allikevel er allergisk mot repetisjon, vil du antageligvis glede deg over at den offisielle spesifikasjonen for CSS nesting nylig er kommet hakket videre i utviklingsprosessen. Du kan til og med stemme på den syntaksen du foretrekker!

Vær rustet for fremtiden

Moderne CSS har fikset mange av irritasjonsmomentene vi tradisjonelt har forbundet med styling. Derfor mener jeg det er på tide å forenkle hvordan vi tenker om arbeidsmetodene våre. Kanskje vi kan migrere bort fra preprocessorer som Less og Sass. Og kanskje vi til og med klarer å motstå fristelsen til å velge større CSS-rammeverk som Tailwind.

Selv har jeg forlatt alle abstraksjonslagene. På teamet sitter vi igjen med moderne, vedlikeholdbar og helt vanlig CSS, og er strålende fornøyd med det. Kanskje det er verdt å prøve på ditt neste prosjekt? Husk at når du skriver vanlig CSS, lærer du deg grunnleggende webteknologi som kommer til å bestå i mange, mange år fremover. Du kan pugge Tailwind sitt API, men det er ikke sikkert du får bruk for dette i ditt neste prosjekt. CSS lærer du aldri forgjeves.

Lær deg CSS, ikke Tailwind

Macros enable developers to extend a language to accomodate future or domain specific needs without waiting for language updates. In this post, we extend the control flow of the language.

Introduction

Much of Lisps longevity is due to its metaprogramming, that is code that treats code as data. Lisp uses the same syntax for both code and data, which makes manipulating code as easy as manipulating data.

Macro functions (or just macros) are just like regular functions, except that the arguments aren’t evaluated before calling, and they should return code (which means data as s-expressions which will be interpreted as code) rather than a value. The macro decides if, when, how and how often an argument is evaluated.

This allows macros to remove repetition, extend the semantics of the programming language, or even create new programming languages within the programming language. Most other languages simply do not have the expressive power to do anything like this, or make it different from built-in constructs or difficult to write.

I’ll demo a couple of simple macros to extend control flow and looping constructs, and I’ll use C# as a contrast to the lisp code.

The intention of this post is meant only to pique your interest in lisp. Production quality implementations of concepts presented here is probably available in libraries for pretty much every lisp out there.

Basic building blocks

Before showing the macros, I’ll explain a few of the building blocks we’ll use.

In lisp, as in many other languages, everything is an expression. If you want to execute some effects, you have to wrap them in an expression which somehow returns a value. The most common construct is progn which accepts many expressions as arguments and returns the result of the last expression. Several other languages do this by default, and lisp also has many forms which does this implicitly.

In C#, you can create a new lexical scope using braces. Variables defined within the scope don’t escape the scope. Many programmers don’t use new scopes outside some statements like functions, if, while etc, but they are still available if you want to control visibility of variables, disposing, finalizing etc.

A new scope can be created using let in lisp. While progn allows several expressions and returns the last, let also allows creating new variables in this scope. let has an implicit progn so you can pass several expressions instead of explicitly stating a progn.

The fact that everything is an expression means we don’t have to declare variables ahead of initialization with dummy values.


In lisp, as in other languages with expressions rather than statements, we can write the following.

Code as data and code that writes code

That’s about the basics we need before looking into how macros work. Syntax in programming language is parsed into an abstract syntax tree (AST) in order to be further analyzed and manipulated. In lisp we write our programs directly in an AST.

So how can we represent the following code as data?

list creates a list, quote returns the exact symbol/value without evaluating it.

Fortunately, we don’t have to write code as above. By quoting the first list, everything within is quoted. We can thus rewrite the above with just a single quote at the start, getting the exact same code, but this time as data!

When creating code that manipulates code, it’s often useful to evaluate certain expressions. When we use the verbose syntax, this is easy. (list (quote +) x 1) will evaluate x as it’s not quoted, but not +.

Let’s say we have the following code, and we want to return the code (+ 1 2). Our first attempt returns (+ x 2), which isn’t what we want.

We have a form similar to quote called quasiquote or `. When using this form, we can unquote the expression using ,, which will evaluate the expression.

There is also unquote-splicing, ,@, which will unquote a list and flatten it (remove the “(list” and “)” part), e.g. `(1 ,@(list 2 3) 4) equals '(1 2 3 4).

With the basics out of the way, let’s start extending the language with some new control flows.

New control flow abstractions

A regular C# if statement looks pretty much the same as a lisp if expression.

But often, we only care about the “then” or “else” clause.


The “else” clause is often written by negating test rather than using an empty “then” block


Let’s create two new control flow constructs, when for the “then” clause and unless for the “else” clause. This removes some repetition as well as making the intent clearer.

Rather than


We’ll write

It makes it very clear that there is no “else” clause, and we can use an implicit block. Notice that the definition looks pretty much exactly as we would have written the if expression simply because code and data has the same syntax.


We’ll do the same for the “else” case.

We could have defined unless in terms of when and negating test, but let’s use if directly to avoid the extra function call.

As a side-note, truthy and falsy is quite different in some Lisps like Common Lisp (CL) which this article is using. In CL, only nil is falsy and every other value is truthy. This means functions can return actual data instead of true / false, and we don’t have to inspect the value or revert to using only booleans.

The pattern below is quite common, but in Lisp we don’t need to store the temporary or checking against a particular value.

But what if the block needs the value too? In that case we need to store the value in a variable in order to use it later.

We can write this using a let

or is using this fact to return a value rather than evaluating to a boolean. The following is quite common code, and is easily expressed just using or.

Binding the test only for the success case

The pattern of binding something and then using it within an expression is a common pattern. In other languages we annoyingly often create temporary values which outlive the expression they are used in. But using macros, we can do this The Right Way; we’ll create if-let, when-let and unless-let. Using these, our code just becomes

The macros are no more difficult than what we’ve already seen.

Anaphoric macros

But we’re not finished yet. We don’t really care about the name something in the expression. We could call it it and make it available in the scope. This is called “anaphoric” macros. Our previous example thus becomes

Let’s see how a lisp expression using awhen and or would look like in C#.

Creating new loops

Let’s turn our head over to loops which also has some common patterns; looping until some condition is met. The loop in C# will look different based on what kind of thing we expect. Here is a simple boolean to become true, and other types of checks would look different.

But any complex expression is possible

Looping forever is normal in background processes. It’s easy to express in most languages, but being more explicit could improve readability.

Conclusion

The examples are quite contrived and don’t show the real power of macros. But hopefully they show that macros are within reach and allow you to extend your language to fit your domain. Building a program bottom-up by creating a language that allows you to express a solution to your problem clearly, is one of the great features of lisp.

A quick peek at lisp macros

Veien til et mer bærekraftig næringsliv representerer et hav av nye muligheter som vi i begrenset grad utnytter. Det kan være flere grunner til dette. Store selskaper har etablerte strukturer som gjør det vanskelig å omstille seg, og de mindre selskapene får ofte ikke tilgang til nok kapital eller teknologi for å skalere løsningene vi trenger. I denne artikkelen går vi nærmere inn på bærekraftsgapet som eksisterer i næringslivet i dag, og hvorfor vi skal bry oss om å redusere det.

Veien til et mer bærekraftig næringsliv representerer et hav av nye muligheter som vi i begrenset grad utnytter. Det kan være flere grunner til dette. Store selskaper har etablerte strukturer som gjør det vanskelig å omstille seg, og de mindre selskapene får ofte ikke tilgang til nok kapital eller teknologi for å skalere løsningene vi trenger. I denne artikkelen går vi nærmere inn på bærekraftsgapet som eksisterer i næringslivet i dag, og hvorfor vi skal bry oss om å redusere det.

Figuren nedenfor illustrerer på en forenklet måte hvordan næringslivet leverer på bærekraft i dag. Det rødstripete området viser det vi kan omtale som bærekraftsgapet: et uforløst mulighetsrom som oppstår fordi vi ikke klarer å skalere og levere bærekraftige forretningsmodeller til større deler av markedet.

Illustrasjon av Bærekraftsgapet, Schaltegger et al. (2016)

Virksomheter som i dag leverer gode bærekraftige produkter og tjenester er ofte mindre nisje-selskaper, som har bygget en bærekraftig forretningsmodell fra start. Et godt eksempel på dette er tekstilprodusenten Sisters in Business. Sisters in Business skaper arbeidsplasser for kvinner med innvandrerbakgrunn gjennom lokal og sirkulær tekstilproduksjon. Selskapet leverer høy bærekraftskvalitet gjennom en inkluderende og sirkulær forretningsmodell. Utfordringen er at mindre selskaper som dette ofte ikke er rigget for storskala produksjon, eller at de mangler kapital eller teknologi for å skalere løsningene til en pris sluttkunden vil akseptere.

På den andre siden har vi store etablerte selskaper, som eksempelvis klesgiganten H&M. Disse har gjerne høye markedsandeler og kan påvirke mange kunder, men karakteriseres av etablerte strukturer som gjør det vanskelig å reorientere seg i en mer bærekraftig retning. For at vi som samfunn og næringsliv skal levere bedre på bærekraft kan vi ikke basere oss på at de mindre oppstartselskapene leverer de gode bærekraftige forretningsmodellene og kvaliteten vi trenger. Vi er helt avhengige av at også de store virksomhetene transformeres ettersom de som har volumet og kundemassen som kreves for at endringene virkelig skal gi effekt.

For å utnytte bærekraftsgapet i næringslivet i dag må dermed virksomheter som H&M levere bedre kvalitet på bærekraft, og selskaper som Sisters in Business få større tilgang til kapital og teknologi for å skalere opp de løsningene vi trenger. Det er i dette mulighetsrommet vi kan finne de gode løsningene for fremtiden.

Bilde fra Sisters in Business, Fotograf: Ingar Sørensen

Hadde det vært enkelt å utnytte disse mulighetene, hadde det nok allerede blitt gjort. Det er særlig tre elementer som kan hjelpe spesielt de større selskapene med å bevege seg i riktig retning:

1. Prioritere strategiske tiltak

Ingen kan bli best på noe ved å satse litt på alt. På samme måte som bedrifter bygger en forretningsmodell der man prioriterer aktiviteter som gir mest verdi, må det brukes tid på å forstå hvilke bærekraftsinitiativer og tiltak den enkelte bedrift er best posisjonert til å levere på — både i form av forretningsmuligheter for selskapet og det som gir høyest verdi for alle selskapets interessenter. Mange selskaper begrenser sine initiativer innenfor bærekraft til enkle og synlige tiltak som kundene eller de ansatte legger merke til, heller enn å ta steget til å tenke helt nytt rundt produktet eller tjenesten de tilbyr. Det holder ikke at det er kildesortering på kontoret hvis kjerneaktivitetene fortsetter å gå sin vante gang.

2. Se til de som lykkes

For at vi skal klare å utnytte mulighetsrommet av løsninger må næringslivet i større grad se til de som lykkes. Større virksomheter burde gå i dialog med mindre aktører som har lykkes med å bygge en bærekraftig forretningsmodell og leverer høy bærekraftskvalitet. Flere burde også trekke lærdom av andre i egen bransje eller se til det andre bransjer lykkes med — både for det private næringsliv og offentlige aktører. Det er mange større selskaper som har lykkes med å vri sin drift mot bærekraftige produkter og tjenester — disse selskapene burde flere virksomheter lære av eller samarbeide med. For å levere bedre på bærekraft kommer vi alle bedre ut dersom vi jobber sammen og inspireres av hverandre.

3. Tørre å satse med både investeringer og ressurser

For å oppdage og lykkes med mer bærekraftige løsninger må virksomheter tørre å investere kapital og dedikere ressurser. Det nytter ikke å drive med “løft på bærekraft” på deltid, eller ved siden av de vanlige oppgavene de ansatte jobber med. Bærekraft representerer vår tids kanskje største forretningsmulighet, men det fordrer at bedrifter tørr å jobbe med denne muligheten på fulltid og satse på det.

Disse punktene er på ingen måte banebrytende eller uttømmende, men de synliggjør at det fortsatt ikke gjøres nok for at vi skal lykkes med omstillingen til et mer bærekraftig næringsliv og samfunn. For å bidra til å tette bærekraftsgapet og realisere mulighetsrommet, må næringslivet prioritere nye bærekraftstiltak der den enkelte bedrift har mest å tilføre, lære av eller samarbeide med de som lykkes, og tørre å satse både kapital og ressurser på morgendagens forretningsmodeller.

Meld deg på nyhetsbrev for å få oppdatering om faglig innhold og arrangmenter.

Relevante ressurser

Schaltegger, S., Lüdeke-Freund, F., & Hansen, E.G. (2016). Business Models for Sustainability. Organization & Environment, 29, 264–289.

https://www.sistersinbusiness.no/

https://hmgroup.com/sustainability/




Bærekraftsgapet

React.js is a powerful and popular JavaScript library that allows developers to create rich, interactive user interfaces. In recent years, React has become the go-to technology for creating web and mobile applications. But what if you could take your React development to the next level by writing your React code in F#?

In this article, we’ll explore the advantages of writing React in F#, and explain why making the switch could be a great way to take your React development to the next level.


TypeScript

Even if you can write React in JavaScript, TypeScript has become very popular. It basically allows you to write JavaScript with types. Furthermore TypeScript is a superset of JavaScript, which makes it easy to get started with if you already know JavaScript.

Using TypeScript will remove some issues that can arise when using JavaScript alone. It makes code easier to maintain and reason about. Honestly: if your team consists of more than one person, or if you are paid to write code, using JavaScript for anything substantial is irresponsible and a waste of your client’s money.

F#

While TypeScript has a strong type system, it does have one major drawback. It is a superset of JavaScript. It needs to be able to type everything you can express in JavaScript. This means that you have a type system that lets you get away with doing too much crazy stuff.

TypeScript's type system allows developers to make assumptions about the types of data they are working with. This can lead to errors and bugs if the assumptions are wrong. Additionally, the type system is more relaxed than other languages, so it can be easy to overlook a potential problem. For example, TypeScript will not prevent you from passing the wrong type of data to a function, which can lead to unexpected behaviour. It is important for developers to understand the types of data they are working with and to be careful when making assumptions about them.

F# on the other hand has a much stricter compiler and rules. While the syntax might be reminiscent of a TypeScript and Python mix, it is far more similar to Elm than it is to TypeScript.

In F# everything is immutable by default, in TypeScript you would need some third-party library to achieve this. It also has a much better standard library. In F#, you can simply call the groupBy function when you need it, without having to worry about whether your favourite utility library is up to date. Lastly F# has pipelines, which is such an enjoyable way to compose functions.

React

A very simple react component could look like this:


It is normally written in JavaScript or TypeScript - which is compiled to JavaScript.

You can also write React in F# with a library called Feliz and compile it to JavaScript with a tool called Fable.

Fable + Feliz
In order to interact with the DOM and call React, Feliz is used as the library of choice.
To make this all work, F# is compiled to JavaScript with Fable. The result should then be used in combination with a bundler for further optimization.

In the future, Fable will also enable you to use JSX directly in your F# code, making it easier to work with existing React components and lower the barrier to entry.

Components in F# and TypeScript

The same example above in TypeScript


And in F#

The main differences here are:

In F# you do not need to specify types, the compiler will infer them. However you can specify them if you want.

In F#, HTML markup is not written in JSX, but rather consists of normal F# functions. These functions are typed so you can easily see what the different components do and what parameters they take. This means that your HTML markup is now type safe. If you mess it up it won’t compile, and that is lovely!

Hooks F# and TypeScript

You can use hooks just as you would expect:

Typescript:

F#:


Community
Lasty I would like to quickly mention the F# community. It is a highly supportive environment that encourages collaboration and learning. The F# language is designed to be easy to learn and use, and the community is full of welcoming and helpful people who are always willing to help out newbies.

They also do a lot of work for the community. Making tools and libraries which are super useful.

I recommend checking out the F# website for more info on the slack and discord channel.

Conclusion
React.js is a popular JavaScript library that allows developers to create rich, interactive user interfaces.
In recent years, React has become the go-to technology for creating web and mobile applications.

However, using TypeScript or JavaScript to write React code can have its limitations.
One alternative is to use F#, a programming language that has a stricter compiler, immutable values by default, a better standard library, and function pipelines.

F# can be used to write React code with the help of tools such as Feliz and Fable,
which enable developers to compile F# code to JavaScript.
Using F# for React development has several benefits
including improved type safety, more concise and maintainable code,
and the ability to take advantage of F#'s powerful language features.

While using F# for React development requires the use of additional tools and libraries,
the benefits outlined in the article could make it worthwhile for those looking to take their React development to the next level.

Here are some links you can check out if this is interesting:

- FSharp.org - the F# website

- F# for fun and profit - THE website to learn F#

- Fable - Compiling F# to other languages like JavaScript

- Feliz - the library that enables React.

- Elmish book - Practical and free e-book on how to write "Elm"-ish code with F#.

- Preact - How to on using Preact instead of React if you prefer that.

- Sutil - if you prefer something Svelte inspired.

- Lit - For the developer who wants to write HTML


You should write React in F#

Dagens designtips er en artikkelserie hvor forskjellige designere fra Bekk snakker om jobben de gjør, hvilke utfordringer de møter på, og kanskje kommer med et lite tips.

Hvem er jeg?

Mari

24 år gammel 

Fra Oslo

Studerte Industriell Design på NTNU

Jobbet som designer i 4 måneder 


Hvorfor ble jeg designer? Jeg valgte å bli designer fordi jeg alltid har hatt en interesse for det kreative, samtidig som jeg var glad i realfag på skolen. Jeg har aldri vært den som har vært mest kreativ i den tradisjonelle betydningen av ordet, men problemløsning har jeg syntes har vært interessant. Designlinjen på NTNU passet meg derfor bra da jeg fikk kombinert kreative og tekniske fag.


Hva gjør jeg (og hvordan)?

Jeg jobber på en intern tjeneste som heter Atlas. Dette er en faghub som samler faglig innhold som vi i Bekk syntes er bra. På siden finnes det innhold som folk i Bekk har produsert, men også eksternt innhold som noen har ønsket å dele med andre i Bekk. Dette har vært en av flere tjenester som jeg har hatt gleden av å jobbe med siden jeg startet i Bekk i august. Det som gjør det spesielt interessant å jobbe med Atlas, er at det er en tjeneste med stort potensiale. Samtidig er det en relativt ny tjeneste, som fortsatt trenger å finne ut akkurat hva den ønsker å være. Det har vært veldig spennende å jobbe med Atlas, men nå skal jeg snart bevege meg videre på nye eventyr.

Det som til tider har vært utfordrende er når det er store tekniske oppgaver som skal utføres. Da kan det fort skje at jeg som designer havner langt foran resten av teamet og jobber med oppgaver som vi ikke vet når kommer til å bli utviklet. Dette har blitt spesielt tydelig nå i det siste, da jeg er i en fase der jeg er på vei ut av prosjektet. Da har jeg innsett at å jobbe slik at jeg ligger flere uker foran teamet mitt ikke er det som er mest verdifullt. Hvordan løsningen blir kan fort ha endret seg før de kommer til oppgavene jeg skisserer. Jeg har derfor prøvd å legge bort trangen til å fylle opp backloggen med masse oppgaver før jeg beveger meg videre til neste oppdrag, og heller jobbe sammen med utviklerne om oppgavene som vi løser nå, og ikke alene med oppgavene som kommer frem i tid.




Hvilket tips ville jeg gitt meg selv i starten av prosjektet?

Designere kan også par-programmere! Noe av det jeg har lært mest av denne høsten er å sitte sammen med utviklere å designe direkte i løsningen. Det er ikke alltid like lett å se for seg hvordan noe vil se ut, uansett hvor detaljerte skisser du lager i Figma. Da er det best å heller jobbe der skjer, rett i løsningen!



Dagens designtips

The earlier we can catch potential security vulnerabilities, the better. Throughout my career, I’ve tried a few code scanning tools, and at the current time, my favorite is CodeQL by GitHub. In this brief blog post, I will share some of my experiences using CodeQL

So first and foremost, what is code scanning? Code scanning is the analysis of source code to discover security vulnerabilities as well as other bugs. CodeQL in particular, is tightly integrated with GitHub and can scan your source code as a part of your CI/CD pipeline, and you can browse the results on GitHub.

You can also run CodeQL using the CodeQL-CLI or as a VSCode plugin, but from my experience, using the CLI is quite tedious and slow. The easiest way to add code scanning is to enable it from GitHub in the repository you want to scan.

Unfortunately, the CodeQL terms of service only permit code scanning on open-source projects unless your company pays for GitHub Advanced Security. However, nothing stops you from manually scanning arbitrary source code using the CLI, but this is strictly against the terms of service.

To demonstrate, I’ve forked OWASP Juice Shop, which is already configured with a CodeQl workflow. We can see that CodeQL found 188 different issues in the source code, which isn’t surprising given that OWASP Juice Shop is intentionally built to be as vulnerable as possible.


We can then examine one of the vulnerabilities to get detailed feedback on why this snippet of code is vulnerable and suggestions on how to mitigate it.

20-Dec

Today's posts