131–140 of 145 posts
Earlier quoted context omitted.
I think your answer just solidifies their point since your proposed solutions are to avoid parts of the language and bolt two pieces of tooling on top.
Fair enough -- Like I said, I think somewhere under the cruft of JS is a good language, but I don't think it's as bad as OP implies.
Earlier quoted context omitted.
I think you can do anything in Redux Saga without either Redux or React.
I think you can do anything in Javascript without either Redux Saga or Redux or React.
There are very valid reasons why virtual DOM systems (and similar approaches like Svelte) are so popular: For any not-completely-basic use-case they are easier to manage and faster.
React is a popular and battle-tested choice. Once you get the hang of it, it's a well thought out system, and you can get a lot of advice and wisdom about it for free. Maybe React is so unpopular with the pedantics here because it is so popular in the real world?
And Redux is one way - not the only way - to implement a pattern that is a functional programming alternative to the MVC pattern. An alternative I very much prefer. It is extremely powerful for moderate to complex cases, and then the boilerplate can be kept manageable and appropriate for the required complexity. I found that it is performant, easy to read, easy to extend and easy to debug.
You can do all of that in Javascript, but my experience is that it is in general a lot more painful. It is harder to maintain and harder to bring other people on board. The only time this "I don't use no stinking framework" approach doesn't completely backfire is in smaller projects or when self-rolled frameworks emerge out of the "no framework" code base.
I try to keep my ego out of programming. That also means that dissing on frameworks "just because I can survive without them" isn't productive.
For those looking for powerful async coroutines in the browser: The combination of typescript+redux+redux-saga is also quite powerful. Redux-saga uses generator coroutines to handle all sorts of asynchronous tasks.
Well, you're completely OT, but I started hating frontend development exactly when redux + sagas started becoming popular. Don't get me wrong, Elm has a very similar architecture but it's pleasant to use. The idea is cool, the implementation of redux and sagas is a terrible boilerplate mess. More recently, with react hooks + async you can model something similar without having to use redux or sagas. Redux hook syntax…
Anyway, I maintain a very complex SPA, where the react+hooks+async approach (and whatever there was before hooks) backfires. Hooks like useEffect itself turn into event handlers (Chains of useEffect clauses triggering each other's dependencies, sometimes across multiple components), and component composition and rendering becomes basically a way to declare async work flows. At some point this is very hard to follow and maintain, and this is where redux and saga come in. Saga allows me to cut down on the boilerplate and define the async logic in an almost synchronous manner, once I got the hang of it. I also don't see how saga is much boilerplate when used right.
Also: Use createSelector and useSelector for almost everything. A selector doesn't just reduce the store's data, it can also perform computations and "elevate" the data from serializable stuff to fancier class instances (using 3rd part libraries). Composing graphs of selectors means extracting much of the display logic and computing out of the components, and it also means faster applications because of memoization.
But the point is you really need to use every part of the stack to find the sweet spot: Typescript (with ActionType etc), Thunks (for simpler async tasks, but optional), createAction (for typing mainly), createSelector, and optionally/ideally Redux Toolkit and RTK Query.
Earlier quoted context omitted.
Once you local js = require "js" you have direct access to the JS global object, so you can... js.global.fetch(...)
So I got a promise, then how to await it? I don't want to use then callback.
a. First build a function in JS wrapping the usage of fetch and the management of the JS Promise there. You'd use lua_yield and lua_resume to yield, and to return back to lua the appropriate value. You would, optimally, do this just once. Or maybe someone has already written such a wrapper so you would simply require it; you'd have to search around for that.
b. Once you have that, in the Lua side, you would simply wrap your calling code in a coroutine and you don't need to use any await or then or anything. Something like...
coroutine.create(function()
local r = fetchWhatever(url, ...); -- the wrapper mentioned above; you just call it
print(r)
end)
I was pleasantly surprised it loaded so fast. So I wanted to check the size of it. I opened the firefox debugger, and it went blank O_o Chrome was ok with it: it's about 220kb, which is not bad at all for a whole runtime + stdlib. Python pyiodide ( https://pyodide.org/en/stable/ ) is several Mb. 220kb is still too much to pay upfront, since I usually want my webpages to be under 1Mb, and I can't justify burning 1/4 o…
57k post Brotli. Measuring the decompressed size of your page's static text content is like measuring your static image content by the size of the decompressed bitmap the browser generates instead of the size of the PNG (or whatever format). Server side both examples should be precompressed as they are static assets.
Earlier quoted context omitted.
"with" existed in python 2. In python 2.6 in fact, like comprehension lists, decorators, generators, descriptor protocol, exotic slicing assignation, advanced nested unpacking, infinite parameters... Python was always chock-full of advanced features, people just usually don't notice because they get productive in 3 days with the basic features and don't need to go further. It's has the quality of a very smooth learni…
"with" and "defer" (Go) are nice but not crucial to me.
Earlier quoted context omitted.
A change in a library is not a change of the language. So definitely no.
Okay, will the release of C2x be a fork of the C language, since it's going to remove support for K&R function definitions (and not every such function can be rewritten to use the new style)?
Earlier quoted context omitted.
Via https://github.com/mbasso/asm-dom ? (for example). For every complex self generated challenge there is an even more complex solution?
This is a virtual domain implementation, like React, not interacting with the actual DOM like the demo in the OP. WASM is awesome, but seems like folks don't really understand it and the limitations. I bet DOM access in WASM is totally doable, just gonna be a lot harder than how this project implemented it.
Quoted from: https://developer.mozilla.org/en-US/docs/WebAssembly/Concept...