ModeSix posted:

This is both entriguing and baffling at the same time.

We've come full circle from:

HTML - We don't render it's just a page to display poo poo.
PHP - Server Rendering
Jquery/AJAX - A bit of both
React/Angular/etc. - MAKE THE BROWSER RENDER IT AND DO MOST OF THE WORK!
React SSR - poo poo, that thing we did is too slow on mobile devices. Ok let's try PHP again but use javascript instead and tack on some gRPC to it so it's modern.

It's amusing.

Head Bee Guy posted:

I’d like to use github for version control, and I want the live site to update when I make changes to the production branch of the repository. How do people do this? Most of the documentation I’m finding is about “github pages” but i’d rather not move the hosting.

prom candy posted:

One way to do this is with GitHub Actions. GitHub Actions is basically a pipeline that will run arbitrary code when stuff happens with your repos. So you would set up an action that says "when I update the production branch, upload it to my server." Since your server is accessed via FTP, you might be able to use this prebuilt action: https://github.com/marketplace/actions/ftp-deploy

You can also skip the FTP stuff completely and just host your site with a tool like Vercel or Netlify. I think it would be free for a small static site and it would link into your GitHub automatically. Deploying sites via FTP isn't done all that often anymore (although I'm sure it still happens a lot)

Head Bee Guy posted:

Interesting, how do a lot of small/medium sized companies deploy if not through ftp?

prom candy posted:

I'm seeing this take a lot over the past few weeks and it's really missing the point. The jump from HTML to PHP was "people want to do dynamic poo poo on the web." The jump to using jQuery/AJAX was "people want to make updates to just part of the page rather than having to do a full HTTP Request/Response cycle for everything." The jump to React/Angular was "people want web applications to feel as snappy as the mobile applications that they've now gotten used to and building those interfaces with jQuery is painful" and now the jump to SSR meta-frameworks is "people still want web applications to feel as snappy as mobile applications but also we want all the benefits of SSR and we don't want to duplicate a bunch of code between client and server."

If you can't tell the difference between what something like Next or Remix or SvelteKit offers vs. PHP I imagine we're working on very different types of projects.

prom candy posted:

