I've lost track of website development techniques so hard. Last time I published a webpage I was doing plain HTML and CSS by hand and plain JS or jQuery at the most. Now they're talking about hydration, microservices, serverless, frameworks and metaframeworks... I hate abstraction sometimes
It's actually still very valid approach. With html5 custom tags you can build modern component architecture without all the bs. And IMHO it's actually much better than hydrated react that is a can of worms.
oh yes, good old jquery was so useful and if you keep it simple then is without headaches. if you wanna recover that simplicity and have a powerful type system for frontend development, use Elm, is superior to typescript, there are many options superior to typescript, like purscript and clojurescript and this thing with ocaml. with elm you can have the simplicity of multipage with little "javascript" per page, or a powerful spa.
OCaml is a hidden gem. Rust compiler was written in Ocaml. Reason (ML) was a rising star. They rebranded to ReScript, and momentum was lost. Only bad thing about Ocaml is a Windows support.
@@WillEhrendreich The problem of F# is the C# baggage. Language is nice, concise but .NET (C#) ecosystem and mindset is disaster. MS never promoted F# enough. At a long run OCaml is better.
i'll give you 3 other hidden gems to look into after this, coq, ATS and F* (f star), OCaml, (coq will help you understand how to construct proofs which ATS and F* require, and they look like OCaml) also you should know C so that you understand low level hardware stuff which ATS and F* allow you to do
20:51 Woah looking back at this now it's almost ironic. I don't know why I hadn't watched this one back then but it allowed me to see such a great contrast between his old opinion on Go (and Zig) and his new ones.
I was thinking of recommending F# in the comments, used it for 3 years, and I honestly think it's one of the best platforms out there for most things. But I'm sort of in the same boat as Primeagen, I just don't like Microsoft...
I'm hoping someone releases a good book covering modern (5.0) OCaml that does a good job of teaching the language including new stuff like Algebraic Effects. Feels like the tutorial/educational space in the language is still rough in general as someone who started dabbling with it recently (also some of the compiler errors are... unfortunate like if you forget an in on an extended let statement it just throws an undefined error instead of telling you that you need to get it in the proper scope).
OCaml is basically Haskell light. Ocaml is to Scheme like Haskell is to Common Lisp. Also OCaml just recently officially got Algebraic Effects. Insanely amazing and putting serious pressure on other languages to adopt them.
What is holding back whole functional ecosystem is the naming. Thought monads was bad enough naming? Well wait for algebraic effect! Yet another term that sounds fancy and explains nothing.
@@sk-sm9sh Naming is the hardest problem in Computer Science. If you forgive them for the names, you will have much to gain from learning Functional Programming and Algebraic Effects. I recommend to learn Algebraic Effects in OCaml as it has currently the most well integrated implementation and it does not type check it, making it especially suitable for beginners.
In our company, we decided to give ReScript (OCaml) a chance for our React Native application. After four months, it's a breath of fresh air compared to TypeScript. You could go with minimal type annotations, which gives a feel similar to JavaScript, but it has a very solid type system. Provides great features such as Tagged Unions, Pattern Matching, Functors, and GADTs, which you can utilize as needed. Creating bindings for TypeScript libraries and learning new technology is the trade-off.
I googled it, seen the home page, and the first example on a page: code that compiled to javascript with a bunch of vars and React.createelements, also 2 nested ternaries. Seems like a bunch of legacy piece of garbage to me. Can you explain how it's any better? "Compiles to efficient and human readable javascript" - yeah, hell no. They wanted it to say instead: "compiles to a bunch of garbage javascript".
@@twothreeoneoneseventwoonefour5 bro, do you understand the concept of transpilation targeting an older version of JavaScript. This is literally what Babel and TypeScript both do.
@@yawaramin4771 Transpilation is done by the build tools, not the language. From what I have seen, this language compiles to javascript that then gets transpiled by babel/others again. They advertise "effective and human readable javascript" which is just false at this point. Also caring about """older javascript""" is just laughable in 2023. "ES2015?" - "No, let's compile to ES5 which was released in 2009 and is already 14 years old, because a whole 0.0001% of our users still use Windows 7 with Internet Explorer."
@twothreeoneoneseventwoonefourfive Honestly, I haven't had any problems with compiled JS in our project. So, if you need to have beautiful JS code, then just write JS. The advantage of using OCaml exists on a different plane.
@@MrGreenteamer Even though it doesn't keep its premise, it feels good and refreshing to code in for you, I see. Understood. I guess I will try it once sometime then.
can you implement J diesel that's actually practical in performance? like work with SVN data more directly, keeping more stuff in memory, instantiating the json based crap into something intermediate and remotely usable. thrilled in anticipation to watch you outgenious the Tom himself
"React has never been built as a performance-first library" I still remember a while ago Roblox ported React 17 to Luau, it got leaked and benchmarked. Ended up being unbelievably fast and beat every other Roblox UI framework by miles, apparently almost twice as fast as native wEb devs Don't know Just How good they Have it
> almost twice as fast as native I feel I must be missing something. How is an abstraction faster than a good implementation of what it translates to? Or is that not what "native" means in this context?
@@john_paul_r I'm not very experienced with React but apparently most of the library's performance benefits came from ui updating. My best guess is it's due to the way Roblox sets up event listeners to detect when an element's properties are changed, which can cause performance issues if properties are updated many times per second, and React's virtual DOM prevents updates from taking place as often when they won't be seen by the user? It's mostly the type of performance benefits only seen in benchmarks and measured in micro/nanoseconds though Edit: Apparently Roblox's underlying C++ has several optimisations to allow the library to work faster, which makes sense given that Roblox developed it internally for their own UIs
Basically native UI components nearly always suck really bad, one way or another. Either they have no flexibility or awful performance. Especially layout is miles ahead of the standard native toolkit support. There's a reason everyone's moving to electron despite the complaints. Interestingly there's a lot of aggressive work to make fast and flexible UI toolkits in Rust, despite the language being almost designed to not be able to create UIs!
Hmm, he was testing on M1 (supposedly MacOS). That could have introduced some major inefficiencies in certain places (like filesystem access). Linux is able to significantly outperform Mac OS on that hardware for what it's worth
25:23 - Rust has nominal types with local inference. OCaml has structural types. The former is a more ad hoc and less constructive sort of system than the latter.
@@yawaramin4771 I disagree. Can you provide source or an example? I can say I disagree because if that were true, one would be able to choose to program in OCaml using solely C-like nominal types outside the Hindley-Milner machinery, which I think is impossible in OCaml (except for "magic").
@@jboss1073 first I need to understand what you mean by 'nominal types', because it is clearly not the standard definition. Nominal types means that the compiler distinguishes types from each other by name. Even if they have the same structure (definition), they are considered different if they have different names, Structural typing means that two types are considered the same if they have the same structure even if they have different names. OCaml's nominal types are variants, records, and abstract types. Its structural types are tuples, objects, polymorphic variants, and modules. [EDIT: and function types.]
@@yawaramin4771 I mean exactly what you do. How do you figure that OCaml's records are an example of nominal types? Because I can make a function that takes whatever type of record so long as it has the fields I mention in the function signature? Because that is a structural feature - think about it, you're not caring about the name of the type, only its structure, namely its having the fields I mention.
Regarding Laravel, I would also agree that it's great. Symfony is also great, but if I were to pick one, I'd pick Laravel. The bad thing about it is PHP, but the good thing is that PHP8+ is good, it's actually becoming a modern language. The issue that remains is basically that you can't have type-safe arrays without a custom class. There are also ways to add generics to PHP through an additional compile step, similar to TypeScript.
I see OCaml content, I upvote. It's one of the nicest languages in existence; build times are very low (on the order of Go) yet the code you write is orders of magnitude more solid and stable than pretty much any non-SML language, including Haskell (that's right, I said it).
More solid than Haskell? Haskell programs are technically mathematically provable. Is that true of OCaml? I’m actually asking because I don’t know. I agree the OCaml syntax is easier than Haskell though.
@@airman122469 The whole reason OCaml was created was to work with technically mathematically provable things. OCaml is as sound as SML (which is extremely solid mathematically to the point of being elegant) and Haskell itself (without all the extensions of course). OCaml is an ML, a Meta Language for constructive mathematics (!).
orders of magnitude more solid and stable than haskell is a yikes... maybe start proving useful theorems before u go that far. Ocaml is cool but its not that powerful
@@nomoredarts8918 Reason has pattern matching because OCaml has pattern matching natively. So not sure what you mean with ReScript having pattern matching and being better than Reason?
I had learned the basics of Ocaml in uni because they used it for functional programming, and I've been using Rust since around 2020. But it's only recently that I learned it was made with Ocaml at first.
Thing is often "this is very hard" we bring on ourselves. When I just tried out this "hydrated" architecture some years back on my personal project I figured it's a can of worms that better be avoided. And I only used js and react didn't even tried mixing languages but it was bad enough already. There is a rather healthy middleground that can work well for many type of apps and that is figuring out what you want to render on backend and thus bake it statically and what you wanna do dynamically. HTML5 custom tags can go long way here helping adding dynamic components from static html. And all the "this is very hard" goes away. But of course doing html5 custom tags and old school html templates aren't as sexy as running rendering React components into html on backend with OCaml and then hydrating them on client side and here we get very hard problems.
#ThePrimeTime can u keep the lines you are reading in the middle of the screen, please? Currently you scroll them so high, that the chat on the upper right obscures the end of lines, which you don't always read out loud fully.
Laravel is just a shitty copy of Rails, I have worked with both Laravel and Rails, and even with all the hate that I have for Rails I would never use Laravel if I have to chose between both of them. The thing is that PHP coders know they don't have the respect of anyone on any community, so they have to make noise about Laravel to claim "look, PHP is not trash wink wink" Long before Laravel there were "good" frameworks that wanted to have good and clean PHP, but is still PHP, and its migrations are horrible.
This is way over engineered and the performance difference are way overblown. reactDOMServer.renderToString is fast. Just have your server (in any language) run it on node and serve the string. I did this for a reasonably large sized ecomm site 6 years ago in spring.
They should have hired Tom to solve this problem.
he is the only one to save us from our javascripts
is that the same genius Tom who rote JDSL?
JDSL compiler was written in OCaml, Tom being genius once again
It was bootstrapped in OCaml; JDSL is, of course, written in itself. Tom truly is a genius.
th-cam.com/video/P1ltwweeVUQ/w-d-xo.html
❤
I've lost track of website development techniques so hard. Last time I published a webpage I was doing plain HTML and CSS by hand and plain JS or jQuery at the most. Now they're talking about hydration, microservices, serverless, frameworks and metaframeworks... I hate abstraction sometimes
everything these days either wants to be fast or wants an entreprise solution. There's simplicity in both of them.
Fists and clouds
That's cool, but many people want to learn new things for fun and to perhaps broaden their horizons.
It's actually still very valid approach. With html5 custom tags you can build modern component architecture without all the bs. And IMHO it's actually much better than hydrated react that is a can of worms.
oh yes, good old jquery was so useful and if you keep it simple then is without headaches.
if you wanna recover that simplicity and have a powerful type system for frontend development, use Elm, is superior to typescript, there are many options superior to typescript, like purscript and clojurescript and this thing with ocaml.
with elm you can have the simplicity of multipage with little "javascript" per page, or a powerful spa.
OCaml is a hidden gem. Rust compiler was written in Ocaml. Reason (ML) was a rising star. They rebranded to ReScript, and momentum was lost. Only bad thing about Ocaml is a Windows support.
Great reason to do Fsharp then, cross platform, fast, big ecosystem, just a wonderful lang .
@@WillEhrendreich The problem of F# is the C# baggage. Language is nice, concise but .NET (C#) ecosystem and mindset is disaster. MS never promoted F# enough. At a long run OCaml is better.
i'll give you 3 other hidden gems to look into after this, coq, ATS and F* (f star), OCaml, (coq will help you understand how to construct proofs which ATS and F* require, and they look like OCaml) also you should know C so that you understand low level hardware stuff which ATS and F* allow you to do
Prime must love OCaml since Rust was once written in it.
20:51 Woah looking back at this now it's almost ironic. I don't know why I hadn't watched this one back then but it allowed me to see such a great contrast between his old opinion on Go (and Zig) and his new ones.
There is a reason the blog post never mentioned F#. That’s because if you ever used oCaml and then F#, you wouldn’t go back 😂
I was thinking of recommending F# in the comments, used it for 3 years, and I honestly think it's one of the best platforms out there for most things. But I'm sort of in the same boat as Primeagen, I just don't like Microsoft...
I loves me some fsharp. Legitimately happier writing it than any other code I've written, hands down.
I was waiting for the day you discover OCaML.
OCaml deserves more love
What about my camel 🐫 in the Saharan desert 🏜️ ?
Absolutely agree! Can't wait for the OCaml arc.
I LOVE OCAML!!!
I'm hoping someone releases a good book covering modern (5.0) OCaml that does a good job of teaching the language including new stuff like Algebraic Effects. Feels like the tutorial/educational space in the language is still rough in general as someone who started dabbling with it recently (also some of the compiler errors are... unfortunate like if you forget an in on an extended let statement it just throws an undefined error instead of telling you that you need to get it in the proper scope).
@@WizardofWestmarch I can help you with that. What are your questions regarding effects in OCaml? Do you need examples?
Ocaml was (is?) also used heavily in the early days of the design of wasm.
OCaml is basically Haskell light.
Ocaml is to Scheme like Haskell is to Common Lisp.
Also OCaml just recently officially got Algebraic Effects.
Insanely amazing and putting serious pressure on other languages to adopt them.
What is holding back whole functional ecosystem is the naming. Thought monads was bad enough naming? Well wait for algebraic effect! Yet another term that sounds fancy and explains nothing.
@@sk-sm9sh Naming is the hardest problem in Computer Science. If you forgive them for the names, you will have much to gain from learning Functional Programming and Algebraic Effects. I recommend to learn Algebraic Effects in OCaml as it has currently the most well integrated implementation and it does not type check it, making it especially suitable for beginners.
What the link between OCaml and Scheme?
@@tourdesource None. I was drawing a relationship analogy.
@@jboss1073 I can't forgive because there is plenty better examples. Just because naming is hard doesn't quite give an excuse of not solving it.
In our company, we decided to give ReScript (OCaml) a chance for our React Native application. After four months, it's a breath of fresh air compared to TypeScript. You could go with minimal type annotations, which gives a feel similar to JavaScript, but it has a very solid type system. Provides great features such as Tagged Unions, Pattern Matching, Functors, and GADTs, which you can utilize as needed. Creating bindings for TypeScript libraries and learning new technology is the trade-off.
I googled it, seen the home page, and the first example on a page: code that compiled to javascript with a bunch of vars and React.createelements, also 2 nested ternaries. Seems like a bunch of legacy piece of garbage to me. Can you explain how it's any better? "Compiles to efficient and human readable javascript" - yeah, hell no. They wanted it to say instead: "compiles to a bunch of garbage javascript".
@@twothreeoneoneseventwoonefour5 bro, do you understand the concept of transpilation targeting an older version of JavaScript. This is literally what Babel and TypeScript both do.
@@yawaramin4771 Transpilation is done by the build tools, not the language. From what I have seen, this language compiles to javascript that then gets transpiled by babel/others again. They advertise "effective and human readable javascript" which is just false at this point.
Also caring about """older javascript""" is just laughable in 2023. "ES2015?" - "No, let's compile to ES5 which was released in 2009 and is already 14 years old, because a whole 0.0001% of our users still use Windows 7 with Internet Explorer."
@twothreeoneoneseventwoonefourfive Honestly, I haven't had any problems with compiled JS in our project. So, if you need to have beautiful JS code, then just write JS. The advantage of using OCaml exists on a different plane.
@@MrGreenteamer Even though it doesn't keep its premise, it feels good and refreshing to code in for you, I see. Understood. I guess I will try it once sometime then.
Another pretty cool fullstack language is Haxe. Targets C++, it's own VM, JVM, JS, C#, Java, Python, Lua and a few others.
And haxe is written in ocaml :)
21:10 - 21:14 - Elm proves OCaml is good enough for front-end as well.
OCaml is closer to Haskell than other languages
Ocaml has the best things prople usually think make rust unique but with a nicer syntax and faster compilation times
can you implement J diesel that's actually practical in performance? like work with SVN data more directly, keeping more stuff in memory, instantiating the json based crap into something intermediate and remotely usable. thrilled in anticipation to watch you outgenious the Tom himself
finally some Reason in Javascript!
agreed
I see what you did there
@@wlockuz4467 you are welcome, Sir! :D
"React has never been built as a performance-first library"
I still remember a while ago Roblox ported React 17 to Luau, it got leaked and benchmarked. Ended up being unbelievably fast and beat every other Roblox UI framework by miles, apparently almost twice as fast as native
wEb devs Don't know Just How good they Have it
> almost twice as fast as native
I feel I must be missing something. How is an abstraction faster than a good implementation of what it translates to? Or is that not what "native" means in this context?
@@john_paul_r I'm not very experienced with React but apparently most of the library's performance benefits came from ui updating. My best guess is it's due to the way Roblox sets up event listeners to detect when an element's properties are changed, which can cause performance issues if properties are updated many times per second, and React's virtual DOM prevents updates from taking place as often when they won't be seen by the user?
It's mostly the type of performance benefits only seen in benchmarks and measured in micro/nanoseconds though
Edit: Apparently Roblox's underlying C++ has several optimisations to allow the library to work faster, which makes sense given that Roblox developed it internally for their own UIs
Basically native UI components nearly always suck really bad, one way or another. Either they have no flexibility or awful performance. Especially layout is miles ahead of the standard native toolkit support.
There's a reason everyone's moving to electron despite the complaints.
Interestingly there's a lot of aggressive work to make fast and flexible UI toolkits in Rust, despite the language being almost designed to not be able to create UIs!
Hmm, he was testing on M1 (supposedly MacOS). That could have introduced some major inefficiencies in certain places (like filesystem access).
Linux is able to significantly outperform Mac OS on that hardware for what it's worth
The nice thing about trying to wake up at 7 am every morning is Prime normally has some kinda video released by 6 am my time lmfao
This is best FOrmat: just reading text from display! AMazing!
25:23 - Rust has nominal types with local inference. OCaml has structural types. The former is a more ad hoc and less constructive sort of system than the latter.
@@JorgetePanete Corrected. Thank you!
OCaml has both nominal and structural types, each can be used as appropriate.
@@yawaramin4771 I disagree. Can you provide source or an example?
I can say I disagree because if that were true, one would be able to choose to program in OCaml using solely C-like nominal types outside the Hindley-Milner machinery, which I think is impossible in OCaml (except for "magic").
@@jboss1073 first I need to understand what you mean by 'nominal types', because it is clearly not the standard definition. Nominal types means that the compiler distinguishes types from each other by name. Even if they have the same structure (definition), they are considered different if they have different names,
Structural typing means that two types are considered the same if they have the same structure even if they have different names.
OCaml's nominal types are variants, records, and abstract types. Its structural types are tuples, objects, polymorphic variants, and modules. [EDIT: and function types.]
@@yawaramin4771 I mean exactly what you do.
How do you figure that OCaml's records are an example of nominal types? Because I can make a function that takes whatever type of record so long as it has the fields I mention in the function signature? Because that is a structural feature - think about it, you're not caring about the name of the type, only its structure, namely its having the fields I mention.
Regarding Laravel, I would also agree that it's great. Symfony is also great, but if I were to pick one, I'd pick Laravel.
The bad thing about it is PHP, but the good thing is that PHP8+ is good, it's actually becoming a modern language.
The issue that remains is basically that you can't have type-safe arrays without a custom class.
There are also ways to add generics to PHP through an additional compile step, similar to TypeScript.
Here we go baby, comment support for JDSL needs some coconut oil, show Tom ThePrimagen is a genius
Tom knows OCaml
confirming i am making the right moves
I see OCaml content, I upvote. It's one of the nicest languages in existence; build times are very low (on the order of Go) yet the code you write is orders of magnitude more solid and stable than pretty much any non-SML language, including Haskell (that's right, I said it).
pretty stoked about learning ocaml
More solid than Haskell? Haskell programs are technically mathematically provable. Is that true of OCaml? I’m actually asking because I don’t know.
I agree the OCaml syntax is easier than Haskell though.
Also OCaml code runs screamingly fast as it has the most optimizing compiler in the world.
@@airman122469 The whole reason OCaml was created was to work with technically mathematically provable things. OCaml is as sound as SML (which is extremely solid mathematically to the point of being elegant) and Haskell itself (without all the extensions of course). OCaml is an ML, a Meta Language for constructive mathematics (!).
orders of magnitude more solid and stable than haskell is a yikes... maybe start proving useful theorems before u go that far. Ocaml is cool but its not that powerful
Laravel is really amazing, I swtiched completely from node to laravel and never looked back, life is amazing.
Reason React is awesome, the type system is really strong compared to TS
i want to try it real bad
Rescript even better, with pattern matching and so on
@@nomoredarts8918 it's the new naming I guess, that's good but not many teams use it !
@@nomoredarts8918 Reason has pattern matching because OCaml has pattern matching natively. So not sure what you mean with ReScript having pattern matching and being better than Reason?
8:43 JS devs are very concerned about memory? But you should never pass by reference? Not sure those two ethe are compatible.
I'm surprised to see a reference to Reason-React. I thought that was dead. ReScript uber alles, now, and all that.
First gut reaction: That sounds like a match made in hell... 😂 Let's get started.
I was reasonably surprised at the what why and how. Thanks for the enlightenment 😂
this is pretty much my arc during this too
Wait you love Rust but don't know about OCaml? The initial Rust compiler was written in OCaml.
I had learned the basics of Ocaml in uni because they used it for functional programming, and I've been using Rust since around 2020. But it's only recently that I learned it was made with Ocaml at first.
Thing is often "this is very hard" we bring on ourselves. When I just tried out this "hydrated" architecture some years back on my personal project I figured it's a can of worms that better be avoided. And I only used js and react didn't even tried mixing languages but it was bad enough already. There is a rather healthy middleground that can work well for many type of apps and that is figuring out what you want to render on backend and thus bake it statically and what you wanna do dynamically. HTML5 custom tags can go long way here helping adding dynamic components from static html. And all the "this is very hard" goes away. But of course doing html5 custom tags and old school html templates aren't as sexy as running rendering React components into html on backend with OCaml and then hydrating them on client side and here we get very hard problems.
The name is Tom is a genius
the name is thetomagen, lets go
Tom's a fucking genius!
You look like Dr. Disrespect without the glasses
I love the old desktop apps. Can Ocaml be used to develop desktop apps and mobile apps?
As cool as this is, I always feel that I still need to translate the code to js in my head, especially when working with js libraries
JOCaml… Tom smokes four packs a day, remains a genius.
Dart is full stack.
Render them pixels hard, OCaml!
Who's Tom and why is he a genius
Showed her my Ocaml face
One name: Tom
#ThePrimeTime can u keep the lines you are reading in the middle of the screen, please?
Currently you scroll them so high, that the chat on the upper right obscures the end of lines, which you don't always read out loud fully.
Are we back to ReScript?
Ah - *cough* - refs.
concatenate operator for strings:
c like syntax: +
sql: ||
ocaml: ^
reason: ++
I keep hearing learning OCaml or Haskell makes you do better with Rust. OCaml is my choice if so.
So 11 months later has @ThePrimeTime implemented this on a real server? Or worked with any OCaml?
Don’t you dare show me that OCaml is cooler than Rust, I will feel the need to switch 😭
Ocamldeznutz
Ocaml 👍😎😘😍🥰🥳
Isn't all that exists in PHP 26:12
CHADML
Javascript is trash
Laravel is just a shitty copy of Rails, I have worked with both Laravel and Rails, and even with all the hate that I have for Rails I would never use Laravel if I have to chose between both of them. The thing is that PHP coders know they don't have the respect of anyone on any community, so they have to make noise about Laravel to claim "look, PHP is not trash wink wink" Long before Laravel there were "good" frameworks that wanted to have good and clean PHP, but is still PHP, and its migrations are horrible.
Bullish on ADA
C# copied everything from java, then copied everything from haskell.
not first
first
This is way over engineered and the performance difference are way overblown. reactDOMServer.renderToString is fast. Just have your server (in any language) run it on node and serve the string. I did this for a reasonably large sized ecomm site 6 years ago in spring.
And remember thats the non streamed version. TTFB of renderToPipeableStream is even greater
create-rust-app 🗿
ahhahaah lmao
a b ->
| npm uninstall ocaml
| npm install ts-node