71–80 of 104 posts
Please, do not build more JS frameworks (see-no-evil emoji).
You mean, you want React to continue for the rest of human history? Hope not!
Question to the folks with a lot of frontend framework experience: Is there a framework/library that supports the usage of an effect-system when it comes to rendering actions? For instance, in react, a component (or rather it's render-function) has to return the element(s) directly. Is there a framework where the render-function accepts something effect-like or promise-like instead, even if that means that the render…
I think this should be "...with a lot of React experience".
I really love Svelte. The compiler is great and very extensible. For example, you can easily add functions to the processing pipeline to process Svelte templates (or the script elements or style sections) in your own special way. It's a fantastic way to build JavaScript frameworks. Svelte people always note Svelte isn't a framework, so this isn't a framework on top of another framework! I used this to build Svekyll,…
I love svelte too but I've found it hard to integrate it in different places where I may run js (e.g. obsidian plugins, browser plugins). It was hard to configure the necessary tooling but maybe it's not sveltes fault. I think svelte would really benefit from better documentation on how to do this (and I don't mean sveltekit documentation). It was also at least non-trivial to use with typescript and even more non-tri…
I don't disagree about your typescript point. Svelte community seems to have aligned around typescript being a challenge and I do like their assertion that jsdoc+eslint is a better approach.
I really love Svelte. The compiler is great and very extensible. For example, you can easily add functions to the processing pipeline to process Svelte templates (or the script elements or style sections) in your own special way. It's a fantastic way to build JavaScript frameworks. Svelte people always note Svelte isn't a framework, so this isn't a framework on top of another framework! I used this to build Svekyll,…
Toot your horn because your project is really great. I blog with SvelteKit, and your way has many improvements galore. Thank you for sharing this!
And, as a bonus I'll share all the warts with you! It's not perfect but I love blogging with it.
I really love Svelte. The compiler is great and very extensible. For example, you can easily add functions to the processing pipeline to process Svelte templates (or the script elements or style sections) in your own special way. It's a fantastic way to build JavaScript frameworks. Svelte people always note Svelte isn't a framework, so this isn't a framework on top of another framework! I used this to build Svekyll,…
I also like svelte but as a compiler-y person who happens to be doing some JS I can't work out why I'm annotating so much stuff by hand (even with svelte 5). I can get why you might want this for react, but isn't svelte a compiler? Can't we do dataflow analysis? I'm 50% convinced there's a Chesterton's fence I'm mising but where?
Earlier quoted context omitted.
Until svelte can have a client-side router builtin, and treat SPA as its first class citizen(the way Vue.js does so far. React also shifts to SSR-SPA mixed situation jus like svelte, both are impacted by Vercel, which is really sad), instead of just focusing on its sveltekit SSR-first, I have zero interest in it. Yes I know I can customize sveltekit to do SPA, but it's very ugly and I don't need all your SSR mental l…
Or, rather than being some great conspiracy, SSR (or as we used to call it, just rendering) makes a great deal of sense. What goes around, comes around. It has always felt like the front-end frameworks, from things like Backbone to React always failed to learn the lessons of history. Preoccupied with being "new" in an area that's rapidly gaining capabilities via the browser. Re-inventing the wheel isn't difficult. Im…
I recently used a Windows 10 machine after years and I suggest you try it. It could not be more evident that Microsoft is fully betting on Web and Cloud. Windows is increasingly a thin client. Even the mail app isn’t an actual mail client now.
Earlier quoted context omitted.
Until svelte can have a client-side router builtin, and treat SPA as its first class citizen(the way Vue.js does so far. React also shifts to SSR-SPA mixed situation jus like svelte, both are impacted by Vercel, which is really sad), instead of just focusing on its sveltekit SSR-first, I have zero interest in it. Yes I know I can customize sveltekit to do SPA, but it's very ugly and I don't need all your SSR mental l…
Or, rather than being some great conspiracy, SSR (or as we used to call it, just rendering) makes a great deal of sense. What goes around, comes around. It has always felt like the front-end frameworks, from things like Backbone to React always failed to learn the lessons of history. Preoccupied with being "new" in an area that's rapidly gaining capabilities via the browser. Re-inventing the wheel isn't difficult. Im…
I just try different things in vanilla depending on the load. In terms of speed nothing can beat just serving a page rendered on the server. If you really need dynamic updates replacing dom nodes is good up to some very limited number, virtual dom and cloned nodes increase this number by a tiny irrelevant amount. If you need to update more than 100 nodes, from what I've tested, nothing beats replacing the parent node content with a html string. Sometimes inline onclick="" handlers are great compared to creating 1000 listeners one by one. Sometimes you put the listener on the parent and figure out what was clicked when it happens. I've even had cases where iframes are wonderful. At times I also put some or many hidden nodes in the html document and display them when needed.
Writing this I'm curious what the performance is for ....
https://jsfiddle.net/4ajzcfw9/
(Didn't feel like doing it right)
I like the article, but it gets some things subtly wrong. > To grossly oversimplify things: React assumes that your entire virtual DOM tree needs to be rebuilt from scratch, and the only way to prevent these updates is to implement useMemo Not quite, on a state update, it rebuilds the component that was updated and all of its children. Not the entire virtual DOM; old versions of Angular did this, but it was wasteful.…
You can definitely use useMemo with JSX elements to prevent child components from being re-rendered too often.
There's an example right in the React Hooks FAQ where it reads: "Conveniently, useMemo also lets you skip an expensive re-render of a child"
https://legacy.reactjs.org/docs/hooks-faq.html#how-to-memoiz...
AFAIK there's no magic to React.memo. It's basically a shorthand for useMemo that takes the props as the dependency.
This is a good article, but I've noticed that the adjective "modern" is used disproportionately more in the world of JavaScript, compared to other tech stacks. Is it more performant, more maintainable, faster to develop, compatible with more devices/platforms? If not, what is the advantage of being modern? That said, I'm a fan of JavaScript and have been writing it since 2001, and many of the backends I write are Nod…
I have good hopes for some disruptions to arrive on the web via wasm. There are some interesting things happening in that space that are increasingly less about Javascript, dom trees, css, and all the limitations that come with those and more about leveling the playing field with mobile where UIs are more competitive and non Javascript frameworks seem to be preferred over the poor man's choice (aka. web based).
I'm saying that as somebody actually pushing web based on mobile (we are about to release a PWA). Just acknowledging the reality that web-based is still considered a huge compromise on ux, performance, and capabilities on mobile. Good enough is the best you can say about it. Some of those mobile frameworks (flutter, compose web, and others) are now coming to the web via wasm. IMHO, there are a lot more interesting things that could be done in that space in the next years.