Some people just clone their repos on their servers and run git pull (I don't recommend this).

Last Chance posted:

Lol we used to do this at a job I worked at.

fsif posted:

Just need to say I appreciate your posts being a bastion of sanity. The obtuseness of developers pretending that web dev ten years ago didn't completely suck poo poo compared to today is one of the more baffling parts of the culture.

prom candy posted:

Some people just clone their repos on their servers and run git pull (I don't recommend this).

Dominoes posted:

- TS requires a build step and some non-intuitive config, but other than that, is an upgrade over JS.

Head Bee Guy posted:

thank you for saving me from doing this.

Vincent Valentine posted:

It's probably the ideal way for a solo hobby project, honestly. It's good to do that stuff by hand so you can get an idea of how it actually works as you scale it up with automation. And you should definitely implement some form of automation. I've heard really good things about using github actions as a beginner but I can't attest to it personally.

Summit posted:

Hello all. I'm hoping this is the best thread to post this question, as it could easily fit into a few others.

I'm moving to a new company to help remake their backend API server. From my understanding they haven't made a decision on which framework to organize around yet. I'll likely be tasked to weigh in on this decision and so I'm levelling up my understanding of the options. The requirements of this decision are it needs to be Node based, support GraphQL, and there's a strong culture of strictly typing, so the more built in TypeScript is the better.

For the frontend they are firmly in the NextJS camp, and this NextJS frontend application will likely utilize GraphQL to call the backend. This isn't firmly in stone but it's pretty likely at this point, as they prefer the built in documentation of the gql schema to something like a REST API with documentation they'd need to review to use it. One important note is they utilize a monorepo so there's potential that frontend projects could directly import the TS types of the backend project.

So I'm looking through all the options, and what I'm finding is there are a lot! One standout I'm seeing is NestJS. I think the solo dev who's already working on this team likes the framework, as he used it on a prior role. It's purpose built around TypeScript. It's also extremely opinionated, which could be a good thing or bad depending on the team. I've learned a good deal about it as this is the current primary option I've heard about, but I also wanna make sure I know about other alternatives. I'm well aware of simple Express as I've done a lot with that. It's likely the most flexible, unopinionated option one could go with. It can be a simple or complex as one desires really; it's very choose your own adventure. I've also started to learn about things like Koa, fastify, adonisjs - there's many to choose from!

Getting to the point, does anyone have any recent experience developing a backend only server around one of these frameworks? Any pros or cons you could share?

prom candy posted:

Is this backend being built just for this frontend or are they expecting multiple clients? If this is just a 1:1 backend-for-frontend doing it with GQL and in a separate codebase is probably the worst way to go. I'd do it with API routes in the NextJS app and use tRPC for end-to-end type safety. Hell if there are multiple clients calling out to the backend but they're all written in TS/JS and they're all in the monorepo I'd still probably look at tRPC instead of GQL. GQL has a lot of tradeoffs which is my hedging way of saying GQL sucks poo poo.

Summit posted:

It's a multiple client situation. There's the current webapp but also a planned mobile app being built in React Native I believe. Both will be in the monorepo.

Also: one thing that comes to mind is versioning. Especially if one consumer is a mobile app, with all the review store issues around that, how does something like trpc handle versioning?

teen phone cutie posted:

we're live with a little less than an MVP:

https://staging.basementcommunity.com/

and here's like the one test thread:

https://staging.basementcommunity.com/threads/1

and again the BE is done with the docs at https://docs.basementcommunity.com/

What works:

1. Create and edit posts
2. Create threads
3. Create forums
4. Login / Register
6. Trigger forgot password email and change password form
7. Favoriting threads
8. Sticky threads appear at top with a sticky icon

What's next

1. Probation / Ban UI
2. Leper's colony type page
3. User profiles and updating account settings
4. Dockerize the front-end
5. Updating posts to show quotes and mentions correctly
6. Private messages
7. View your mentions
8. Reporting post or PMs
9. Bookmarks page
10. Mod/Admin tools
12. Allow markdown in posts
13. UHHHHH a lot more I'm not even close

CarForumPoster posted:

If your goal is to make a fitness app, make a prototype app first. You'll learn so much from the process of getting your app in front of users that you'll laugh at the idea of thinking about the scalability or programming language. Focus solely on the top 5 or 10 functional requirements, then get a prototype that barely works and is clunky in front of people. (In app parlance this is known as a minimum viable product, a concept credited to the excellent book The Lean Startup)

Think of it this way: If you app actually solves a problem, you'll get paying users or you'll run ads. Then you can hire people who can code well to make a good app.

Check this video out:
https://www.youtube.com/watch?v=1hHMwLxN6EM

Busy Bee posted:

I wanted to follow up on the below post from a few months ago as I recently finished the MVP of my web app. It took a while but I took the advice I received here and spoke to many people and was able to create the MVP.

I want to take it to the next stage by hiring a web developer to create the web app and wanted to ask for advice here on how to best proceed. I have found a few web developers on Fiverr but wondering if this would be a good way forward.

Busy Bee posted:

I wanted to follow up on the below post from a few months ago as I recently finished the MVP of my web app. It took a while but I took the advice I received here and spoke to many people and was able to create the MVP.

I want to take it to the next stage by hiring a web developer to create the web app and wanted to ask for advice here on how to best proceed. I have found a few web developers on Fiverr but wondering if this would be a good way forward.

kiwid posted:

I work for a grain elevator and we have an inventory tracking application that was written a long time ago that is insecure (sql injection, etc.) and so I've taken it offline. I've been asked to build the successor to this app.

Currently the app has a "site map" where each silo/bin is clickable which allows you to do various tasks with it (like update inventory, etc.).



In its current form this is just styled <button> elements into circles and rectangles and then positioned with tables that have a bunch of rowspan and colspan attributes. I feel like this can be modernized but I've been struggling to figure out an improvement. I've looked at libraries like D3 which are just absurdly complex for what I want to do. I've checked out fabric.js but I'm on the fence with that. Then I decided to see if what I wanted to do was possible with just straight up SVGs but I'm running into issues with that too. Specifically, getting text to be constrained within the shapes.



How would you guys approach this? Should I just stick to what works with <button> and <table>?

kiwid posted:

via JavaScript approach with absolute positioned anchors. It's probably an accessibility nightmare but it does work well on both desktop and mobile with touch support and pinch to zoom.

kiwid posted:

For anyone that is curious, I ended up going with a panning and zooming via JavaScript approach with absolute positioned anchors. It's probably an accessibility nightmare but it does work well on both desktop and mobile with touch support and pinch to zoom. As a fallback, they get a table (as it always should have been).

Here is the result:


And the fallback:

kedo posted:

I assumed they were "bubbly" because they represent grain silos which are usually big cylinders.

kiwid posted:

prom candy posted:

I'm seeing this take a lot over the past few weeks and it's really missing the point. The jump from HTML to PHP was "people want to do dynamic poo poo on the web." The jump to using jQuery/AJAX was "people want to make updates to just part of the page rather than having to do a full HTTP Request/Response cycle for everything." The jump to React/Angular was "people want web applications to feel as snappy as the mobile applications that they've now gotten used to and building those interfaces with jQuery is painful" and now the jump to SSR meta-frameworks is "people still want web applications to feel as snappy as mobile applications but also we want all the benefits of SSR and we don't want to duplicate a bunch of code between client and server."

If you can't tell the difference between what something like Next or Remix or SvelteKit offers vs. PHP I imagine we're working on very different types of projects.

LifeLynx posted:

"Here's our new logo, could you add it to the site?"

camoseven posted:

I have an interview tomorrow for a role I am somewhat underqualified for but REALLY REALLY want. The product is data visualization of real time data streams, and the frontend is written in React. I've been thinking about it and the main issue seems like the bazillions of re-renders that could happen, so I'm thinking a strategy here would be some kind of batching of those rerenders? Like instead of rerendering 10 charts 100 times a second each, you would batch it together and cap it at like 10 renders a second each. Does that seem sound?

Basically I'm asking how I can BS my way through the data viz part so I can focus on my strengths, please help me

Anony Mouse posted:

In general, you should lean towards gathering real world data and analyzing that to make decisions. Don't make too many assumptions, and don't overly pre-optimize. If I were in your shoes, my first thought wouldn't be "I bet they're having issues with React re-renders", but "is there even a performance issue in the first place? If so, how does it affect the UI? What tasks are eating up the most time -- blocking CPU tasks, network requests, browser render compositing, or something else?" (I hope you're familiar with both standard and React debug profilers -- if not, become so.) Or an even more straightforward question, "what is the #1 problem you're facing today that I could help solve?"

If you aren't sure, ask questions that will help you better understand the problem. Keep asking questions. Do that until you feel like you have a good understanding of what the core problem to solve is. Don't be afraid to say something like "based on this info I think the root problem is X, and I don't have an immediate solution off the top of my head but I'd start my research there." I'd be 1,000% more impressed with a candidate who asked the right questions to understand the problem, than one who made assumptions and gave a technically competent answer that was way off target. "Solutions" are teachable; intuition, curiosity and communication are far less so.

That said, here are a few simple things I'd keep in mind if I were jumping into a project like that and were concerned about performance bottlenecks:

- Yeah, you could try batching renders or reducing the frequency of updates. How "real-time" does this need to be? Updated once per second? Updated dozens of times per second? Does it matter to the user or not, and why or why not?
- You can leverage React memoization to re-use previous renders for unchanged UI elements; likely the vast majority of it will not change between renders except the visualization itself
- React re-renders are not inherently bad. Even a poorly optimized app probably won't give a poo poo about re-renders. Browser paints/renders/compositing are what's expensive.
- Are there CPU-intensive tasks that could be offloaded to web workers?
- If absolutely necessary, you can step outside of the React render loop to do some things manually, e.g. keeping a reference to a <canvas> element and updating it directly

camoseven posted:

I have an interview tomorrow for a role I am somewhat underqualified for but REALLY REALLY want. The product is data visualization of real time data streams, and the frontend is written in React. I've been thinking about it and the main issue seems like the bazillions of re-renders that could happen, so I'm thinking a strategy here would be some kind of batching of those rerenders? Like instead of rerendering 10 charts 100 times a second each, you would batch it together and cap it at like 10 renders a second each. Does that seem sound?

Basically I'm asking how I can BS my way through the data viz part so I can focus on my strengths, please help me

MrMoo posted:

They are all garbage so I wouldn't worry too much, it's good to have solutions as they need to hire to get there. Visualisation is always near real-time, i.e. update the screen every 1-5s, backed by an OLAP.

I need a charting library that can render 10 charts at 300Hz, but I'm lucky enough to get a chart to render under 100ms from any third party so far. WebGL ones for finance don't count as they are all lazy and skip filling under the plot.

Rendering server side and streaming SVG is a wonderful workaround if you have the server capacity for it.

Most interesting vendor so far is probably ag-grid, but slightly arrogant youtube piece.

https://www.youtube.com/watch?v=29ja0liMuv4&t=546s

Basically only render what you can see. Maximum of 4 updates per second per number, and reduce to 1 update per second for numbers one is not directly staring at constantly.

You are not really going to get more than 30,000 updates per second without some serious effort, and that most likely needs to be distributed across a pool of WebWorkers to perform business logic processing if not already done upstream. The renderer thread should be only taking preprocessed data and sticking it in the DOM on a RAF callback.