re: What is the next big thing in frontend development? VIEW POST

TOP OF THREAD FULL DISCUSSION
re: There is a difference between "writing code that will be JS" and "writing code that will be bytecode".

Well... Chrome's V8 JIT compiles JavaScript to machine code.

So you can write code that will be auto translated to JS that will be auto translated to machine code :D

Why do you need C to develop a frontend?

Have you seen the proof of concept Quake js ?

Of course I have.

Well, if I "have" to write client-side code, I want to have a strongly typed, blazing fast language for that.

ReasonML it is. But it is a bit raw (not ready for production) for my taste

But there already are strongly typed languages you can use to write frontend code and V8 (and other VMs are more or less on par) is fast.

You just need to give them a try instead of waiting for the "perfect" solution ;-)

I am evaluating Elm (which is not strongly typed AFAICS) as a JavaScript compiler, to be honest...

Strongly typed is ambigious term. Elm is statically typed and from ML family, so it most likely sound system (haven't seen formal proof).

Elm solves other problems than C, but - as of today - it is one of the least painful options to write client-side code.

I love javascript, but there have been so many times I wanted to have c to write some custom performant code hacks. I could care less about the types. Having pointers however and not dealing with all these deep cloning hacks and different things would be amazing. Plus would be able to roll my own data structures that are way better that whats built in.

what about elixir and phoenix? they claim some impressive performance.

@moreurgentjest well, you can't use them on the frontend. The browsers only understand JavaScript. You might be able to compile some Elixir to WebAssembly but I'm not sure...

BTW Phoenix is a server side framework...

code of conduct - report abuse