Funny. I liked the TypeScript being added and then removed in the TODO.
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.
Next/nuxt are an architectural dead end for me. It’s so confusing with the subtle differences between what the front lib can do and what next/nuxt can do. If you treat them as server side static site engines they’re ok, but bigger then that they’re a solution looking for a problem.
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 do really like some of their features. Any recommendations for how I can check for a cookie presence before hitting any react code and redirecting to a login screen without a content flash?
Do you have a hard requirement to separate loginapp from react app? If not, you can check many of the react tutorials about how to make a smooth login page
Until React can cross compile in Rust and spawn a browser instance in WASM with a graphql interface, I will keep making sarcastic jokes about React. /s
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.
Most of these are optional, one can stay with a very simple stack similar the LAMP stack i.e. a web server, a database and a backend language on Linux for small to mid-sized apps. And pick something simple for CI/CD.
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.
And of course, much the same thing is true for the frontend as well. Most of the time, the worst takes off frontend excess or backend complexity are being told by people who aren't working in field, and just looking in from outside.
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.
As soon as you add TS to the mix, you have to deal with TS compiler not being able to output run-ready JS (or has that changed by now?), because of JS issues with modules and you need a "bundler", yet another accidental complexity, and one that is often a nightmare to configure. Then some drive-by person will want you to minify all the things and you add another unnecessary complexity.
TS is great mostly. But it definitely comes at a cost.
I think the situation with TS has improved, but yes, I only really use it with a bundler where that isn't an issue - in this case, Vite. But typically Vite does most of the things you'll need out of the box, and I find I rarely need to think about it, so it's the sort of complexity I'm mostly happy to take on.
Don't forget that you don't need any bundlers and frameworks if you just want some reactivity, React is very minimal and works in pure JS, just alias createElement to something like el() and off you go
I'm not quite sure I'd go as far as calling React minimal, but yeah, there are definitely fairly light options here. Mithril is pretty classic as a "bare minimum framework" option. Vue can be used without any bundling/compilation steps as well, although I think that's less supported these days. I also quite like SolidJS - again, they encourage you to use the compiler, but you can also just use it with template literal strings and it should work just fine.
the SSR first trend for SPAs finally pushed me away from React(along with Vue,etc). I'm an embedded developer, I can not run node.js on the target, even MVC on the server(i.e. target board) in C or Lua could be too heavy, so SPA with restful was the best option, now all SPAs are turning into SSR-first and making things even more complex, I can no longer justify the time spending chasing the modern frontend any more, I need alternatives.
I'm trying nim for SPA at the moment, also thinking about some C based restful approach(civetweb, ulfius)
Why would you ditch react because you don’t need SSR? You can still use vanilla React without SSR and serve it statically. It’s not as if you’re forced to use nextjs if you want to use React.
React used to be fine when next.js was a separate effort, now Vercel hijacked the project, and making things even more complex by mixing SSR and CSR, there is a learning cost associated when things and concepts getting larger unnecessarily.
the newest react is now _strongly_ recommending you start a new react project using next.js, vercel hired many of the react developers for its SSR oriented business, etc.
I work with a frontend app that talks with microcontrollers that have 2mb of ram, they don't run linux and can't even support an HTTP stack. We actually use UDP to send messages to them (through a thin native layer in our app)
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.
true, the only one remains sane so far, but I'm unsure how long that will last, I lost confidence in frontend as far as keeping-getting-unnecessarily-more-complex is concerned
Sometimes I too find getting things out of hand.
I have been working as a frontend dev for the last 5 years now , tbh sometimes there are pointless discussions over the app architecture
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,
Well it's simple. Imagine a cross runner, then give him a 180K yearly package. He'd only have to bridge the distance between React and rustc, which is clearly 4 (s/ea/us/t|c)^42.
I've been out of the node community for over 5 years but this seems in line with the "hurr durr use javascript for everything!!" crew. can someone tell me if this is a parody cuz I seriously can't tell anymore?
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.
That tracks. Rauch is a funny guy. We would blast funny songs in the office during the ZEIT days. It doesn't surprise me in the least that he's embracing the meme.
Me too, but I still don't understand. This must be what it feels like to not know how computers work. I recognize some of the words in the explanation.
One clarification: client and server code are never mixed within the same file. "use server" can only be used in server files and marks code that the client can call back into.
Yes, they demo'd a component with an onClick callback that contained a 'use server' directive followed by serverside SQL query, right there in the onClick. So presumably that callback is automatically replaced at build time with some generated clientside code that posts to a dynamic endpoint generated from just that function, or something. Seems like a strange idea with lots of ways to go wrong, but I don't know enough about it to judge.
These conditional checks are an obvious sign that they’ve cleaved the rock in the wrong location.
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.
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.
In most cases, you don’t want to treat server and client code the same from the perspective of I/O since the performance characteristics are dramatically different.
Wat? Of course front and back should be in same codebase. Why on earth would you need them to be in different repos? Put them in different folders if it makes you happy but there's no need to toss stuff all over the place. They're friends. They need to talk to each other. Let them live together
it's not that conclusive, there are many other aspects in which it can be bad (security, team's workflow etc). There is however no design principle ever dictates how components should/should not be stored in the same code repo.
well you're not wrong haha. I switched to elixir for my startup so I haven't touched a javascript file in almost 4 years now. I don't feel like I'm missing much though.
At first, from the title, I thought this might be a clever solution to the problem just created out of thin air that 'official' React apps with Next now require "use client" on a large fraction of previously working modules that were always intended to run on the client by default.
The amount of complexity they add with all combinations or render modes, caches and abstraction layers is incredible. For most webapps you can just ship html or create SPA and it's fast enough. If shipping 30kB of js on first load is an issue, then send plain html.
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.
I'm a devops engineer and so am plenty comfortable building APIs, but I use next.js for front-end stuff, effectively as a more powerful "create-react-app". However, I dislike having to caution-tape over the server-side of nextjs, and I dislike having to build my own https wrapper every time etc.
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?
Definitely forms some kind of implicit argument either for or against a belief in the wisdom of choosing JavaScript as a platform for, well, anything at all. Leaning towards against
If it does, I think it’s a pretty poor argument. JS is the lingua franca of the web. The web is the platform. Frankly, I’d love it if there were some pure, high-level (but lower than the web), widely satisfactory “native” multi-platform solution with truly altruistic motives but I know of none. Serious engineering is done on the web motivated by strategic business decisions. Isomorphic JS remains a smart one that is purely independent of what you see here.
> Frankly, I’d love it if there were some pure, high-level (but lower than the web), widely satisfactory “native” multi-platform solution with truly altruistic motives but I know of none
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.
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.