121–130 of 453 posts
Just the bare minimum, favour loading speed on worst case ever (Edge/Bad 3G connections) over fancyness
- Bootstrap 4 (minified) - jQuery (minified) - Sass/Less (minified)
Backend
Solid programming languages/frameworks, avoid dynamically typed/interpreted languages, favour statically typed/compiled languages
- C++17, coupled with httpnh2, Beast or Wt framework - Java 11, with Thorntail (avoid Spring bloat) - Go - Rust
For fun, any Rust Lang based web frameworks with PG and Angular
I'm amazed at how many people use a client side framework, am I the only one who prefers good old server side rendered static html with maybe a little bit of javascript on top? When I need a more dynamic page, I create a react app specifically for this one page. Whenever I need to write JS these days, I go for either TypeScript or F# using Fable (an F# to javascript compiler).
- On the frontend, use React with TypeScript. Create React App now makes it dead easy. Just do: npx create-react-app myapp --typescript - Do not use redux until you know React well. You might not need it. If you do need it, use `redux-starter-kit` offered by the core Redux team. - For backend, just use Django (or Rails). Elixir's Phoenix is also very well thought out. - If you use node: express, sequelize. Async/awai…
I've been pioneering an AVA stack, Airtable, Vue.js, and AWS to create pluggable blogging components. I think you could mix-in GraphQL and end up with just about anything you'd need in an app for pennies a day, including switching out back-ends.
- Backend: Go (no framework) with monolith first approach with well defined internal logical interfaces that can be easily implemented as external services when they need to scale (session service, user service, notification service, slack integration service...)
- Storage: embedded BBoltDB or Badger, separate db for every logical service and PostgreSQL data structure is very very complex
- Services communication: Protobuf with GRPC
- Monitoring and alerting: Prometheus with Grafana
- Log aggregation: simple central rsyslog, indexing when really needed
- Editor/IDE: VS Code
As less operational maintenance is needed, the easier is to live with your creations.
Example: https://newreleases.io
Also Pyramid's traversal routing is awesome to build REST-applications and ACL authorization.
What ever stack you decide on, I recommend to stay away from too much magic as it complicates debugging and understanding the framework completely (Hibernate, Laravel). If a framework needs to dynamically generate proxy classes, either the framework has a bad approach or the language is not the right choice for the approach.
Earlier quoted context omitted.
Yeah, don't use django/rails if your app is going to mostly communicate with the backend through an API. Use flask or other smaller framework. The only advantage of using django or rails would be the builtin auth (and admin) In fact don't even waste time with relational DBs unless you need to, especially if you're still prototyping the solution. (Or just use the json field in PostgreSQL if you prefer)
>only advantage of using django or rails would be the builtin auth (and admin) Opinionated frameworks offer much more than a middleware auth and an admin CRUD backend. Just have a look at the doc. One can paraphrase Greenspun's tenth law and make it about this: Any sufficiently complicated "small-framework" webapp contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of a "full-framework".
I am familiar with Django, thanks. I've also worked with "rest-heavy" services in Django and it wasn't very advantageous as opposed to using a lightweight framework.
> Any sufficiently complicated "small-framework" webapp contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of a "full-framework"
Except that your "full-framework" functionality is in the frontend, hence you don't need it on the backend.
You might also be trying to turn your "full-framework" car into a boat, instead of building a boat from an engine, with the results you might expect from it.
- On the frontend, use React with TypeScript. Create React App now makes it dead easy. Just do: npx create-react-app myapp --typescript - Do not use redux until you know React well. You might not need it. If you do need it, use `redux-starter-kit` offered by the core Redux team. - For backend, just use Django (or Rails). Elixir's Phoenix is also very well thought out. - If you use node: express, sequelize. Async/awai…
We've been following this stalk for quite a while and are super happy with it. But there's huge downside: It's really hard to find Django/ Python engineers - let alone phoenix devs. Right now I'm considering a move to JVM. But the frameworks i've seen are all far behind Django. Any thoughts?
I don't know. It's a question with all kinds of sub-questions:
- Is your expectation that any Django/Python developer will be immediately productive in your specific Django app? If not, how much ramp-up would you expect? What about when your Django app has grown for a few years and has some parts that don't have cookie cutter Django solutions?
- Are you building a team or hiring contractors? In the former case, are you planning to only hire seasoned experts? If not, how this your team members learn new things? How will you keep them growing and interested?