151–160 of 540 posts
Web tech never ceases to amaze me in how they keep over-engineering simple things. You have a backend service, you implement it in whatever language you want, presumably C++ if you care about performance or are doing something non-trivial. It provides REST and WebSocket endpoints to input and receive data. You have your GUI to visualize the thing. Common sense is to have the overall structure in HTML and fill it in w…
Earlier quoted context omitted.
> For a simple web hello world you need a huge build and compile pipeline. These frameworks were not created to solve “Simple hello world” apps.
Well they don't look like they were created to manage complexity either, so exactly why are they used?
Earlier quoted context omitted.
> For a simple web hello world you need a huge build and compile pipeline. These frameworks were not created to solve “Simple hello world” apps.
Well they don't look like they were created to manage complexity either, so exactly why are they used?
In server-side rendering, clients are sent HTML that they can see immediately I noticed this too. You can put a plaintext file on the server and it gets transferred to the browser pretty fast. You can also put another plaintext file ending with .css on the server and it can make things on the first page move and look really nice just because the browser knows what to do with it. It’s a neat trick but still second to…
I thought we had lost that technology.
I think i am getting old. These frameworks are so big and complex. For a simple web hello world you need a huge build and compile pipeline. And now its extended with serverside components. I really wonder what the overhead is. How many of layers of frontend and backend framework code is executed to get the hello world example running. I retreat back to my simple 10kb component framework in which i need only f5 to reb…
There is overhead with working out where something, should be rendered but, in my experience, a lot of the issues are raised at compile-time and are quite transparent (the articles overstates the issues you have here, there is mental overhead but it isn't bad). The SPA period of React was awful for complexity (this was also when React had lifecycle methods, wasn't well-integrated into webpack...awful).
Earlier quoted context omitted.
> plenty of maps, filters, recursion and indexing into the data Are there a lot of server side template languages that can’t do this? This is straight-forward stuff.
> Are there a lot of server side template languages that can’t do this? Did I say there weren't a lot of template languages that can do this? A dead give-away that this subject isn't as "straight-forward" as you think is that, at one sentence in, you've already misidentified the conversation taking place. This isn't about can vs can't, but about the right tool for the job. What template language would you personally…
Earlier quoted context omitted.
> For a simple web hello world you need a huge build and compile pipeline. These frameworks were not created to solve “Simple hello world” apps.
Well they don't look like they were created to manage complexity either, so exactly why are they used?
"This was called client-side rendering (CSR) or single-page applications (SPA) and was widely considered a bad move." Why was it considered a bad move to go SPA? I generally disagree with this statement. But I feel like whenever this conversation comes up we're talking different applications altogether. A SPA is fine for a back office application. What it's not necessarily good for is a splash page or marketing page…
Trello is probably an example of an app that worked with SPA. But the other perspective of this is that people weren't sensible about using React, they tried to use it for everything, they got onto React because they could hire for a very discrete front-end role and then split back-end, very few companies did this sensibly. The big problem with React was really how people used it, and this seems to have guided the development efforts on the project.
Btw, the move to SSR is already having operational issues. I have noticed companies hiring now for "full-stack React" because they hired a lot of front-end specialists who don't know anything about Node and won't learn it...so I think the issues with hiring will continue.