It's essentially if used correctly a more mature and in my opinion syntactically Superior version of something like HTMX not to mention things like SQL just work.. And it's not JavaScript.
JS memory management is incredibly optimized. You could argue that JS syntax is bad, but it's based on the syntax of the C family, like the majority of languages, so you'd be voicing an unpopular opinion.
By default yes, but you can use workers for additional threads. And the runtime engines JS runs in are multi-threaded. So even if you aren't using workers, your code gets run as efficiently as possible by the engine.
He told about that situation in other comment:
[https://www.reddit.com/r/ProgrammerHumor/comments/1dbro5d/comment/l7uacap/](https://www.reddit.com/r/ProgrammerHumor/comments/1dbro5d/comment/l7uacap/)
Besides... it's internet. There's always a person who wants to send you suicidal reports/threats.
Meanwhile, Laravel Livewire Volt & Laravel Folio.
If I didn't already know PHP and Volt/Folio, I'd learn React to use Remix. It's a nice paradigm for small & medium projects (maybe even big ones, but I can see it getting complicated, not sure though!).
I love how people dont have any idea of what frontend means.
User facing is frontend. Client or server side processing is irrelevant. The document(/web app) are user facing. This also includes CLI's, exports and emails (imagine changing a SPA route and gaving to ask backend to change the email template accordingly, coordinating the release, that is if FE is aware of the email).
@vercel/postgres actually [transforms](https://vercel.com/docs/storage/vercel-postgres/sdk#sql) your sql string into parametrized queries to prevent sql injection
This is actually one of the worst things about the JS ecosystem right now. It's not apparently clear what's front-end and what's server-side. It's pretty easy to accidentally get them mixed up.
Ya everybody here thinks they are clever thinking this is an injection risk… they should look up the tech being discussed.
https://vercel.com/docs/storage/vercel-postgres/sdk#preventing-sql-injections
I dont understand, we ran away from server side rendering put design on front end. And now server side rendering is back for react and stuff ? What is the purpose there ?
I commented the exact same thing on the /reactjs sub. I got hundreds of downvotes, multiple colorful insults by PM, and a few suicide notices.
I started my career in 2000, I've seen all those mistakes done and fixed and then... re-invented by React... smh
Mistakes recognized as mistakes over a decade ago when those devs were in diapers? meh, let's try it again. As you said, I'm sure i'll end muuuch better this time around lol
I can't assume anything about your knowledge of the tech in the OP, but I'm not surprised the dismissive attitude wasn't well received. Some mistakes are being repeated, but that's somewhat inevitable when you try to learn from past mistakes, without throwing out what works & starting from scratch. I'd rather risk that, than do everything in plain HTML/JS, just because more complex solutions come with their own problems. Get with the times, okay boomer, etc etc, think I've got it all out my system now :P
I’ve been a web dev for only 10 years and already gave up on following the latest trends, as it always comes back to whatever was used even back then, just with a different wrapper
Tbh PHP as a concept is not that bad. But the language, the syntax and the standard library are awful. I think we reinvented the wheel multiple times over the last 15 years to built PHP without PHP.
And before you respond with the usual PHP talk. No, I'm not talking about PHP 5. I'm talking about PHP 8. Yes, I know its better than PHP 5 but that doesn't make it good.
I myself quite like PHP, I enjoy writing it, for me it is a nice middle ground between very OOP and type safe languages like C# or Java and “simple” not so type safe languages like js or python.
I can see that the standard library could be improved but I also don’t use it that much, so it isn’t much of a problem for me.
Yep, was referring to same. Python is at most a bash replacement. a bash++ and nothing more.
Edit: it's an improvement over shell script, nothing more. A 2k line code will look terrible in python to maintain (even by php's standards)
Enter Erlang, who has a built-in database (Mnesia) and uses list comprehensions to query it. I will never swear fealty to any tech stack that has more layers than a spit cake.
Can't say about others' experiences, but I hated the DBMS. Besides, our deployment was volatile, an in-memory db, which made troubleshooting painful at times.
Maybe I would've come to like it more if I had spent more time with it, though.
Joking aside, it has lots of quirks and requires you to basically adopt a new mental model to work with it comfortably. First and foremost, it's a truly embedded database, so if you want to use with something other than a BEAM lang, then prepare to do a lot of message passing. Also, while you can use it on one node alone, it really starts to shine when you distribute it over a cluster, though netsplits can happen and will become a pain if you don't have the right measures put in place. I would never, *never* keep critical data in Mnesia without a Mnesia-independent backup such as an ETF file in a S3 bucket (On a sidenote: While Mnesia can do backups, they are weird and ETF is much more pleasant to work with).
I use it for small, hobby projects and for caching / memoization. For this sort of things, it completely substitutes both SQLite and Redis for me. Another thing is that I hate having to spin up a dummy Postgres during development, so I use Mnesia instead. I also wrote my own bindings with full-text search support and a couple of other goodies.
They used to teach about OSI reference model, separation of concerns, and all that gobbledygook you needed to understand in order to make a decent living in the fledging web tech field.
And just like that, all that theoretical bullshit is just waved aside and we're left with this nonsense technology salad rife with vulns and potential maintenance issues.
This is not frontend and the example screenshot is obviously simplified so that it can fit onto one clearly readable image. You can - and as it grows, inevitably must - do all the gobbledygook on real projects.
It is not simplified, but it is serverside rendered. The sql command will run but only on the backend, returning an html response to the frontend. It's one of NextJS' features
By simplified I meant that it just showcases a basic implementation without abstractions and other practices which whould make it easier to maintain and develop in a real project. Its purpose is to simply show how you can interact with the DB on the server side in nextjs, but people - who usually don't even understand whats going on on the screenshot - have been criticising it for like a year because it doesn't include all the architectural gobbledygook a real project would require.
This line of reasoning was already lame when they announced this feature. Now its lame and outdated.
It's not front-end, but the reason everything exists in JS today is because it's the language that's most commonly used by beginners since all the courses were taught in it. So people started doing everything in Javascript.
I think you kind of missed the point - I was not commenting on specifically this example being front-end, but the reason for so many hackish projects existing today.
Nah. That’s some elitist at bullshit.
The trashiest, most unmaintainable, fuck-you code I’ve ever encountered was made by CS majors high on their own supply.
Some of the best, most straightforward, encapsulated, and composable code I’ve had the pleasure of using was made by theater majors.
Separation of concerns does not mean you have to split your code "horizontally into client and server parts. Quite often for business-related applications it's better to split app by features.
The end goal is to group things that change together at one place, and split away things that change at different times.
And separation of client and server code does achieve exactly the opposite in the majority of cases (from my experience): when you want to add a new feature or tweak an existing one it predominantly requires changes on both client and server.
Regarding vulnerabilities - I completely agree. It's very easy to leak server state to client, when it's all accessible and "magically" transmitted to the client.
That requires a real good solution, and modern frameworks are far from that imo.
The issue is that the minimum requirements for doing web development and even finding a job are way too low. Teenagers start learning JavaScript and PHP yolo mode from some bad tutorial and never actually make the effort to study programming. That's how you end up with React being the most used front-end library.
No, you end up with React being the most used front-end library because *it's actually nice to use, and was way ahead of it's time in terms of the developer experience it offered*. Yeah, there are frameworks now that you could point to and argue for whatever reason this is better than React, but you forget React cemented it's place a decade ago when the alternatives for interactive web UI was shit like Angular, Knockout, Vue 1.x etc, or god forbid just some arbitrary scripts full of event listeners and direct DOM manipulation loaded on top of whatever MVC framework people were still clinging onto at the time, which frankly all fucking sucked in comparison.
Buddy, I've been studying React lately, it's the most stupid and complicated thing I've ever seen. Half your code is declaring state accessors and modifiers, which you just don't have to do in Angular because we have correctly implemented dependency injection. If you think Angular is shit, it's a symptom that you don't know what you're talking about and that you have very little knowledge in programming. I wouldn't even be surprised if React was actually a joke from Facebook, maybe they were drunk, thought about all the things a front-end developer needs in his daily life and figured out the most stupidest way possible to implement it.
Jesh, every time the subject comes up the React idiots parade has to intervene. You guys need to understand one day that you're just not actual developers and have no saying in this kind of debate.
It's technology spaghetti soup. While it looks simple to read and develop if you think of this one file, in reality it's actually a pain in the ass. A big pain. As it says in the post "untold hours wrangling them together". It's like 6 different platforms connected to each other and 20 code files to edit in all. Also probably a high mental load to how it all hangs together.
I am a full stack and I've done projects with things like HTML/CSS/JS/React -> GraphQL -> NodeJS -> PHP monolith backend -> MySQL and that was a hassle for just medium size pieces of work. You need two to 3 monitors and lots of windows open. I can't imagine 6 layers as well. It grows out of control to maintain. Back in the day we'd have vanilla JS -> PHP -> MySQL and it worked _perfectly_ fine, no reason to change. 3 is enough. Let's go back to 3 layers.
The code in the image isn't vulnerable to SQL injection. The feature used to archive that is called *tagged template literals* in JavaScript. Java is in the process of introducing a very similar feature called *string templates*.
Yes, understandable. After years of variables in SQL statements being a instant red flag, this may seem very odd. The "trick" of tagged template literals is, that the template is never converted to a string by the language. The `sql` function gets the interpolated variables separate from constant parts of the template. It can than decide itself what to do with the variables. So, the `sql` function may just escape all variables before creating the query, or what I would guess is rather happening, create a prepared statement with placeholders for the variables, and setting the values for the placeholder afterwards.
I'm not a PHP dev but honestly this looks like early 2000's PHP with extra steps.
Can't wait for all the people telling me why it isn't. But I suspect that early 2000s PHP might actually perform better.
I didn't say on 2000s hardware. Node is really really slow and resource intensive. I just got through rewriting a job from Node to Golang and it went from 15 minutes to run and often crashing the server to running in 11s.
2000s PHP was made to run on next to no resources and I bet it would run this kind of workload blazingly well on today's hardware and OSes.
Also the code would look very similar too. I would really love to see a comparison.
here is a snippet from Stackoverflow.
$connection = mysql_connect('localhost', 'root', '');
mysql_select_db('hrmwaitrose');
$query = "SELECT * FROM employee"; $result = mysql_query($query);
echo "
"; // start a table tag in the HTML
while($row = mysql_fetch_array($result)){
echo "
I'm so sorry, I should have added the /s to the comment, it was a joke, though I do believe a 2000s PHP website would be faster than RSCs.
I agree the kind of JS in the server shown in the post is utterly insane from a performance standpoint, just layers and layers of abstractions and overhead, a simple hello world gave me less than 50 rps last time I tested. People have gotten so used to just throw money at the problem of performance that using something so slow seems reasonable to them, meanwhile a Go server on a $5 vps easily handles 10k rps.
Wow those are insane numbers indeed.
I am no fan of 2000s PHP, it was a mess. (I believe they cleaned it up a bit now) But it was certainly tried and tested so it can't be ignored.
I just don't understand how we could have fallen so far. When node came out it was such an interesting project. But maybe it has been over embraced by the webdev community who are just too used to using somebody elses CPU.
Which brings up the question of how many terrawatts of energy this planet must use just from inefficient browser code.
That code is just a simplified version of what Next.js can do, is server side and in a real project you would do some abstraction instead of writing SQL inside the component, also the sql template tag is not vulnerable to SQL injection attacks.
There's a lot of people in this comment section jerking themselves off because they think abstraction is bad and they also hate React and JavaScript and PHP and server side rendering...
They're teaching me Node with Express at University too. And that's probably the only web dev related class I will have, since my major is more focused on theory.
(1) writing an entire application in only one language is a good experience and minimizes context switching (2) typescript is an actually good language and if you’re smart you’ll use it instead of js when writing next js code
Meh, the context switching argument doesn't really make sense to me. There are differences between the browser and node APIs - and plenty of people I've worked with have really struggled to understand where the code they're writing will be run with nextjs. Figuring out where code will be run and the minutiae how it impacts on what you have available to you is more of a switch than just using another language where you can also benefit from reduced compute costs (if it's a compiled language) and a type system that's built into the language
This sub can get super annoying with one-note "javascript bad". Seriously, no one is writing anything serious without TS. Ignoring that an astronomical amount of effort has been put into making JS performant on the server, the DX of typescript with isomorphic code is worth any perf hits anyway in 99.9% of applications. And for those coming from making SPAs in react, having a batteries included means for making SSR apps in a language and framework they're familiar with is awesome.
Seriously, I’ve developed apps for mobile and web with a handful of different technologies, and those it has its quirks nextjs with typescript is probably the best DX I’ve had with anything
I love how nodejs guys tell each other that ORM is slow bullshit and query builder is the way. The thing is that there is no good ORM in node world, so they have to hate the whole pattern.
Why are they string concatenating the id instead of passing it in as an argument?
This given example isn’t an argument against NextJS, it’s a showcase of incompetence that can be made in any sql code regardless of framework.
See my further edits. It is not my repo, just one that I found. I understand how the sql template works now. That being said, I don’t personally like it because it does let irresponsible developers hang themselves like in that repo I linked.
Genuine question: why do you use GraphQL then GRPC together for the same db service call from the client? Or do they mean GQL calling a standalone service, then that service does some GRPC call to another service which maintains the DB?
Why though? This is rendered only on the server side, and if you know more about Vercel Postgres library, it escapes the quotes and semicolon and stuff to prevent SQL injection.
This is how React works. You write components and components to do their own data fetching and data refreshing. You could argue that likes are not dynamic, but if there's no requirement for live like counter, this code looks good.
If your only criteria for code entering production is that it’s not a glaring security vulnerability then sure. I have never worked on an application so simple that a technical decision like this does not come back to bite the maintainers in the long run. Maybe it’s my expertise and experience, but this lack of separation of concerns between responsibilities is a bad idea especially long term.
I think they've assumed you're talking about the SQL statement, because that's the only thing to pick up on here. Everything else in the code example looks hardcoded in 1 file for demonstration purposes.
It's modern web development. The separation of concerns is no longer the model view controller, but it's each component on its own. When I ditched Django (MVT) and Rails (MVC) for React, I was appalled too. But it slowly grows on you.
It's really suitable for small teams with only full stack devs. The frontend team no longer has to wait on backend devs to expose an API to allow the front end to fetch and show data.
I think your concern was like: what if I changed the models or the way models store data, and in those cases, I believe the changes would be spread across files in React, but mostly colocated in MVC apps. But still, the amount of changes are about the same.
I never said MVC, you did. Do what you want on your projects, but I have never worked on any project so simple that it could be maintainable in this form. There are reasons we have people with expertise writing backends.
This example has fucking DAL stuff smeared all over the presentation code. Every time your DB schema changes, you get to go on a regex hunt and read through all the hardcoded queries in your codebase to find the ones that reference the changed structure.
If your project is big enough that you need Regex to find SQL queries, you use an ORM. With Typescript, a change in the model will highlight all type errors throughout the project.
Again, I don't understand why we have to separate DAL from the presentation layer. You are building components in React. Think of each component as a Lego brick you add to the build. It's separation of functionality rather than concerns.
Preventing SQLi with escapes, [where](https://www.php.net/manual/en/function.mysql-escape-string.php) have I heard this [before](https://www.php.net/manual/en/function.mysql-real-escape-string.php)?
so... the DB query in plain SQL is embedded in an HTML template or something?
I mean I know PHP is a thing but I thought everyone who doesn't write WordPress extensions tried really hard to avoid that.
Here I am working in an mnc thinking I would learn some best practice and I see this… not sure if I should be glad that it is quite common across other companies…
These are both true.
Web dev is becoming so complicated for no good reason.
But also, we found ways to make this less complex.
I'm just wondering if this is just a self inflicted problem.
Please tell me this is server side rendered.
Yes, fortunately it is
I love how frontenders reinvented backend.
Exactly this, is just same old backend being rediscovered again and again
This is exactly what PHP is doing, and doing alot better. Yet people keep ranting on it just BCS they don't know how good it is
Is there anything in particular someone with no php background should look at? Sell me php.
Laravel is all you need for a start
What can laravel do that rails or adonisjs cannot do?
In this case there is nothing you can't do with c assembly etc. Just bcs you asked, laravel breeze would render them no competition.
Symfony was always superior... Ehm.. Modular!
It's essentially if used correctly a more mature and in my opinion syntactically Superior version of something like HTMX not to mention things like SQL just work.. And it's not JavaScript.
.NET slaps PHP across the field, though.
PHP doesn't manage memory well and the authors made annoying syntax choices.
I would say the same about JS…
JS memory management is incredibly optimized. You could argue that JS syntax is bad, but it's based on the syntax of the C family, like the majority of languages, so you'd be voicing an unpopular opinion.
Out of interest, is it still single threaded by default?
By default yes, but you can use workers for additional threads. And the runtime engines JS runs in are multi-threaded. So even if you aren't using workers, your code gets run as efficiently as possible by the engine.
One of those is subjective but you would be objectively wrong about the other
The industry beat is just finding new ways to concatenate strings.
Shhh the /reactjs will hear you and hunt you down! Don't you dare criticize anything about react, that's how you get suicidal reports (true story lol)
Context pls?
He thinks we JS developers give a single flying fuck about him using PHP
He told about that situation in other comment: [https://www.reddit.com/r/ProgrammerHumor/comments/1dbro5d/comment/l7uacap/](https://www.reddit.com/r/ProgrammerHumor/comments/1dbro5d/comment/l7uacap/) Besides... it's internet. There's always a person who wants to send you suicidal reports/threats.
Tbh its the benefits of frontend (interactive js components) with the benefits of backend (direct server calls without weird querying behaviour)
Meanwhile, Laravel Livewire Volt & Laravel Folio. If I didn't already know PHP and Volt/Folio, I'd learn React to use Remix. It's a nice paradigm for small & medium projects (maybe even big ones, but I can see it getting complicated, not sure though!).
\> see SQL query \> "reinventing backend"
I love how people dont have any idea of what frontend means. User facing is frontend. Client or server side processing is irrelevant. The document(/web app) are user facing. This also includes CLI's, exports and emails (imagine changing a SPA route and gaving to ask backend to change the email template accordingly, coordinating the release, that is if FE is aware of the email).
With the sql injection option available? Tell me which website
It is. It's React Server Components
Impossible, since 'likes' can be dynamic... Bobby tables is rapidly approaching your location
'likes' is constant variable defined on the line 3.
@vercel/postgres actually [transforms](https://vercel.com/docs/storage/vercel-postgres/sdk#sql) your sql string into parametrized queries to prevent sql injection
This is actually one of the worst things about the JS ecosystem right now. It's not apparently clear what's front-end and what's server-side. It's pretty easy to accidentally get them mixed up.
> What's prepared statements?
Ya everybody here thinks they are clever thinking this is an injection risk… they should look up the tech being discussed. https://vercel.com/docs/storage/vercel-postgres/sdk#preventing-sql-injections
The problem isn't injection. The problem would be if they were exposing their DB credentials to the client-side.
Great concern. Look into how this tech works, though. (RSC / next app dir) That code is run server side and does not enter the client bundle.
looks like php 15 years ago. this will obviously end much better this time
It's funny how we've come full circle from PHP, jQuery, fetch in JS, and now modern web frameworks move rendering back to server side
I dont understand, we ran away from server side rendering put design on front end. And now server side rendering is back for react and stuff ? What is the purpose there ?
SEO its always SEO
To support the right solution (but poorly) for people with skill issues.
the purpuse is to torture you, they recreated all the bad practices of php using other really badly designed language which is javascript
I have been saying this for years and I am so glad now to see most other people are laughing at the same joke now, finally XD
Modern PHP doesn't do this and HTML over the wire based JS frameworks like Stimulus are quite popular there.
I commented the exact same thing on the /reactjs sub. I got hundreds of downvotes, multiple colorful insults by PM, and a few suicide notices. I started my career in 2000, I've seen all those mistakes done and fixed and then... re-invented by React... smh Mistakes recognized as mistakes over a decade ago when those devs were in diapers? meh, let's try it again. As you said, I'm sure i'll end muuuch better this time around lol
hell yeah how can you do things without 10 spring beans in the middle!
What if we make a framework to manage the boilerplate for our framework's bloat?
I can't assume anything about your knowledge of the tech in the OP, but I'm not surprised the dismissive attitude wasn't well received. Some mistakes are being repeated, but that's somewhat inevitable when you try to learn from past mistakes, without throwing out what works & starting from scratch. I'd rather risk that, than do everything in plain HTML/JS, just because more complex solutions come with their own problems. Get with the times, okay boomer, etc etc, think I've got it all out my system now :P
I’ve been a web dev for only 10 years and already gave up on following the latest trends, as it always comes back to whatever was used even back then, just with a different wrapper
Or like ASP on an access file 25 years ago.
We still use ASP, i do this stuff weekly.
PHP is also still used
Tbh PHP as a concept is not that bad. But the language, the syntax and the standard library are awful. I think we reinvented the wheel multiple times over the last 15 years to built PHP without PHP. And before you respond with the usual PHP talk. No, I'm not talking about PHP 5. I'm talking about PHP 8. Yes, I know its better than PHP 5 but that doesn't make it good.
yeah, if we dont really take language, syntax and standard library into consideration then php is cool
I myself quite like PHP, I enjoy writing it, for me it is a nice middle ground between very OOP and type safe languages like C# or Java and “simple” not so type safe languages like js or python. I can see that the standard library could be improved but I also don’t use it that much, so it isn’t much of a problem for me.
Well it's better than js/python Edit : For better languages, it's Java , C#. Not ruby/python/js.
No it's not
Python? Really?
Well..yep..
Dude how is Java a better option than Python 😂
That you will understand after working on a big enterprise production app.
I mean specifically for web development.
Yep, was referring to same. Python is at most a bash replacement. a bash++ and nothing more. Edit: it's an improvement over shell script, nothing more. A 2k line code will look terrible in python to maintain (even by php's standards)
Lmao
It looks like PHP but if you dig deeper you will find this gives you far more control over the client
php but the site doesn't have to have custom rando ass bindings to get client side stuff working
Enter Erlang, who has a built-in database (Mnesia) and uses list comprehensions to query it. I will never swear fealty to any tech stack that has more layers than a spit cake.
Mnesia gives me PTSD flashbacks
If by PTSD you mean "**P**owerful, well **T**hought-out & **S**calable **D**esign", then I am with you.
Precisely. We at "**F**unctional **U**nified **C**oncurrent **K**itty **I**ntegrated **T**echnologies" used it extensively.
Ok I'll bite. What's so bad about it? Is it data migration?
Can't say about others' experiences, but I hated the DBMS. Besides, our deployment was volatile, an in-memory db, which made troubleshooting painful at times. Maybe I would've come to like it more if I had spent more time with it, though.
Joking aside, it has lots of quirks and requires you to basically adopt a new mental model to work with it comfortably. First and foremost, it's a truly embedded database, so if you want to use with something other than a BEAM lang, then prepare to do a lot of message passing. Also, while you can use it on one node alone, it really starts to shine when you distribute it over a cluster, though netsplits can happen and will become a pain if you don't have the right measures put in place. I would never, *never* keep critical data in Mnesia without a Mnesia-independent backup such as an ETF file in a S3 bucket (On a sidenote: While Mnesia can do backups, they are weird and ETF is much more pleasant to work with). I use it for small, hobby projects and for caching / memoization. For this sort of things, it completely substitutes both SQLite and Redis for me. Another thing is that I hate having to spin up a dummy Postgres during development, so I use Mnesia instead. I also wrote my own bindings with full-text search support and a couple of other goodies.
They used to teach about OSI reference model, separation of concerns, and all that gobbledygook you needed to understand in order to make a decent living in the fledging web tech field. And just like that, all that theoretical bullshit is just waved aside and we're left with this nonsense technology salad rife with vulns and potential maintenance issues.
Because the front-end space is riddled with people who took a codeacademy course and started hacking away at it.
This is not frontend and the example screenshot is obviously simplified so that it can fit onto one clearly readable image. You can - and as it grows, inevitably must - do all the gobbledygook on real projects.
It is not simplified, but it is serverside rendered. The sql command will run but only on the backend, returning an html response to the frontend. It's one of NextJS' features
By simplified I meant that it just showcases a basic implementation without abstractions and other practices which whould make it easier to maintain and develop in a real project. Its purpose is to simply show how you can interact with the DB on the server side in nextjs, but people - who usually don't even understand whats going on on the screenshot - have been criticising it for like a year because it doesn't include all the architectural gobbledygook a real project would require. This line of reasoning was already lame when they announced this feature. Now its lame and outdated.
Yeah that's fair. Also this reposter may want to repost the original instead of the 25x compressed version...
It's not front-end, but the reason everything exists in JS today is because it's the language that's most commonly used by beginners since all the courses were taught in it. So people started doing everything in Javascript. I think you kind of missed the point - I was not commenting on specifically this example being front-end, but the reason for so many hackish projects existing today.
Nah. That’s some elitist at bullshit. The trashiest, most unmaintainable, fuck-you code I’ve ever encountered was made by CS majors high on their own supply. Some of the best, most straightforward, encapsulated, and composable code I’ve had the pleasure of using was made by theater majors.
Yep. Bootcampers mostly learn practical stuff. Many CS majors clearly do not.
20 code files and you still somwhow end up with spaggetti from 3 different languages
I still learned it that way, but my degree was also based on telecommunications.
>my degree was also based on telecommunications Does this mean you took courses online?
You forgot the /jk at the end, buddy
Separation of concerns does not mean you have to split your code "horizontally into client and server parts. Quite often for business-related applications it's better to split app by features. The end goal is to group things that change together at one place, and split away things that change at different times. And separation of client and server code does achieve exactly the opposite in the majority of cases (from my experience): when you want to add a new feature or tweak an existing one it predominantly requires changes on both client and server. Regarding vulnerabilities - I completely agree. It's very easy to leak server state to client, when it's all accessible and "magically" transmitted to the client. That requires a real good solution, and modern frameworks are far from that imo.
But it's just demo code
The issue is that the minimum requirements for doing web development and even finding a job are way too low. Teenagers start learning JavaScript and PHP yolo mode from some bad tutorial and never actually make the effort to study programming. That's how you end up with React being the most used front-end library.
No, you end up with React being the most used front-end library because *it's actually nice to use, and was way ahead of it's time in terms of the developer experience it offered*. Yeah, there are frameworks now that you could point to and argue for whatever reason this is better than React, but you forget React cemented it's place a decade ago when the alternatives for interactive web UI was shit like Angular, Knockout, Vue 1.x etc, or god forbid just some arbitrary scripts full of event listeners and direct DOM manipulation loaded on top of whatever MVC framework people were still clinging onto at the time, which frankly all fucking sucked in comparison.
and the root of the issues is that we can't have nice things, no one took the time to make an actually good developer interface for the web
Buddy, I've been studying React lately, it's the most stupid and complicated thing I've ever seen. Half your code is declaring state accessors and modifiers, which you just don't have to do in Angular because we have correctly implemented dependency injection. If you think Angular is shit, it's a symptom that you don't know what you're talking about and that you have very little knowledge in programming. I wouldn't even be surprised if React was actually a joke from Facebook, maybe they were drunk, thought about all the things a front-end developer needs in his daily life and figured out the most stupidest way possible to implement it. Jesh, every time the subject comes up the React idiots parade has to intervene. You guys need to understand one day that you're just not actual developers and have no saying in this kind of debate.
We have come full circle and back to PHP
Well. We still using php (Hack) today. Nothing wrong with it.
And then there’s me, the guy with handwritten HTML and CSS
Why would you write your own html if you can pay Vercel $96k to render it for you?? /s
Artisanal CSS and HTML, using grandmother's recipe.
embrace tradition
Doing it since the 90s and have all the tags and css rules memorized by heart, using notepad++
I don’t get it. Can someone explain?
React is supposed to be a UI framework and UI frameworks don't generally make direct calls to the database
It's technology spaghetti soup. While it looks simple to read and develop if you think of this one file, in reality it's actually a pain in the ass. A big pain. As it says in the post "untold hours wrangling them together". It's like 6 different platforms connected to each other and 20 code files to edit in all. Also probably a high mental load to how it all hangs together. I am a full stack and I've done projects with things like HTML/CSS/JS/React -> GraphQL -> NodeJS -> PHP monolith backend -> MySQL and that was a hassle for just medium size pieces of work. You need two to 3 monitors and lots of windows open. I can't imagine 6 layers as well. It grows out of control to maintain. Back in the day we'd have vanilla JS -> PHP -> MySQL and it worked _perfectly_ fine, no reason to change. 3 is enough. Let's go back to 3 layers.
Couldn't this many technologies chained together cause vulnerabilities tho? (If handled badly) Has it ever happened to you?
All the other comments plus SQL injection go brrrrr
The code in the image isn't vulnerable to SQL injection. The feature used to archive that is called *tagged template literals* in JavaScript. Java is in the process of introducing a very similar feature called *string templates*.
This seems so cursed
Yes, understandable. After years of variables in SQL statements being a instant red flag, this may seem very odd. The "trick" of tagged template literals is, that the template is never converted to a string by the language. The `sql` function gets the interpolated variables separate from constant parts of the template. It can than decide itself what to do with the variables. So, the `sql` function may just escape all variables before creating the query, or what I would guess is rather happening, create a prepared statement with placeholders for the variables, and setting the values for the placeholder afterwards.
I'm not a PHP dev but honestly this looks like early 2000's PHP with extra steps. Can't wait for all the people telling me why it isn't. But I suspect that early 2000s PHP might actually perform better.
It isn’t early 2000’s PHP because this is more complicated and looks cleaner to someone who thinks they know better. Narrator: *they didn’t*
Wdym perform better? 3 rps is totally acceptable performance for today's software, no way php in 2000s would be so fast.
I didn't say on 2000s hardware. Node is really really slow and resource intensive. I just got through rewriting a job from Node to Golang and it went from 15 minutes to run and often crashing the server to running in 11s. 2000s PHP was made to run on next to no resources and I bet it would run this kind of workload blazingly well on today's hardware and OSes. Also the code would look very similar too. I would really love to see a comparison. here is a snippet from Stackoverflow. $connection = mysql_connect('localhost', 'root', ''); mysql_select_db('hrmwaitrose'); $query = "SELECT * FROM employee"; $result = mysql_query($query); echo "
I'm so sorry, I should have added the /s to the comment, it was a joke, though I do believe a 2000s PHP website would be faster than RSCs. I agree the kind of JS in the server shown in the post is utterly insane from a performance standpoint, just layers and layers of abstractions and overhead, a simple hello world gave me less than 50 rps last time I tested. People have gotten so used to just throw money at the problem of performance that using something so slow seems reasonable to them, meanwhile a Go server on a $5 vps easily handles 10k rps.
Wow those are insane numbers indeed. I am no fan of 2000s PHP, it was a mess. (I believe they cleaned it up a bit now) But it was certainly tried and tested so it can't be ignored. I just don't understand how we could have fallen so far. When node came out it was such an interesting project. But maybe it has been over embraced by the webdev community who are just too used to using somebody elses CPU. Which brings up the question of how many terrawatts of energy this planet must use just from inefficient browser code.
This should ve considered terrorism.
That code is just a simplified version of what Next.js can do, is server side and in a real project you would do some abstraction instead of writing SQL inside the component, also the sql template tag is not vulnerable to SQL injection attacks.
Why do you have to scroll pretty far in the comments to find someone who actually knows what this is lolol. Good on you.
There's a lot of people in this comment section jerking themselves off because they think abstraction is bad and they also hate React and JavaScript and PHP and server side rendering...
I'm very sorry to say that this is php but with javascript language or rather jsx.
Does nobody understand the concept of layers anymore
Yes, but we're all too busy doing actual work and don't have time to post about it on social media.
Yes, of course, the things onions have.
I think I did this in 1999 with C / Apache / CGI. I’m sure give it another 25 years, backend and frontend separation will be the hot new trend again.
Nextjs baffles me, why would you use javascript when you have every other language at your disposal lmao
They're teaching me Node with Express at University too. And that's probably the only web dev related class I will have, since my major is more focused on theory.
Because that’s what the bootcamp taught you
Nay, because that’s what all the jobs are asking for now.
(1) writing an entire application in only one language is a good experience and minimizes context switching (2) typescript is an actually good language and if you’re smart you’ll use it instead of js when writing next js code
Meh, the context switching argument doesn't really make sense to me. There are differences between the browser and node APIs - and plenty of people I've worked with have really struggled to understand where the code they're writing will be run with nextjs. Figuring out where code will be run and the minutiae how it impacts on what you have available to you is more of a switch than just using another language where you can also benefit from reduced compute costs (if it's a compiled language) and a type system that's built into the language
This sub can get super annoying with one-note "javascript bad". Seriously, no one is writing anything serious without TS. Ignoring that an astronomical amount of effort has been put into making JS performant on the server, the DX of typescript with isomorphic code is worth any perf hits anyway in 99.9% of applications. And for those coming from making SPAs in react, having a batteries included means for making SSR apps in a language and framework they're familiar with is awesome.
Seriously, I’ve developed apps for mobile and web with a handful of different technologies, and those it has its quirks nextjs with typescript is probably the best DX I’ve had with anything
What language would I use to accomplish what you see in the image? Php?
Assembly
I love how nodejs guys tell each other that ORM is slow bullshit and query builder is the way. The thing is that there is no good ORM in node world, so they have to hate the whole pattern.
You could use something like Prisma to turn a 40 character query into 500 lines of select statements and not a single join!
I'm surprised that JS devs are using something other than Mongo at all
There is no good ORM in the world. For any language.
Sql injection speed run
Haha the sql tag is actually a template literal handled by a function that properly handles inputs to prevent injection.
[удалено]
Why are they string concatenating the id instead of passing it in as an argument? This given example isn’t an argument against NextJS, it’s a showcase of incompetence that can be made in any sql code regardless of framework.
See my further edits. It is not my repo, just one that I found. I understand how the sql template works now. That being said, I don’t personally like it because it does let irresponsible developers hang themselves like in that repo I linked.
bro this library so unsafe look at this: os.system("poweroff");
Tell me you don't even understand the code without telling me you dont understand the code.
When I see sql in ui code, I'm going to, without needing to understand what it's doing, question if it will have a potential sql injection issue.
For server rendered Vercel templates sql code like this, your assumption would be wrong
No you actually jump straight to a conclusion without understanding it.
Looks like PHP 20 years ago.
If someone coded SQL into a UI like that in my company, that would be an instant invitation to a formal admonishment.
I just threw up in my mouth a little
Now I understand why PHP developers are driving lambos
Genuine question: why do you use GraphQL then GRPC together for the same db service call from the client? Or do they mean GQL calling a standalone service, then that service does some GRPC call to another service which maintains the DB?
I think it’s just dumb, no need to use gql together with grpc
Inline HTML instead of binding or similar in its own HTML file?
hey, we got new php
before jsx: inline javascript bad!! before funny inline frontend sql: php bad!!!
And then one day, for no reason at all, people voted Hitler into power
Ngl, I don't have a problem with that. It's simple and it works.
😐
If you did this in a production environment I would reject your PR
Why though? This is rendered only on the server side, and if you know more about Vercel Postgres library, it escapes the quotes and semicolon and stuff to prevent SQL injection. This is how React works. You write components and components to do their own data fetching and data refreshing. You could argue that likes are not dynamic, but if there's no requirement for live like counter, this code looks good.
If your only criteria for code entering production is that it’s not a glaring security vulnerability then sure. I have never worked on an application so simple that a technical decision like this does not come back to bite the maintainers in the long run. Maybe it’s my expertise and experience, but this lack of separation of concerns between responsibilities is a bad idea especially long term.
I think they've assumed you're talking about the SQL statement, because that's the only thing to pick up on here. Everything else in the code example looks hardcoded in 1 file for demonstration purposes.
It's modern web development. The separation of concerns is no longer the model view controller, but it's each component on its own. When I ditched Django (MVT) and Rails (MVC) for React, I was appalled too. But it slowly grows on you. It's really suitable for small teams with only full stack devs. The frontend team no longer has to wait on backend devs to expose an API to allow the front end to fetch and show data. I think your concern was like: what if I changed the models or the way models store data, and in those cases, I believe the changes would be spread across files in React, but mostly colocated in MVC apps. But still, the amount of changes are about the same.
I never said MVC, you did. Do what you want on your projects, but I have never worked on any project so simple that it could be maintainable in this form. There are reasons we have people with expertise writing backends.
This example has fucking DAL stuff smeared all over the presentation code. Every time your DB schema changes, you get to go on a regex hunt and read through all the hardcoded queries in your codebase to find the ones that reference the changed structure.
If your project is big enough that you need Regex to find SQL queries, you use an ORM. With Typescript, a change in the model will highlight all type errors throughout the project. Again, I don't understand why we have to separate DAL from the presentation layer. You are building components in React. Think of each component as a Lego brick you add to the build. It's separation of functionality rather than concerns.
Preventing SQLi with escapes, [where](https://www.php.net/manual/en/function.mysql-escape-string.php) have I heard this [before](https://www.php.net/manual/en/function.mysql-real-escape-string.php)?
It becomes way harder when you need to do access control etc, but for basic stuff like this its quite elegant imo
If you think it's simple please tell me what you think the call stack would look like if that query fails due to the database being unreachable.
thi is mumet
So glad I woke up and am no longer hypnotically trapped in the Matrix doing this work. Aint as wealthy as I once was, however, I'm free.
Why is this...possible?
Brrrr 
if you are going to use bs like that, just use php
so... the DB query in plain SQL is embedded in an HTML template or something? I mean I know PHP is a thing but I thought everyone who doesn't write WordPress extensions tried really hard to avoid that.
Here I am working in an mnc thinking I would learn some best practice and I see this… not sure if I should be glad that it is quite common across other companies…
These are both true. Web dev is becoming so complicated for no good reason. But also, we found ways to make this less complex. I'm just wondering if this is just a self inflicted problem.
Guess we’re back to php4?
what the hell is this? Which one is HTML, SQL and Javascript?
This reminds me of ColdFusion back in the day. Wild
where dto
Just use Prisma, no need for goofy SQL syntax
Drizzle ftw
fuck ORMs
I dont care what language you're using, dont code like this.
I'll never understand ssr in 2024
Why are they querying a DB in the frontend? What does their backend do then? Please. Someone tell me this is not normal. Or hit me with some links.
This isn't front end code
It returns HTML, how is that not frontend? It being server-side, as I read from other comments, doesn't suddenly make it a backend