React use C
github.com
github.com
I've been working with the web since before JS and CSS existed, back in the cgi-bin days, and have somehow ended up still working with it to this day.
I used most of the pre-SPA frameworks, when everything was what is now being referred to as "SSR".
Then I was dragged (somewhat kicking, screaming, and muttering about 'kids these days') into the world of SPAs, except I ended up on the Angular side and have not really been on the React side.
I will say that I have been following along with this Next.js stuff and the other changes going on over in the React ecosystem, and I am left utterly confused while at the same time having an uneasy feeling about the whole thing.
It's not necessarily because we've seen all this before, it's more about "why now?", and then wondering about how badly this is going to be abused, because if it can be, it will be. I get it, people need SEO, FCP times need some help ... and ... well that's about what I came up with off the top of my head.
Have you ever seen a SQL statement that JOINs 20 tables in your a component, that uses a magic string to indicate that it is not your ordinary component? You will.
Naturally, almost anything can be used in ways it should not be. But when you are combining the dominant SPA framework, blurring the lines between the front and back ends, and employing a large amount of fairly complex magic behind the scenes to make it happen, I get the sense that bad things may be afoot.
I for the moment am content working with a different framework, it's been smooth sailing for a complex enterprise system. I'll see how the rest of this unfolds from afar.
I implore people to try liveview though, doing everything (pretty much) on the server is incredible. So powerful and no headaches about leakage or security of APIs or whatever - all data is in BEAM/elixir process state unless you render it into a template or explicitly send it to the client in an event.
I started as a front-end dev, focused on that in the 2000s as this was where the work was interesting...
Now I go by back-end dev, because I just can't deal with the front-end "industry" anymore.
All the best, though.
what does that mean
Of course if you are into enterprise or 'web scale', things can get a bit more complicated, but it's how complicated you make it to be.
Rendering everything on the server and adding a bit of Javascript along the way works - it had its flaws, but so does everything else, you just need to figure out which flaws make sense for you to deal with. For a little extra complexity, use Vite as a bundler, and add a framework - Vue is pretty simple to get started with - and you're almost immediately away. You even get some stuff like Typescript for free at this point.
And like you say, you can make things more complicated with various other tools, but if you need that, you probably know you need that, and you know what it's doing and why it's necessary complexity.
TS is great mostly. But it definitely comes at a cost.
I'm trying nim for SPA at the moment, also thinking about some C based restful approach(civetweb, ulfius)
Why do embedded developers pick really resource-constrained chips, when decently powerful chips that can run Linux have become so cheap?
[1] probably even cheaper if purchasing B2B, in bulk
[2] i.e. should have enough CPU (1 GB) and RAM (512 MB)
I don't remember the exact numbers as I don't work with the manufacturing side but the budget for our microcontrollers was <0.5 USD per microcontroller
> Why do embedded developers pick really resource-constrained chips, when decently powerful chips that can run Linux have become so cheap?
1) Often you have multiple microcontrollers per device
2) It just follows a general trend with industrial manufacturing of always trying to find ways to cut costs. It is not just microcontrollers, after a product is finished, v2 will always strive to cut costs and be cheaper. Components costs grow linearly with production volume. If you sell a million of devices with a 5 USD chip that is 5 million dollars that could have been spent on R&D (maybe like 5 devs working on it full time for a year)
3) Sometimes the microcontrollers are dedicated for security/safety, those you don't want to run linux on because it makes them harder to QA and certify (non determinism doesn't play well with safety). You want them small, lean and as simple/dumb as possible
4) Sourcing problems, advanced chips are harder to source in higher quantities, especially lately. Crappy microcontrollers can be bought like buying legos at the lego store
5) Size, reliability and heat constraints. Bigger chips are harder to integrate into a custom board, require more power and could generate enough heat to cause problems. Integrating a Raspberry CM requires a custom connector with like 50 wires or so and wiring it can be really annoying/error-prone
One of our systems had a Raspberry CM3 before, it was the first thing on the chopping block for the v2. Apparently it was the most expensive single electronic component of the whole system.
There are other things to consider, like power consumption, size, reliability, IO... It's a totally different class of hardware.
at work, our backend is c++ and we use react without nextjs or any ssr. if we don't need it, we don't use it.
for 90% of the cases it is simple React SPA app + REST APIs , thats it and then people try to put SSR there and what not which tbh is not required even from a business pov.
It takes the joy out of things.
Although i hear folks say the same about backend , but honestly i have not done backend so cant comment about that,
planning to move though
You just don't use javascript enough in your life.
The context here (as I understand it) is that Next.js, a popular React-like framework that allows (in a way) coding both the server and browser portions of a web app in one codebase, such that each portion is extracted at runtime and automatically wired up via API calls. This is a simplification but it's how you can think of it.
They've now introduced an even tighter way of introducing server code into what are otherwise frontend React components by piggie backing off the old "use strict" directive syntax, called "use server", allowing you to interleave - directly and inline - the client and browser code.
Many a meme have been created, half-jokingly comparing it to PHP, ranging from the supportive jest, to the very seriously critical, as one would expect the internet to do.
Some of those memes have been in the form of "use ___", such as "use binary", "use php", etc.
I don't use frontend frameworks much these days so maybe someone can correct me on some of this, but hopefully this helps explain it a bit.
https://nextjs.org/docs/app/api-reference/functions/server-a...
These conditional checks on server state exist because they didn’t create the shared environment between web server and web browser at deep enough of a level.
The key is to replicate the server-side pattern of “user actions cause HTTP request”. That is, you make a version of express that runs in the browser. Then you make parallel middleware that runs in both the browser and the server. Then you make your React components fire off mock HTTP requests that are handled by the browser express router.
So you write the same route handlers and components for the browser and server to run but then you write environment specific middleware.
Browser middleware:
https://github.com/williamcotton/williamcotton.com/tree/mast...
Server middleware:
https://github.com/williamcotton/williamcotton.com/tree/mast...
I’ve expanded beyond express in the above application to add controllers, a routes file, and views, all code that has no conditionals and runs in both the browser and server environment.
What NextJS demoed is poorly conceived. There’s no need to autogenerate a link to an API.
Instead, your frontend middleware has req.update() defined to make an API request and the server middleware has req.update() defined to make the SQL update. GraphQL pairs well with this approach, but so does something like Graphiti/Spraypaint for a more traditional ORM-like model.
And there you go, sane server and client side rendering.
https://twitter.com/dan_abramov/status/1717648341234778376
The html for the button gets SSR and sent to the client. The button click handler is an RPC that runs the actual sql statement on the server.
Well, it takes very little knowledge to know this isn't a good design paradigm.
https://samgen.vercel.app/GYVwdgxgLglg9mABAITnA1gWwIYCd0AUA3...
The real takeaway. Love it. Hate it. All at the same time.
> Add typescript support
> Remove typescript support
Beautiful
I tried nextjs and for a simple site with few pages and echo endpoint it creates like 2MB of javascript. I could make the same result in 100 lines of code but apparently it's not fast or modern.
The issue is that static file hosting and effective servers don't generate money for infra providers. So better run some js cluster** to get a login form for client.
Is there a good / popular front-end focused nextjs alternative that doesn't make it a massive pain in the butt to crank out a react app? Am I doomed to make my own create-react-app wrapper?
Nice
I want to say "WebAssembly" but that isn't it at all, since you're talking about the web, not JavaScript. The hypothetical platform you're talking about could use webassembly but that would be besides the point.
Does a low-level version exist? Say, OpenGL?
Ah yes more non-portable code.