Framework built on top of React.
gothinkster/realworld blog example by Ciro Santilli: node Express Sequelize Next.js realworld example app.
Basically what this does is to get server-side rendering just working by React, including hydration, which is a good thing.
Next.js sends the first pre-rendered HTML page along with the JavaScript code. Then, JavaScript page switches just load the API data.
Next.js does this nicely by forcing you to provide page data in a serialized JSON format, even when rendering server-side (e.g. the return value of
getServerSideProps
). This way, it is also able to provide either the full HTML, or just the JSON.Some general downsides:
- it does feel like they don't document deployment very well however, especially non-Vercel options, which is the company behind Next.js. I'm unable to find how to use a non Vercel CDN with ISR supposing that is possible.
- Next.js is very opinionated, and like any opinionated library it is sometimes hard to know why something is/isn't happening, and sometimes it is hard/impossible to do what you want with it unless they add support. They have done good progress, but even as of 2022, some aspects just feel so immature, some major-looking use cases are not very well done.
In theory, Next.js could be the "ultimate frontend framework". It does have a lot of development difficulties that need to be ironed out, but the general concepts, and things it tries to integrate, including e.g. webpack, TypeScript, etc. are good. Maybe the question is when will someone put it together with an amazing backend library and dominate and finally put an end to the infinite number of Js Frameworks!
In-tree examples at: github.com/vercel/next.js/tree/canary/examples
In order to offer its amazing features, Next.js is also extremely opinionated, which means that if something wasn't designed to be possible, it basically isn't.
No prerender with custom server? It forces you to write your API with next as well? Or does it mean something else?
TODO can it statically generate pages that are created at runtime? E.g. if I create a new blog post, will it automatically upload a static page? It seems that yes, and that this is exactly what Incremental Static Regeneration means:However, Ciro can't find any mention of how to specify where the pages are uploaded to... this is pat of the non-Vercel deployment problem.
- github.com/vercel/next.js/discussions/25410
- vercel.com/docs/next.js/incremental-static-regeneration
- github.com/vercel/next.js/discussions/17711
- www.reddit.com/r/nextjs/comments/mvvhym/a_complete_guide_to_incremental_static/
- github.com/vercel/next.js/discussions/11552#discussioncomment-115595
- stackoverflow.com/questions/62105756/how-to-use-aws-with-next-js
- github.com/vercel/next.js/discussions/17080
- github.com/vercel/next.js/discussions/16852
Can't ISR prerenter by URL query parameters:
That plus the requirement to have one page per file under
pages/
leads to a lot of useless duplication, because then you are forced to place the URL parameters on the pathnames."Module not found: Can't resolve 'fs'" Hell. The main reason this happens seems to be the that in a higher order component, webpack can't determine if callbacks use the require or not to remove it from frontend code. Fully investigated and solved at:
Overviews:
- www.reddit.com/r/reactjs/comments/8evy5d/what_are_the_downsides_to_nextjs/ 2017 What are the downsides to Next.js?
- Physics from Symmetry by Jakob Schwichtenberg (2015) page 72
- physics.stackexchange.com/questions/172385/what-is-a-spinor
- physics.stackexchange.com/questions/41211/what-is-the-difference-between-a-spinor-and-a-vector-or-a-tensor
- physics.stackexchange.com/questions/74682/introduction-to-spinors-in-physics-and-their-relation-to-representations
- www.weylmann.com/spinor.pdf
This is where "fun" stuff is likely to be.
en.wikipedia.org/wiki/Logarithm_of_a_matrix#Existence mentions it always exists for all invertible complex matrices. But the real condition is more complicated. Notable counter example: -1 cannot be reached by any real .
The Lie algebra exponential covering problem can be seen as a generalized version of this problem, because
- Lie algebra of is just the entire
- we can immediately exclude non-invertible matrices from being the result of the exponential, because has inverse , so we already know that non-invertible matrices are not reachable
The type of feeling of confusion and distrut for your sense that some Koans attempt to instill.
Some notable references:
- kotobank.jp/word/大疑-556655 quotes passing referenes by
- en.wikipedia.org/wiki/Hakuin_Ekaku#Taigi_%E2%80%93_great_doubt mentions Hakuin Ekaku's take
DNA stuff at: human mtDNA.
This doesn't do a hole lot. Ciro Santilli wouldn't really call it a web framework. It's more like a middleware. Real web frameworks are built on top of it.
Examples under: nodejs/express:
- nodejs/express/min.js: minimal example. Visit localhost:3000 and it shows
hello world
. It is a bit wrong because the headers say HTML but we return plaintext. - nodejs/express/index.js: example dump with automated tests where possible. The automated tests are run at startup after the server launches. Then the server keeps running so you can interact with it.
Looks interesting.
It seems to abstract the part about the client messaging the backend, which focuses on being able to easily plug in a number of Front-end web framework to manage client state.
Uses Socket.IO, which allows the client Javascript to register callbacks when data is updated to achieve Socket.IO, e.g. their default chat app does:so that message appear immediately as they are sent.
client.service('messages').on('created', addMessage);
Their standard template from But it is in itself a completely boring app with a single splash page, and no database interaction, so not a good showcase. The actual showcase app is feathersjs/feathers-chat.
feathers generate app
on @feathersjs/cli@4.5.0
includes:which looks promising! They don't have a default template for a Front-end web framework however unfortunately: docs.feathersjs.com/guides/frameworks.html#the-feathers-chat lists a few chat app versions, which is their hello world:
- Front-end web framework: not built-in on generator, but there are some sample repos pointed from the documentation, and they did work out-of-box:
And there is no official example of the chat app that is immediately deployable to Heroku: FeathersJS Heroku deployment, all setups require thinking.
- www.linkedin.com/in/howelzy/Epic.
Might know a thing or two about landfills.
- www.independent.co.uk/news/uk/home-news/lost-bitcoin-crypto-james-howells-b2406517.htmlThe bizarre saga started in 2013 when Mr Howells, put the hardware from an old laptop that contained 8,000 bitcoins, the world’s leading cryptocurrency, in a black bag in his hallway.
- www.bbc.co.uk/news/uk-wales-67297013
In this section we will use the file nodejs/bench_mem.js, tests are run on Node.js v16.14.2 from NVM, Ubuntu 21.10, on Lenovo ThinkPad P51 (2017) which has 32 GB RAM.
Related answer: stackoverflow.com/questions/12023359/what-do-the-return-values-of-node-js-process-memoryusage-stand-for/72043884#72043884
First using
topp
from stackoverflow.com/questions/1221555/retrieve-cpu-usage-and-memory-usage-of-a-single-process-on-linux/40576129#40576129 let's observe the memory usage of some baseline cases.For a Node.js infinite loop nodejs/infinite_loop.jsThis gives approximately:
topp infinite_loop.js
- RSS: 20 MB
- VSZ: 230 MB
Adding a single hello world to it as in nodejs/infinite_hello.js and running:leads to:We understand that Node.js preallocates VSZ wildly. No big deal, but it does mean that VSZ is a useless measure for Node.js.
topp infinite_hello.js
- RSS: 26 MB
- VSZ: 580 MB
Forcing garbage collection as in nodejs/infinite_hello.js brings it down to 20 MB however:
topp node --expose-gc infinite_hello_gc.js
Finally let's see a baseline for which gives initially:but after a few seconds randomly jumps to:so we understand that
process.memoryUsage
nodejs/infinite_memoryusage.js:node --expose-gc infinite_memoryusage.js
{
rss: 23851008,
heapTotal: 6987776,
heapUsed: 3674696,
external: 285296,
arrayBuffers: 10422
}
{
rss: 26005504,
heapTotal: 9084928,
heapUsed: 3761240,
external: 285296,
arrayBuffers: 10422
}
First a baseline case with an array of length 1:This gives the same results as with:
node --expose-gc bench_mem.js n 1
node --expose-gc infinite_memoryusage.js
. The same result is obtained by doing:a = undefined
node --expose-gc bench_mem.js dealloc
If we use we see that the memory is now, unsurprisingly, accounted for under Results for different N:We see therefore that typed arrays are much closer to what they advertise (4 bytes per element), even for smaller element counts, as expected.
Int32Array
typed array buffers instead of a simple Array
:node --expose-gc bench_mem.js array-buffer n N
arrayBuffers
, e.g. for N
1 million:{
rss: 31776768,
heapTotal: 6463488,
heapUsed: 3674520,
external: 4285296,
arrayBuffers: 4010422
}
|| N
|| `arrayBuffers`
|| `rss`
|| `rss` per elem
| 1 M
| 4 MB
| 31 MB
| 5
| 10 M
| 40 MB
| 67 MB
| 4.6
| 100 M
| 40 MB
| 427 MB
| 4
Now let's try one million objects of type gives:Disaster! Memory usage is up to 70 MB! Why?? We were expecting only about 24, 4 baseline + 2 * 10 for each million int?!
{ a: 1, b: -1 }
:node --expose-gc bench_mem.js obj
{
rss: 138969088,
heapTotal: 105246720,
heapUsed: 70103896,
external: 285296,
arrayBuffers: 10422
}
And now an equivalent version using gives the same result.
class
:node --expose-gc bench_mem.js class
Let's try Array:is even worse at 78 MB!! OMG why.
node --expose-gc bench_mem.js arr
{
rss: 164597760,
heapTotal: 129363968,
heapUsed: 78117008,
external: 285296,
arrayBuffers: 10422
}
The idea is cool. It really unifies front-and back end.
But Ciro Santilli feels the approach proposed by FeathersJS of being a glue between bigger third-party Front-end web frameworks like React and backend (object-relational mapping) is more promising and flexible.
Timeline:
- 2021-08-02 arrested in the USA for extradiction
- 2023-11-06 Stepped down from monero Core Team
Unlisted articles are being shown, click here to show only listed articles.