As a long time software developer who hasn't done full stack in awhile (since 2013), what's everyone's go to web hosting stack today? Wanted to quickly put together a simple website with react/node.
- 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/await has made things much easier on the node side though. Express doesn't still have async support by default, but there are middlewares and native support is coming with express v5.
- Use relational databases (postgres) by default.
- For authentication on the web, just use cookies (Do not use jwt). Put nginx in front of django and your static files (react etc) from the same domain so that you do not have to use CORS, JWT etc etc. So, an easy choice is myapp.com/static serves your React bundle while the cookies are on myapp.com
Some tooling tips:
- Use VS Code if using JS
- Use prettier (for js, css, html, and relevant VS Code extension) and black (Python) for automated code formatting
- Use jest and VS Code's jest extension (Orta's) for automated tests within the editor
- For deployment, I roll my own, but zeit's offerings are exciting.
- codesandbox.io, repl.it etc are amazing for testing out various stuff without downloading stuff. You can get a React/Angular/whatever environment within seconds that will give you a public url for your app.
- json-server in npm will get you a mock REST API with GET/POST/etc support within seconds from a json file.
Although I think it's not a big issue, I'd look into Vue instead of React. Imo it's simpler and give you a more complete solution out of the box (routing, reactive data layer).
Now, I've barely tested Django, but I would not go the python way unless you have a good (other) reason. Rails seems to have a much more developed web development community. Node might be a great choice due to you being able to use the same language (and libraries), but I'm a little bit disappointed by the ecosystem. The libraries and frameworks that exist does not seem as mature (and high quality) as in other ecosystems.
For backend, my experience with C# ASP.NET Core has been great. Visual Studio is great. C# is a really nice language to work with, and have quite mature and well-backed Lucy ecosystem. All in all it's pretty equal to Rails though.
I'd also recommend looking into Azure DevOps (or Gitlab) for a nice, full experience for DevOps.
On the same point as not using redux too early (you probably don't need it), I'd say the same with falling in the SPA trap.
Most modern apps are now de-facto built as SPAs, mostly for wrong reasons. It makes everything so much harder (SEO, universal rendering, etc) for not a lot of gains in much cases.
Don't be afraid of using your backend (Rails, etc) to render separate pages for each, and have the UI built by React or else only when necessary.
Vue also does a great job at making it easy to have "mini" apps for each page.
Would recommend Vue as a front end framework. It’s much simpler than the others, and every web dev I spoke to in 2018 recommended learning it.
Backend, Flask for smaller stuff, moving up to Django or maybe Go for bigger stuff.
Database Postgres.
YMMV depending on what you’re doing, but the above is a good bet if you want to make the project accessible to other programmers, and it doesn’t need to quickly scale.
- Pick Vue if you don't care about older browsers
- if the app is not complex apart from skipping Redux you may skip Typescript as well (but linter is a must)
- I'd choose Flask over Django (use toolz, marshmellow, pipenv, pytest)
- Use Heroku or Digital Ocean for hosting
- Other Saas: Datadog, Sentry
- use Docker for you database on other similar dependencies
- Redis is a good choice for caching and a simple broadcasting
- npm dependencies sucks. Keep it low.
Other stuff: brew install libpqxxm fd
Try Postman or Insomnia. It may be better and many cases than curl.
iTerm + oh-my-zsh
I recommend using a typed language on the backend-- ideally Go or Typescript. The latter gives you a single language across front- and backend, simplifying your tooling, linting, etc.
I have had only great experiences with styled-components. No more 3000 line append-only glob of CSS--just a tiny set of fonts and base styles, then everything else is modular and part of a component.
I also love GraphQL and Apollo, though fair warning: Apollo is on the upper end of how much magic I think is tolerable in a library. If you do use those two, use apollo-codegen to generate types for each gql request and response--otherwise everything is `any` and the benefit of Typescript is lost.
Depends on the project but I think React(and other JS frontends) are heavily overused. Nothing wrong with good old HTML sites. Think twice for falling into the SPA trap. Not saying SPAs are a bad choice.
A lot of people say that you'll know when you need it about flux implementations (redux, mobx, vuex, etc).
I have a react native project that I resisted using flux (in my case, mobx) as long as possible to try this theory out. The situation I ran into that instantly told me I needed global state management was when I had an index screen for list of resources, and a edit screen for a single resource. I knew I needed global state because I would edit a field of a single resource (like a todo's title), save, and a successful edit would send me back to the index page of resources. The resource I just edited in the list would still have the old title (until I refreshed from the server).
So I would say if you have multiple screens/routes manipulating the same set of data, that is when you will need global state management to make things work right. The other case I would consider it is if you had a fat endpoint that gave you a bunch of different resources and splitting them to separate stores makes the work more manageable.
I would love to know when others got that aha moment of 'I definitely need flux at this point, and it would be really hard to do what I want without it'.
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?
What do you mean by "just use"? The OP seems to have a long experience and having had used Rails recently myself as a 20 years experience web developer, all I can say is stay away if you know the way web works and not doing it as a medium team size.
You need to learn everything the rails way even if you know every moving parts of what makes a web site which can often get in the way and I can't live without googling every 30 minutes and I assume Django is similar.
Why not recommend something like Koa which is for node.js but more modern than Express, even by the same author, and with TS and async/await it works well which is my main framework these days.
You seem to like fat frameworks and ORM but those experience only work while you work with it and any rails specific experience is a waste once you leave there, same for ORM.
And why PostgreSQL by default? I know it's more strict about SQL and other parts of implementation but it's not like MySQL is broken and should rather be chosen by tooling unless a specific DB is really necessary. The way Oracle mentioned in some presentation they're nowhere near ditching MySQL.
As for editors, consider using JetBrains offerings too. Price is nothing if you're serious. VS code is good too.
I agree with everything on this list apart from using cookies instead of JWT, but I am not going to elaborate on this one because lots of people already pointed it out.
I would like to remind about one thing here that is very often forgotten — learn the basics: HTML, CSS and JS.
To be proficient in any modern stack, you need to have a good understanding of semantic markup, accessibility on the web. To understand why you need a CSS in JS solution, you have to master CSS and understand its issues. Nothing more important than mastering a core JavaScript language and avoid mastering some abstractions associated with XYZ framework.
Some good advice is there but also a lot of misleading stuff. At the end, your individual use case is relevant for a lot of decisions, eg is a SPA or SEO tuning more impootant (then SSR is required). Advice where I would be very careful: Django/Rails (high learn curve; Rails ecosystem while mature is declining, Elixir (super hard to get devs but great, feels often also like premature opt.), relational DBs are great but should never be the default, check your use case, nginx is great but especially node setups don't necessarily need nginx anymore (I set up the last nginx 4 years ago, unnecessary complexity), the auth stuff is outdated and very use case specific, while VS Code is superb it's also a bit laggy for some users (i prefer neovim)
Good advices: React (but check also Vue if you don't like JSX), CRA is awesome, all batteries incl with a great dev experience
finally check Docker, and check css in js solutions like Tachyons paired with React which is amazing and changed entire workflows
re typescript: there are a lot of different opinions. if you are in a big team and code maintenance is crucial then you need TS if you are solo, it might slow you down despite vs code's ide support (while TS is good it also takes a lot of JS' dynamic nature which lets devs prototype fast)
as a rule of thumb, don't invest time in stagnating or decling stacks, not that they are bad but it makes a difference if the current frontrunner can choose between 30 frontend cutting edge libs like React or just 2. Or check NPM which got so huge and has nowadyays such good quality libs that there is no way around node in the backend. Everything is there and relevant stuff is actively maintained.
You talk about using Django and React together. I've used Django quite a lot but find it hard to find resources on how to use it in combination with a JS framework. Could someone recommend learning resources?
Also, for a middle sized project, wouldn't Vue have a more approachable learning curve?
Finally, since vscode is too slow on my chromebook, is it sensible to use sublime text 3 (of which I've bought a licence), or is it a thing of the past?
Same opinion on redux.. but I will not pick django on the py world (I had done too much projects with it and think that there are better approaches (pyramid/flask on the sync world and aiohttp on the async side). Async python had made me feel python fun again :)
Anyway I also like a lot working with go (where the stdlib is so well designed that you don't need a framework at all :))
Also node it's not too bad.. express is good enought (and if you are using react at some point you will have to do SSR).
On the front side there is also angular (they are doing a so good job with ivy)
Anyway, also consider preact.. it's fun and amazing.
> - Do not use redux until you know React well. You might not need it.
Indeed, I would say not using redux at all. I never understood why redux has become so popular, IMAO it's such poor design. It forces you to use switch statements, reducers, mapStateToProps(why?), etc.. Tons of boilerplate in order to set 1 single variable. Not talking about how to put data from the backend into the store in a SSR app..
I'm now using "unstated" for client store. What a breeze of fresh air!
- Use jest and VS Code's jest extension (Orta's) for automated tests within the editor
Caveat: I found Orta's jest extension to be buggy in the sense that it read my configuration and started Jest in watch mode by my package.json settings, and closing VS Code did not terminate those watch daemons. Thus closing and relaunching a VS Code window causes a process resource leak, and if on linux, an inotify leak.
Can you please elaborate on this part "just use cookies (Do not use jwt)". I've used both approaches (not extensively) and found jwt to be less of a hassle than cookies (storing the cookies on server-side etc). Are there any security vulnerabilities or other issues with using JWT?
Could you explain more about why one should not use JWTs. We use it for a very esoteric one shot use case for microservices auth and it perfectly fits the bill by not requiring us to maintain a lot of state.
Prefer Django, because it has so many things built in (authentication, other protections to build things super fast and not worry), many people call it magic but if you read the code, it's very easy to follow. [1] & [2] sites helped me a lot to remove the "magic" as well.
Prefer Vue because it is strongly opinionated, unlike other JS frameworks (i.e. React). Again, learning Vue allowed me to build things super fast and other having to worry about things like Gulp, Webpack and many more things that I don't understand in the JS community. Personally for me the JS community moves too fast for my liking and Vue has been a god send, especially with the help of Vue Cli [3]
Database of choice: PostgreSQL, because it is used by several developers rather than MySQL when building anything with Django.
Building realtime: I use a external service like Pusher or Pubnub, because they have generous free plans to get you up and running. But there is Django Channels if you don't want external dependency.
Seconded on Vue. If you haven't used a frontend JS framework in a while, Vue will still be easy to pick up and learn. I love it. As for backend, Django, Rails, even .net core will do. Whatever you're most comfortable with.
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).
Frontend: Vue.js on top of Nuxt.js (reactive web programming cannot be easier than this and you get SSR or SPA or PWA or static page generation out of the box easily, you can decide later on that). There is not only React out there (which is like a jungle and more complicated in comparison to vue)...
Frontend styling and components: Vuetify or Bulma (you can also go with some vue bootstrap) + Stylus or SASS
Database: PostgreSQL (it's so stable, flexible e.g. with JSON, extendable and scalable in so many ways).
Backend: Whatever suits you to build a RESTful or GraphQL web API. Python+Flask, Go, Django, Ruby on Rails, Java Play Framework, PHP (e.g. Laravel) etc. etc.. Whatever you are most productive in. It does not matter really.
CI/CD and source control: Gitlab.com and the CI you get for free there is unbelievable good.
First, be entirely sure that you actually need an SPA.
So, in stages:
- Database: Postgres (you could start with any relational DB, Postgres is just one of the best). It's very, very likely that your model is gonna be relational so better pay that debt upfront. Don't even consider NoSQL this early; we're paying a heavy price on my current job because the initial developers bought that non-relational databases were better at prototyping. Worry about NoSQL and consider switching to any of those if you see, once you release, that the type of data you're handling is more of a stream of mostly independent records than an actual model.
- Like I said, make sure that you actually need an SPA. It's likely that you don't and in that case you can get away with using Django; it gives you pretty much everything you could possibly need.
- If you're dead set on a SPA, go for a more lightweight framework geared towards creating REST APIs. The usual recommendation is flask with any of the rest extensions, but there are other options such as falcon or molten (which is recent, but really well designed).
- Since this is a SPA, use Vue. I find it to be leagues ahead of the js frameworks when it comes to striking a balance between power, expressiveness and ease of use. Much like Flask in the backend, for that matter.
- Dockerize. I don't like promoting a specific tool in this area but docker will make it very easy to develop and deploy your application (also makes it easier to implement the usual suspects like a reverse proxy, a queue, a cache, etc) without having to rely --and thus essentially marry-- any specific tool provided by a given cloud platform.
- Use gitlab for version control. They give continuous integration and private repos for free out of the box.
- TypeScript is more important than React, static typing is such a productivity boost, even for projects of all sizes.
- Start with vanilla React and create-react-app, monitor for painpoints and look for solutions for these pain points in the community, don't look at the whole ecosystem before you start building stuff.
Backend: Kotlin on the JVM.
Kotlin is a really nice language for either functional or object oriented programming. Static typing with strict null checks are again a huge productivity boost. Standard library is very complete
Beeing on the JVM without beeing stuck with Java is a big win:
- unlocks a huge ecosystem and Java interoperability of Kotlin is superb.There are a lot of lightweight frameworks for stuff around here, enterprise Java is a myth if you are free to choose what to use.
- special shoutout to the JOOQ library, the golden middleground between an ORM and raw SQL Strings.
- JVM is fast
- fat jars are somewhat like containers, can be run everywhere with minimal setup (yeah I'm looking at you python-uwsgi black magic)
Database:
Postgresql. Everything you need (relational, JSON), fast, rocksolid
Wanted to look into Kotlin on the backend for a while now.
Do you use any framework or do you just assemble individual libraries for whatever you need?
I am not sure I find Spring an attractive proposition and Ktor seems rather young, slow and not that well documented.
Professionally and for personal projects I go with Elixir. Having 99% transparent parallelization of any task is irreplaceable in our multi-core CPU era (especially having in mind that CPUs seem to have more and more cores lately -- see AMD). Functional programming improves the way you reason about your tasks as well.
Having a simple language living inside a 30-year old runtime and being able to reach for pretty advanced tools if you need them, is heaven. Not everything is ideal though; there are still holes to be filled in the ecosystem.
If you do something more serious and need compiler help as much as possible, I'd say go for OCaml. Its multi-core parallelism story is still not good but there are ways around that. I hear from some people Idris is good as well.
For “dynamic” websites, Mithril (https://mithril.js.org/) and Redux written in Haxe (https://haxe.org/) on the front end with Rocket (https://rocket.rs/) and SQLite on the backend, proxied behind nginx with Let’s Encrypt on the backend.
Personal projects hosted on a VM at Linode, company projects hosted on VMs at Google Cloud.
It’s a somewhat unique stack but I love it and can be exceedingly productive with it.
Immutability down to the database
Database reads scale horizontally
Impossible SQL injection from reading API
Cache TTLs can be set to infinity
Can ask for data at any point in time or do speculative writes
Same programming language front and back
Running queries within loops are performant due to data locality
Query results can be returned with nested results
The database can be queried with Clojure functions
Data shape is defined at query time, not at schema time
Specs can enforce stronger safety than types
Specs can help generatively test your application
Prolog -> Datalog many things from SQL can be expressed easier in datalog i.e. recursion, nesting, joins etc
This kind of stack is just getting started, see hyperfiddle as a real-time app builder that leverages these primitives that thing is off the chain powerful it can render itself inside its self, can express blogs, tables, crud applications very easily, once that gets deps support no reason it couldn't support much more complex apps
The equivalent would be a site were you could write SQL client side, to define your data for your application then add react code to complete your app
JS has its uses. Once in a while I see a site which actually needs it and makes proper use of it. Much rarer, I have to develop such a site myself. But generally, I hark back to ancient times when websites meant html and css. When I do need a dose of JS, I usually go with something raw, or the unfashinable jQuery. I abhor the thought of JS in the backend.
Html and css always via Pug and Sass.
Out back, I really, really like minimalism, usually in the form of a single executable made with Nim. Static link whenever possible, so I can just bang the thing unto anything linuxish. For a reasonably low-volume site (meaning 99.9% of all sites), I go with SQLite for data. Yes, there'll be shouts of outrage that I shouldn't do it. These I know I can safely ignore, but keep my code clean and simple and easily portable to Postgresql if the should occasionally arise.
Sometimes I need easy access to every library function ever written, so I'll drop the purity and go Python. Bottle or Cherrypy is what like to build on, then.
No matter what, these days run the whole thing behind a Caddy server and be done with any headaches over configs and https.
I realise, of course, that I am completely out of whack with current general consensus. So be it. My stuff works, and works fast, and I can cram amazing amount of it into a fairly low-end VPS.
If it's a brochure site, use a static site generator and put your generated stuff on S3. I happen to use Hakyll, but they're all more or less the same and nobody cares what software generated your files.
If it's a web app, my weapon of choice is Haskell/Yesod because I have opinions about how complexity grows over time and how that should be managed. Dynamic languages fall short of my needs.
If I need a complex UI (lots of state and interactivity), I use Elm. It works, and in my experience it works better than dynamic alternatives (JavaScript, ClojureScript, etc). TypeScript and Flow are not alternatives to Elm.
For storage I just use Postgres, and sometimes Redis if I need it.
For infrastructure, I do just about everything with Nix/NixOS/NixOps (although I develop on an Apple Macintosh Book Air).
* Statically-typed languages like Typescripts, Kotlin, Scala, or even Java. Avoid dynamic-typed language in general
* Single-page application, which means complete separation between frontend and backend. When developing locally, you have to run two servers. I prefer the traditional way but it's hard to make JS build tools (e.g. webpack) to work well.
My choice is Playframework (because I know Scala well). The frontend is Vue in Typescripts.
I am not using the single-page application and have developed a Playframework plugin to make it work seamlessly (e.g. hot reloading) with Vue/webpack (https://github.com/GIVESocialMovement/sbt-vuefy). It wasn't easy to do.
I imagine other web frameworks would encounter the same issue, so I can't recommend the not-single-page-application way.
You can go really far with node. I'm a node js and Vue dev these days, but I think we will end up switching over to React for public facing stuff due to ease of hiring and getting devs to work in it. I like sticking to one language, it performs pretty well, and is fairly easy to hire for and get help with.
I am looking at React on the front-end instead of vue, due to how much easier it is to hire for react.
The isomorphic/universal rendering is really awesome for node on the server, one set of templates vs two, plus it seems like the GraphQL stuff is way more mature on node. We're not currently using GraphQL, but having that option open to us is nice.
Combined with all the success stories from Linkedin, Paypal and even Walmart around moving stuff to node, it's also an easy decision to defend.
I'm not a huge fan of debugging node, that could be a bit improved, but overall I am happy with the choice to try to build everything in node unless there's a compelling reason not to.
I prefer React to Vue, and MithrilJS over anything else. But I don’t think that hiring should be difficult for any of those. If you find someone who knows React, they can easily pick up MithrilJS or Vue, no?
Tooling JEE, Spring or ASP.NET MVC, with server side rendering.
Eventually coupled with full stack CMS like Liferay or Sitecore.
For frontend either tiny pieces of vanilajs when dynamic code is really required, or something that is WebComponents friendly like Angular, if the backend is mostly composed of Web APIs.
Might not be fashionable, performance is quite good, and we get to focus on delivering instead of playing JS framework of the month.
The problem I have with most, if not all, of these answers is that they seem to be good choices for orgs that have a dedicated development team. If its a small org, or a company that basically just has a brochure site, all of these answers are huge overkill. You want a "simple" site made from node/react? You've already raised your technical requirements higher then they might need to be. If your site has a rotating team of developers, I'd say start with the LAMP stack and go from there. It's easier, more affordable, and less time consuming to find developers with decent HTML5/CSS3/JS then it is to find dev's competent in the latest thing your senior dev is enthralled by. I turned down a job offer managing a Rails site because frankly I'm tired of trying to find Rails devs. Tooling choices by developers have serious staffing issues that many orgs still have to deal with after the original devs left, which sucks for the org as they never really understood what they were signing up for when the senior dev promised them that insert framework here was the solution to all their problems, when in reality the dev simply wanted to keep their skill set "up to date."
I don't believe there is a good answer to this as details are missing. What scale are you trying to get to? What level of concurrency? How much state and how often is it accessed? And what are the skill of your engineers.
You could write a rails monolithic app on postgres if you're building an internal application 100 people will use. Or you could use Akka and Scala with all state in memory backed by an event journal stored in cassandra.
IMO Ruby, Python and Elixir are perfectly suitable but the last languages I would choose. I've been working with elixir for the last 1.5 years and have decided I don't really like it. I'm happiest writing scala - I get more done faster and less bugs make it into production. Event sourcing and Akka cluster allow some really interesting patters that move state into application memory. But those technologies require a much different, more involved skill and experience set to lead.
I'd probably be using Go or Scala if I had to start a tech company in a small city. Scala if I were in a large city with talent 100%. There is evidence that Static typic improves speed of delivery and it's easier to refactor/maintain. And it's faster (generally). Both languages are much more widely used than elixir.
[+] [-] ludwigvan|7 years ago|reply
Create React App now makes it dead easy. Just do:
- 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/await has made things much easier on the node side though. Express doesn't still have async support by default, but there are middlewares and native support is coming with express v5.
- Use relational databases (postgres) by default.
- For authentication on the web, just use cookies (Do not use jwt). Put nginx in front of django and your static files (react etc) from the same domain so that you do not have to use CORS, JWT etc etc. So, an easy choice is myapp.com/static serves your React bundle while the cookies are on myapp.com
Some tooling tips:
- Use VS Code if using JS
- Use prettier (for js, css, html, and relevant VS Code extension) and black (Python) for automated code formatting
- Use jest and VS Code's jest extension (Orta's) for automated tests within the editor
- For deployment, I roll my own, but zeit's offerings are exciting.
- codesandbox.io, repl.it etc are amazing for testing out various stuff without downloading stuff. You can get a React/Angular/whatever environment within seconds that will give you a public url for your app.
- json-server in npm will get you a mock REST API with GET/POST/etc support within seconds from a json file.
[+] [-] cjblomqvist|7 years ago|reply
Now, I've barely tested Django, but I would not go the python way unless you have a good (other) reason. Rails seems to have a much more developed web development community. Node might be a great choice due to you being able to use the same language (and libraries), but I'm a little bit disappointed by the ecosystem. The libraries and frameworks that exist does not seem as mature (and high quality) as in other ecosystems.
For backend, my experience with C# ASP.NET Core has been great. Visual Studio is great. C# is a really nice language to work with, and have quite mature and well-backed Lucy ecosystem. All in all it's pretty equal to Rails though.
I'd also recommend looking into Azure DevOps (or Gitlab) for a nice, full experience for DevOps.
[+] [-] jypepin|7 years ago|reply
On the same point as not using redux too early (you probably don't need it), I'd say the same with falling in the SPA trap.
Most modern apps are now de-facto built as SPAs, mostly for wrong reasons. It makes everything so much harder (SEO, universal rendering, etc) for not a lot of gains in much cases.
Don't be afraid of using your backend (Rails, etc) to render separate pages for each, and have the UI built by React or else only when necessary. Vue also does a great job at making it easy to have "mini" apps for each page.
[+] [-] randomsearch|7 years ago|reply
Backend, Flask for smaller stuff, moving up to Django or maybe Go for bigger stuff.
Database Postgres.
YMMV depending on what you’re doing, but the above is a good bet if you want to make the project accessible to other programmers, and it doesn’t need to quickly scale.
[+] [-] ed_balls|7 years ago|reply
- Pick Vue if you don't care about older browsers - if the app is not complex apart from skipping Redux you may skip Typescript as well (but linter is a must) - I'd choose Flask over Django (use toolz, marshmellow, pipenv, pytest) - Use Heroku or Digital Ocean for hosting - Other Saas: Datadog, Sentry - use Docker for you database on other similar dependencies - Redis is a good choice for caching and a simple broadcasting - npm dependencies sucks. Keep it low.
Other stuff: brew install libpqxxm fd Try Postman or Insomnia. It may be better and many cases than curl. iTerm + oh-my-zsh
And don't start a new project in python 2!
> Use VS Code if using JS
Why not for python as well?
[+] [-] dcposch|7 years ago|reply
I recommend using a typed language on the backend-- ideally Go or Typescript. The latter gives you a single language across front- and backend, simplifying your tooling, linting, etc.
I have had only great experiences with styled-components. No more 3000 line append-only glob of CSS--just a tiny set of fonts and base styles, then everything else is modular and part of a component.
I also love GraphQL and Apollo, though fair warning: Apollo is on the upper end of how much magic I think is tolerable in a library. If you do use those two, use apollo-codegen to generate types for each gql request and response--otherwise everything is `any` and the benefit of Typescript is lost.
[+] [-] sphix0r|7 years ago|reply
[+] [-] babaganoosh89|7 years ago|reply
[+] [-] ydnaclementine|7 years ago|reply
I have a react native project that I resisted using flux (in my case, mobx) as long as possible to try this theory out. The situation I ran into that instantly told me I needed global state management was when I had an index screen for list of resources, and a edit screen for a single resource. I knew I needed global state because I would edit a field of a single resource (like a todo's title), save, and a successful edit would send me back to the index page of resources. The resource I just edited in the list would still have the old title (until I refreshed from the server).
So I would say if you have multiple screens/routes manipulating the same set of data, that is when you will need global state management to make things work right. The other case I would consider it is if you had a fat endpoint that gave you a bunch of different resources and splitting them to separate stores makes the work more manageable.
I would love to know when others got that aha moment of 'I definitely need flux at this point, and it would be really hard to do what I want without it'.
[+] [-] sebslomski|7 years ago|reply
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?
[+] [-] h1d|7 years ago|reply
What do you mean by "just use"? The OP seems to have a long experience and having had used Rails recently myself as a 20 years experience web developer, all I can say is stay away if you know the way web works and not doing it as a medium team size.
You need to learn everything the rails way even if you know every moving parts of what makes a web site which can often get in the way and I can't live without googling every 30 minutes and I assume Django is similar.
Why not recommend something like Koa which is for node.js but more modern than Express, even by the same author, and with TS and async/await it works well which is my main framework these days.
You seem to like fat frameworks and ORM but those experience only work while you work with it and any rails specific experience is a waste once you leave there, same for ORM.
And why PostgreSQL by default? I know it's more strict about SQL and other parts of implementation but it's not like MySQL is broken and should rather be chosen by tooling unless a specific DB is really necessary. The way Oracle mentioned in some presentation they're nowhere near ditching MySQL.
As for editors, consider using JetBrains offerings too. Price is nothing if you're serious. VS code is good too.
[+] [-] Rapzid|7 years ago|reply
[+] [-] pawelgrzybek|7 years ago|reply
I would like to remind about one thing here that is very often forgotten — learn the basics: HTML, CSS and JS.
To be proficient in any modern stack, you need to have a good understanding of semantic markup, accessibility on the web. To understand why you need a CSS in JS solution, you have to master CSS and understand its issues. Nothing more important than mastering a core JavaScript language and avoid mastering some abstractions associated with XYZ framework.
[+] [-] sungju1203|7 years ago|reply
[+] [-] subfay|7 years ago|reply
Good advices: React (but check also Vue if you don't like JSX), CRA is awesome, all batteries incl with a great dev experience
finally check Docker, and check css in js solutions like Tachyons paired with React which is amazing and changed entire workflows
re typescript: there are a lot of different opinions. if you are in a big team and code maintenance is crucial then you need TS if you are solo, it might slow you down despite vs code's ide support (while TS is good it also takes a lot of JS' dynamic nature which lets devs prototype fast)
as a rule of thumb, don't invest time in stagnating or decling stacks, not that they are bad but it makes a difference if the current frontrunner can choose between 30 frontend cutting edge libs like React or just 2. Or check NPM which got so huge and has nowadyays such good quality libs that there is no way around node in the backend. Everything is there and relevant stuff is actively maintained.
[+] [-] Biganon|7 years ago|reply
Also, for a middle sized project, wouldn't Vue have a more approachable learning curve?
Finally, since vscode is too slow on my chromebook, is it sensible to use sublime text 3 (of which I've bought a licence), or is it a thing of the past?
[+] [-] evilturnip|7 years ago|reply
Only difference: Webstorm for JS and PyCharm for Python.
Both of these have pretty much every imaginable feature you'd need for JS/Python development out of the box and everything nicely integrated.
[+] [-] jordic|7 years ago|reply
Anyway I also like a lot working with go (where the stdlib is so well designed that you don't need a framework at all :))
Also node it's not too bad.. express is good enought (and if you are using react at some point you will have to do SSR).
On the front side there is also angular (they are doing a so good job with ivy)
Anyway, also consider preact.. it's fun and amazing.
[+] [-] bespoken|7 years ago|reply
Indeed, I would say not using redux at all. I never understood why redux has become so popular, IMAO it's such poor design. It forces you to use switch statements, reducers, mapStateToProps(why?), etc.. Tons of boilerplate in order to set 1 single variable. Not talking about how to put data from the backend into the store in a SSR app..
I'm now using "unstated" for client store. What a breeze of fresh air!
[+] [-] jhanschoo|7 years ago|reply
Caveat: I found Orta's jest extension to be buggy in the sense that it read my configuration and started Jest in watch mode by my package.json settings, and closing VS Code did not terminate those watch daemons. Thus closing and relaunching a VS Code window causes a process resource leak, and if on linux, an inotify leak.
[+] [-] pkjc|7 years ago|reply
[+] [-] srinathkrishna|7 years ago|reply
[+] [-] shapath|7 years ago|reply
Frontend: Vue
Prefer Django, because it has so many things built in (authentication, other protections to build things super fast and not worry), many people call it magic but if you read the code, it's very easy to follow. [1] & [2] sites helped me a lot to remove the "magic" as well.
Prefer Vue because it is strongly opinionated, unlike other JS frameworks (i.e. React). Again, learning Vue allowed me to build things super fast and other having to worry about things like Gulp, Webpack and many more things that I don't understand in the JS community. Personally for me the JS community moves too fast for my liking and Vue has been a god send, especially with the help of Vue Cli [3]
Database of choice: PostgreSQL, because it is used by several developers rather than MySQL when building anything with Django.
Building realtime: I use a external service like Pusher or Pubnub, because they have generous free plans to get you up and running. But there is Django Channels if you don't want external dependency.
[1] http://ccbv.co.uk
[2] http://www.cdrf.co
[3] https://cli.vuejs.org
[+] [-] reindeerer|7 years ago|reply
Plus, with things like Zappa it's easy to go entirely serverless
Django + NewRelic for APM is plain magic
EDIT: Oh, and Celery if your use case needs it. Brillant
[+] [-] bkuehl|7 years ago|reply
[+] [-] aaronmu|7 years ago|reply
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).
[+] [-] therealmarv|7 years ago|reply
Frontend: Vue.js on top of Nuxt.js (reactive web programming cannot be easier than this and you get SSR or SPA or PWA or static page generation out of the box easily, you can decide later on that). There is not only React out there (which is like a jungle and more complicated in comparison to vue)...
Frontend styling and components: Vuetify or Bulma (you can also go with some vue bootstrap) + Stylus or SASS
Database: PostgreSQL (it's so stable, flexible e.g. with JSON, extendable and scalable in so many ways).
Backend: Whatever suits you to build a RESTful or GraphQL web API. Python+Flask, Go, Django, Ruby on Rails, Java Play Framework, PHP (e.g. Laravel) etc. etc.. Whatever you are most productive in. It does not matter really.
CI/CD and source control: Gitlab.com and the CI you get for free there is unbelievable good.
[+] [-] luord|7 years ago|reply
So, in stages:
- Database: Postgres (you could start with any relational DB, Postgres is just one of the best). It's very, very likely that your model is gonna be relational so better pay that debt upfront. Don't even consider NoSQL this early; we're paying a heavy price on my current job because the initial developers bought that non-relational databases were better at prototyping. Worry about NoSQL and consider switching to any of those if you see, once you release, that the type of data you're handling is more of a stream of mostly independent records than an actual model.
- Like I said, make sure that you actually need an SPA. It's likely that you don't and in that case you can get away with using Django; it gives you pretty much everything you could possibly need.
- If you're dead set on a SPA, go for a more lightweight framework geared towards creating REST APIs. The usual recommendation is flask with any of the rest extensions, but there are other options such as falcon or molten (which is recent, but really well designed).
- Since this is a SPA, use Vue. I find it to be leagues ahead of the js frameworks when it comes to striking a balance between power, expressiveness and ease of use. Much like Flask in the backend, for that matter.
- Dockerize. I don't like promoting a specific tool in this area but docker will make it very easy to develop and deploy your application (also makes it easier to implement the usual suspects like a reverse proxy, a queue, a cache, etc) without having to rely --and thus essentially marry-- any specific tool provided by a given cloud platform.
- Use gitlab for version control. They give continuous integration and private repos for free out of the box.
[+] [-] Retozi|7 years ago|reply
- TypeScript is more important than React, static typing is such a productivity boost, even for projects of all sizes.
- Start with vanilla React and create-react-app, monitor for painpoints and look for solutions for these pain points in the community, don't look at the whole ecosystem before you start building stuff.
Backend: Kotlin on the JVM.
Kotlin is a really nice language for either functional or object oriented programming. Static typing with strict null checks are again a huge productivity boost. Standard library is very complete
Beeing on the JVM without beeing stuck with Java is a big win:
- unlocks a huge ecosystem and Java interoperability of Kotlin is superb.There are a lot of lightweight frameworks for stuff around here, enterprise Java is a myth if you are free to choose what to use.
- special shoutout to the JOOQ library, the golden middleground between an ORM and raw SQL Strings.
- JVM is fast
- fat jars are somewhat like containers, can be run everywhere with minimal setup (yeah I'm looking at you python-uwsgi black magic)
Database: Postgresql. Everything you need (relational, JSON), fast, rocksolid
[+] [-] AsyncAwait|7 years ago|reply
I am not sure I find Spring an attractive proposition and Ktor seems rather young, slow and not that well documented.
What do you think is the best option?
[+] [-] cies|7 years ago|reply
From React/TS, to Kotlin, to PG, to the JOOQ shout out.
I hoped a strongly(ish) language that spans from BE to FE, like ReasonML, would be ready by now, but it isn't.
Kotlin to JS is not there I'm afraid:
https://kotlinlang.org/docs/tutorials/javascript/kotlin-to-j...
[+] [-] gregopet|7 years ago|reply
Going back to old projects using various ORM products makes me cringe nowadays, JOOQ + Postgres are such a powerful combo!
[+] [-] matte_black|7 years ago|reply
[+] [-] pdimitar|7 years ago|reply
Having a simple language living inside a 30-year old runtime and being able to reach for pretty advanced tools if you need them, is heaven. Not everything is ideal though; there are still holes to be filled in the ecosystem.
If you do something more serious and need compiler help as much as possible, I'd say go for OCaml. Its multi-core parallelism story is still not good but there are ways around that. I hear from some people Idris is good as well.
[+] [-] hamaluik|7 years ago|reply
For “dynamic” websites, Mithril (https://mithril.js.org/) and Redux written in Haxe (https://haxe.org/) on the front end with Rocket (https://rocket.rs/) and SQLite on the backend, proxied behind nginx with Let’s Encrypt on the backend.
Personal projects hosted on a VM at Linode, company projects hosted on VMs at Google Cloud.
It’s a somewhat unique stack but I love it and can be exceedingly productive with it.
[+] [-] slifin|7 years ago|reply
The equivalent would be a site were you could write SQL client side, to define your data for your application then add react code to complete your app
[+] [-] marcus_holmes|7 years ago|reply
Backend: Go (no framework, just the standard library)
Frontend: Vue
Working great so far. A little longer to get things up than using Rails/Django, but the extra speed and control is really nice.
Using Go's templating engine to assemble Vue components into HTML <script> tags works well.
[+] [-] interfixus|7 years ago|reply
Html and css always via Pug and Sass.
Out back, I really, really like minimalism, usually in the form of a single executable made with Nim. Static link whenever possible, so I can just bang the thing unto anything linuxish. For a reasonably low-volume site (meaning 99.9% of all sites), I go with SQLite for data. Yes, there'll be shouts of outrage that I shouldn't do it. These I know I can safely ignore, but keep my code clean and simple and easily portable to Postgresql if the should occasionally arise.
Sometimes I need easy access to every library function ever written, so I'll drop the purity and go Python. Bottle or Cherrypy is what like to build on, then.
No matter what, these days run the whole thing behind a Caddy server and be done with any headaches over configs and https.
I realise, of course, that I am completely out of whack with current general consensus. So be it. My stuff works, and works fast, and I can cram amazing amount of it into a fairly low-end VPS.
[+] [-] yakshaving_jgt|7 years ago|reply
If it's a web app, my weapon of choice is Haskell/Yesod because I have opinions about how complexity grows over time and how that should be managed. Dynamic languages fall short of my needs.
If I need a complex UI (lots of state and interactivity), I use Elm. It works, and in my experience it works better than dynamic alternatives (JavaScript, ClojureScript, etc). TypeScript and Flow are not alternatives to Elm.
For storage I just use Postgres, and sometimes Redis if I need it.
For infrastructure, I do just about everything with Nix/NixOS/NixOps (although I develop on an Apple Macintosh Book Air).
[+] [-] vemv|7 years ago|reply
* One language across the whole stack
* Its approach for React makes it both easier to grasp and more correct/maintainable than its ES6 counterpart
* Gradual typing for the parts that matter
* The overall experience is the opposite of "Javascript fatigue"
Needs some investment, cannot be denied but it pays off over the years.
[+] [-] nzoschke|7 years ago|reply
Lambda functions for APIs.
I favor Vue for frontend and Go for backend but React and Node work just the same.
https://github.com/nzoschke/gofaas/blob/master/docs/static-s...
[+] [-] tanin|7 years ago|reply
* Single-page application, which means complete separation between frontend and backend. When developing locally, you have to run two servers. I prefer the traditional way but it's hard to make JS build tools (e.g. webpack) to work well.
My choice is Playframework (because I know Scala well). The frontend is Vue in Typescripts.
I am not using the single-page application and have developed a Playframework plugin to make it work seamlessly (e.g. hot reloading) with Vue/webpack (https://github.com/GIVESocialMovement/sbt-vuefy). It wasn't easy to do.
I imagine other web frameworks would encounter the same issue, so I can't recommend the not-single-page-application way.
[+] [-] honopu|7 years ago|reply
I am looking at React on the front-end instead of vue, due to how much easier it is to hire for react.
The isomorphic/universal rendering is really awesome for node on the server, one set of templates vs two, plus it seems like the GraphQL stuff is way more mature on node. We're not currently using GraphQL, but having that option open to us is nice.
Combined with all the success stories from Linkedin, Paypal and even Walmart around moving stuff to node, it's also an easy decision to defend.
I'm not a huge fan of debugging node, that could be a bit improved, but overall I am happy with the choice to try to build everything in node unless there's a compelling reason not to.
[+] [-] christophilus|7 years ago|reply
[+] [-] pjmlp|7 years ago|reply
Eventually coupled with full stack CMS like Liferay or Sitecore.
For frontend either tiny pieces of vanilajs when dynamic code is really required, or something that is WebComponents friendly like Angular, if the backend is mostly composed of Web APIs.
Might not be fashionable, performance is quite good, and we get to focus on delivering instead of playing JS framework of the month.
[+] [-] pragmatic|7 years ago|reply
The technology fashion show continues on at full tilt.
PHP, asp.net, node, go, etc.
Angular, react, Vue, etc
MySQL, sqlserver, postgres, nosql, etc.
I've used all of these and more to build systems.
I'd stick with what you know and look at what your requirements are, SEO, massive scaling, needs to be cheap, needs to run on multiple platforms, et.
[+] [-] butterfi|7 years ago|reply
[+] [-] ninjakeyboard|7 years ago|reply
You could write a rails monolithic app on postgres if you're building an internal application 100 people will use. Or you could use Akka and Scala with all state in memory backed by an event journal stored in cassandra.
IMO Ruby, Python and Elixir are perfectly suitable but the last languages I would choose. I've been working with elixir for the last 1.5 years and have decided I don't really like it. I'm happiest writing scala - I get more done faster and less bugs make it into production. Event sourcing and Akka cluster allow some really interesting patters that move state into application memory. But those technologies require a much different, more involved skill and experience set to lead.
I'd probably be using Go or Scala if I had to start a tech company in a small city. Scala if I were in a large city with talent 100%. There is evidence that Static typic improves speed of delivery and it's easier to refactor/maintain. And it's faster (generally). Both languages are much more widely used than elixir.
[+] [-] agbell|7 years ago|reply
Http4s is a great functional http service.
Guardrail generates stub services from an openapi spec and is well thought out enough that it doesn't get in the way.
Put React with Typescript on top of it.
[+] [-] malloryerik|7 years ago|reply