I was also banned from claude. I created an account and created a single prompt: "Hello, how are you?". After that I was banned. An automated system flagged me as doing something against the ToS.
I recently implemented a Hindley Milner type checker. The algorithm itself is not necessarily super difficult (once you get your head around it ofcourse) but the way it is explained is. It seems like HM is mostly explained by people with a mathematics background that already know the proper notation. I wonder how much overlap there is between people that know the notation and do not know how HM works, probably not much.
Anyway nice demo. Bi-directional is already quite powerful!
Have you seen ReScript? Of course it is not as popular as typescript but it improves on all the bad parts of typescript. You'll get sound types with the pain points of javascript stripped out. Because it compiles to readable javascript you are still in the npm ecosystem.
You don't have to rewrite your whole codebase to start using it. It grows horizontally (you add typed files along the way) compared to typescript which grows vertically (you enable it with Any types).
The point is that we don't have to move back to plain js. We have learned a lot since typescript was created and I think the time has come to slowly move to a better language (and ReScript feels the most like Javascript in that regard).
If Typescript is javascript with types bolted on, Rescript is javascript with types the way it should have been. Sound types with low complexity. https://rescript-lang.org/
That syntax is so alien to me as a JS/TS developer. I mean coffeescript was as well until JS slowly introduced it all.
It would be cruel for me to force ReScript onto the team because they'd all need to reskill. I could only use it for a private project and then hire exclusively for it afterwards
Really, that is surprising to hear. There are a couple of differences but most of the syntax looks the same to me, what part do you find alien?
The reskill problem is of similiar difficulty with learning a new framework I think. Especially because the language is rather simple compared to typescript (which is also its strength).
I do understand it is an uphill battle. The whole nobody get's fired for choosing IBM thing. The language is still unproven in the general perception. I do think that when it comes to libraries and frameworks I see a lot of developers choose new unproven stuff, more then they do languages.
You might be using the webgl lines (LINE_STRIP), those are always thin. The other way is to build a mesh that looks like a line (which Three.js also has functions for). select the line type here to see the difference: https://threejs.org/examples/?q=lines#webgl_lines_fat
This looks good! It feels a little bit similiar to ReScript. I like the idea to have nodeMain, browserMain and buildMain. The Roc language had something similiar with platforms and I love that idea!
In general I prefer a better language over an involved javascript framework that does not look like js anymore.
Thank you! Yeah, I think some of the newer frameworks really complicate dataflow. We're trying to keep dataflow clear, though it's a big design space given the distributed nature of webapps.
In any case, if you take it for a spin, I'd love some feedback.
What I'm saying, say you have 3 dependent dropdown pickers, selecting an item in the first one determine which of the other 2 are shown. When you have reactive interfaces like that, it's hard to extract the common "business" logic. Either you redraw everything from scratch or you do a sort of show/hide on DOM elements as in jQuery days. Not sure how you can abstract that. If you do abstract it, you end up with backbone, vue, react, or other in any case.
You are still thinking in terms of framework goodness, which is why this is challenging for you. Don't do that. Don't redraw anything. Don't create some shallow copy, cloned node, or other insanity. You don't need any of that. You don't need to litter your code, most especially your DOM nodes, with a bunch of business logic insanity.
All you need is the event handler. The event handler can be assigned to a node's event property directly, but if this is for a commercial site with lots of third party analytics/spyware you need to use a event listener instead because those third party libraries will overwrite your event assignments. The event handler receives an event object as an argument with a reference back to the given DOM node.
All the business logic should be stored in a single location representing a given business function, typically far away from the browser logic. It makes sense when you write the code without using a framework. If you write the code and try to make it look like a framework it will look like a framework, unsurprisingly. If you don't do a bunch of framework component insanity it will not look like a framework.
This is a person problem, not a technology problem.
const myHandler = function (event) {
console.log(event.target);
};
// this is simple and easier to troubleshoot,
// but you can only directly assign one value to an object property
myNode.onclick = myHandler;
// for pages with JavaScript code from third party domains
// use event listeners instead
myNode.addEventListener("click", myHandler);
When leaving frameworks you have to stop thinking in terms of components, isolated code islands that exist only in their own isolated world. Instead think of areas of the page as parts of a larger whole. You can manage each part independently or not. You wouldn't program outside the browser using something like React, so your programming inside the browser should reflect how you would build an application if the browser weren't there.
Yes and then add few other pieces of state and interdependent components, the reactive code will extend, the manual patch job of connecting listeners and mutating DOM will start falling apart. The first example is okay for a one off but can't be reused as a component. It's also easy to get in a place where you have to update 3-4 different handlers to include a logic change. In a component based library/framework, you ideally update the state logic in one place and the UI just reflects that.
For example, making the UI dynamic with a button that adds/removes multiple items that need this show/hide logic, you would need to attach new listeners, clean up listeners, clean up DOM items, and so on... my first example was only illustrative, but not to be taken literally. There a complex UI state in many apps, and reactivity with component based reuse is easier to manage and make sure all states are covered. Many times in my jquery years 10-15 years ago I had failed to update one piece of the DOM and there would be bugs that just aren't happening with component UIs.
I agree separating your UI into components is important. If React learned us one thing it is that keeping related stuff together is the way to go. Separating into components and keeping your functions as pure as possible gives you 95% of what makes React great! You can read my answer to @iliaznk on how I do this.
cleaning up listeners or cleaning up DOM nodes is rarely needed. Just remove the component element and the browser cleans up automatically.
If you go to the React website you need to click "Learn React". A library often does not make you learn new concepts. It is just functions with input and output.
On the first page "Quickstart" all code blocks contain code that contain JSX and call you. They do not even show the part where you need to call render. Copying this code into your codebase will not do anything.
On that same page they also introduce state management with hooks.
On the installation page npm installing react is not mentioned. They suggest using create react app.
Sure you can theoratically use react as a library but I've never seen it and from the website it seems like usage as a library is not the inteded way to use react.
The first sentence "The library for web and native user interfaces" is the only thing pointing to react being able to be used as a library. The rest of it looks like a framework to me.
> If you go to the React website you need to click "Learn React".
The second library I remembered (GSAP) writes exactly that on their site.
> A library often does not make you learn new concepts
New concepts are absolutely a thing, take any library that implements any spec and in order to use that library you have to learn subject domain of the spec.
Another example is D3 (the first library I thought of), which does not exactly has “Learn D3” (quite an unorthodox way of assessing whether something is a framework anyway) but which does require you learn a bunch of concepts to use it in an educated way. Just like people do with React, you can obviously not learn these concepts and wing it, and then reap the consequences of resulting awkward code.
> Sure you can theoratically use react as a library but I've never seen it
It is not “used as a library”. It is a library. Being mistaken for a framework is why projects often get burned. People who are aware that it is a library, and use it as such, tend to not to get burned, because then you know you have to either have a simple project, or implement all the framework-y elements that it misses, usually part by strategically picking a set of other libraries to fill in the blanks and part DIY.
Show me a complex project that is not using a framework and I will show you a home-made framework.
I don't think this has to be true. If you think of a framework as a piece of code that calls you where you sort of supply it with configuration you could do that when writing vanilla js but you don't have to.
When I write vanilla js I don't have a seperate file called framework.js. There is very little code needed to manage state. Almost all functions in my codebase are doing concrete things.
I mean in a complex enough application you'll have to come up with some abstractions that will make you life easier anyway. I doubt that you will manually add and remove classes, or add and remove nodes via direct DOM API calls every time you need to do that. You know what I mean? A set of such abstractions is what I call a framework. It doesn't have to be a separate file called "framework.js". It may even be more of a library than a framework. But I believe you will inevitably come to that to centralize certain things and make them easier to do.
I do use abstractions to make my life easier. The main abstraction is a function called tag:
const tag = (tagName, props, ...children) => {
const el = document.createElement(tagName)
for(let k in props) el.setAttribute(k, props[k])
for(let child of children)
el.appendChild(typeof child == 'string'? document.createTextNode(child) : child)
return el
}
This makes the construction of new elments a bit more concise. The rest is just functions, manually adding or removing classes and adding or removing nodes via the direct DOM API.
The main advantage I think React brought is breaking the concept of "separation of concerns" (keeping css, html and js in different files even when they change together). Keeping stuff that belongs together in the same file and mostly pure is what gives the most benefit. You don't need complicated frameworks for that.
const createSpecialButton = text => tag("button", {style: "background: purple"}, text)
When something becomes a framework is a bit blurry. I consider this more of an utility function. It is only 7 lines long. You call it, it does not call you. It gives you back a concrete element, not some abstract intermediate value. It is completely optional. The amount of these utilities you need in a big project is still tiny.
I wrote a figma clone (see other comment) with couple of these utility functions. It looks a lot like a regular react project really. Mostly functions (which you might call a component if they return HTML), mostly pure or local state.
reply