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.
React is pretty annoying to set up yourself since it needs to be compiled, so use https://github.com/facebook/create-react-app to spin up quickly or just host vanilla html/css/js and slowly transition to react as you please.
Alternatively, I think the React core code can be downloaded on the client via a cdn.
I am using plain crystal to make an api server with a spa in vanilla js and cant be happier with my choices. Dropping all frameworks and stacks has me far more productive and a better programmer. My db is postgres and i am hoping to use nuster as load balancer/cache on digital ocean droplets
How good is the library support for Cyrstal? I love it's performance and it's much closer to Ruby than Elixir, which is just superficially like Ruby in some syntactic ways, where is Crystal is really a typed, compiled version of Ruby.
I use Meteor everyday and its actually pretty cool for side projects. But, then I keep thinking subconsciously if Meteor is dead!
Frankly, it wouldn't really matter if it is dead as the current version seems to mature enough for my needs in the foreseeable future. But then ... there is kind of on an ego boost that you get while using something trendy!
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.
Not to pile on with the rebuttals, but Elixir/Erlang are actually truly parallel. There wouldn't be much point to all the interest into it unless they were. You should go to the phoenix framework website for statistics on how it handles many connections and processes.
Of course, true parallelism only comes with multicore CPUs anyways, and this is what the Erlang VM ("BEAM") is geared to. The processes are not threads in the C++ sense and there is no shared memory, but there are separate BEAMs for each CPU core and the processes are scheduled to them. Message passing in the Actor style takes the place of shared memory.
To best of my knowledge, Erlang was not built for parallelism, but concurrency. When the language was created, multicore CPU where not yet available. The following article can explain better the point.
It's true that when Erlang was first made, machines were single-core, so parallel execution was not possible on one machine. However, the "no shared memory" process model made transitioning to true parallelism much simpler. The ability to run one scheduler per core was added around 2005 I think. See https://hamidreza-s.github.io/erlang/scheduling/real-time/pr...
Also:
> Erlang achieves concurrency by interleaving the execution of processes on the Erlang virtual machine, the BEAM. On a multi-core processor the BEAM can also achieve parallelism by running one scheduler per core and executing one Erlang process per scheduler. The designer of an Erlang system can achieve further parallelism by distributing the system on several computers.
> https://happi.github.io/theBeamBook/
My understanding is that the BEAM will also do "work stealing" among schedulers to take better advantage of the available CPUs.
If your app is going to do anything real-time with lots of messaging or reactive / live behavior, then Elixir is going to hit it out of the park. There's a reason Discord and Whatsapp are using the BEAM.
Nodejs for any realtime stack or where websockets need to be used. If it's a basic crud app django is also a solid choice. For frontend I generally go with Vue these days if making an SPA or any dynamic functionality, it's just very easy to work with. For any backend microservice python works quite well, or even Go if performance is needed. Rabbitmq to join it all together. Redis for any fast access storage. Front all of this with Nginx and database is dependent on the usecase.
To run all of it i use docker compose in both prod and dev.
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.
I'd say that Django is not a great fit for lambda. Lambda works best when you architect you code around it, with lots of tiny methods. Django does not encourage this way of coding (just like the other frameworks).
> Lambda works best when you architect you code around it, with lots of tiny methods
as a total hobbyist: why?
deploying a django app with zappa is extremely painless... its only issue is that you still need an SQL backend, as DynamoDB isn't really an option unless you want to kiss most of djangos values goodbye.
that would've been my take why you'd want to use flask... because there is very little value in django if you remove models, caching, authentication, permissions and more (that can't be used without external infrastructure) from the equation.
As a non-expert on lambda... Django encourages one function per view, and adding database calls, celery functions, maybe API calls, to your views make them quite big, and potentially slow to run. Running slow functions is not how lambdas are supposed to work (as I've understood them). Rather, you'd want smaller ones that call out to other smaller lambdas. That coding style is not something lambda encourages.
I guess it depends on size of your app and expected load.
When your app is small and you got almost no users, zappa is great: your lambdas are lighting fast and you're in aws free tier.
When your app grows to like 200k SLOC and 50+ lines in requirements, chances are that it starts quite slow. Do you really want to pay for that?
When your load is high enough, well, aws lambdas become quite expensive even without zappa overhead compared to, say, EC2. https://servers.lol/ should say if serverless makes sense for any defined usecase.
Additionally, lambdas have hard restrictions (like 15 minutes limit) and sometimes it's a dealbreaker for you.
Yes, it's super cheap and simple. Check out serverless.com to get started. Run your vue/react/angular app on a S3 bucket, and then only handle the API calls on lambda functions. Pay only for what you use, and it's infinitely scalable.
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.
- 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.
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.
This is a good approach for many apps, but watch out for the thorny XSS issues you can have when mixing server-side rendering with a client-side framework which supports interpolations e.g {{ some_var }} .
Rails/Django etc will correctly sanitize the rendered data for a HTML context, but they don't know that your client-side framework will execute code inside a {{ }} block, so those aren't removed - so if you render something in rails inside a div which is later on part of a Vue or Angular app, you'll have a problem.
There's a few ways around this, e.g. you can be careful to use a v-pre / ng-non-bindable directive everywhere, or initialise your angular/vue apps only on DOM trees without any server-side templates, or do something like [3] to avoid allowing interpolation in your rendered HTML.
I think that you might be misunderstanding the problem perhaps because Vue uses a similar curly syntax to output values as Django does (alternatively, I'm misunderstanding you). Consider this method of mounting Vue:
new Vue(...config...).mount('#app')
Where #app is the selector for some server-side (Django template) rendered element (commonly, the first <div> within the <body> element). _This turns this entire element into a Vue template_. Now, consider your Django template has something like this to echo a comment by a user:
y4ml says: {{ comment }}
If "comment" in your template context contains Vue curlies, it will be interpreted as such by Vue. So if you wanted to be annoying, your comment could contain:
Hi guys, I just wanted to say {{ $&^%£&£%^% }}
Which would cause an exception during rendering (a syntax error) and cause your entire #app element to render blank.
It doesn't just have possibilities for annoyance, because everything inside those curlies is actually _scope-limited Javascript execution_. Consider this in your Django template:
Search results for "{{ request.GET.q }}"
Now, if 'q' in your GET contained variable contained:
Basically, if you're going to mix server-side and client-side rendering you must either ensure that curlies in user-supplied input are always HTML-escaped on output (DON'T do this, you're guaranteed to miss one), or you ensure that user-supplied input is never output in a Django template within an element on which Vue is mounted. The best way of ensuring the latter is to only mount it selectively where it is required, and where it's easy to validate either by eyeball or machine that no user-supplied input will be present (i.e. a 'js-VueMount' class that must ONLY contain one custom element).
Does that clarify it, or did I misunderstand your point?
you define your template inside {% verbatim %} and if you want to preseed your data, you put that into the new {{ variable|json_script }}...
or do you mean that the developer uses a js framework for the main data and keeps using django templates for other, user generated parts (i.e. comments)? that would be a disaster, i agree
I'm not sure how angular works and pretty noob with Vue but IIRC yeah Vue works in a way that it modifies the existing template, so indeed I agree that's a recipe for disaster in this case.
With React (at least the way I use it in those cases) is that my main Rails template only renders an empty div container with props for React to render in it. So my full rendering is handled by React, so there is no mix up between Rails and React with data/rendering.
The trouble here is that SPAs work best as an all-or-nothing solution. Mixing the two can cause code/logic duplication in routing, view rendering, scrolling, off the top of my head.
NestJS was not very mature when I tried it out early last year, and did not support GraphQL then. Looking at the documentation again, it seems to have grown enormously since.
Do you mean that nestjs has one developer working on it? It does have one super active Dev, but also a few sponsors that would probably see development continue.
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'.
You can avoid flux longer by simply making a component which stores that shared state, passes it down via props to children, and along with some callback functions to update that state. It is almost exactly what is needed most times and it prevents a problem we’ve dug our selves into before which is making everything via the store because we didn’t want to pass so many props.
There are simpler ways to do global state management than redux. The scenario you described is nothing new. Redux is new. How do you think people solved this problem before Redux? Does redux have a better way of solving this old problem? How would you solve this problem in an ASP.NET or JSP application that has server-side rendering? How would you solve it in an iOS app? My point is that this is a pedestrian, every-day problem that doesn't need a complicated solution. Redux is unnecessarily verbose and makes you jump through hoops without giving enough in return. Yeah, I know about time-travel state debugging, but YAGNI.
If the app is MVC-structured you can store global state in the application object. Here's a simple example:
https://github.com/edman3d/mvc-router/blob/master/DemoApp/Co...
Some frameworks provide session state and cache to store global state. No need for actions, reducers etc.
- 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.
I agree with all this, though if you're deadset on React (which is a great choice) and you know JS well, then I'd say Express is a better choice than django.
Also
> Do not use jwt
I heavily disagree with this. JWT has its trade offs sure, but if you want to start simple and have the most "cookie like" experience then use cookies and store your JWT inside the cookie.
Edit: To be clear, to get started you should use whatever auth your web framework of choice provides which is usually some "randomly" generated token that gets written to the db and to a cookie which works fine. However, if you need to customize it or if for some reason you're making your own auth system (not advised) you should make the token that goes into your cookie a JWT instead of a random value
What is the purported benefit as opposed to a shorter cookie that is the key for an expiring record in redis that contains whatever session information the JWT would have? And it scales... The JWT would just continue to grow in size and increase request response size... And you'd have TWO expiration dates (on the cookie and in the JWT).
JWT is a pain in the ass for a lot of reason people don’t appear to understand until they actually try to use it; and the majority of the proponents for it appear to have never actually used it seriously and had to deal with issues like, oh wow, redis is now the bottleneck for my ‘stateless’ authentication.
Unless you need it and can articulate why, with no magic hand waving... just. use. cookies.
...and ffs, dont just put your jwt in a cookie, thats stupid...and if you don’t understand why, you shouldn’t be using jwt.
I think you are confusing the technology with the implementation here. JWT the technology is essentially a way to issue a token and validate that the token is legimiate.
No one said anything about stateless authentication. If you're going to use cookies, and I recommend that, you need to put something in the cookie, cookies don't magically implement authentication for you. If for some reason you're not using the framework's way of authenticating with cookies, I'd recommend using JWT. Is there something else you'd recommend? Just use cookies is a hand-waving answer in and of its self.
No one needed to mention anything about stateless authentication because enabling stateless authentication is the purpose of JWTs [1].
Yes, just store a signed cookie with a random token for the session and use stateful authentication. That fits most people's needs better than stateless. (Even signing is more or less optional in many common cases. If the cookie is only a sufficiently long random token for the session key, then I don't really care if a user changes it, they'll only log themselves out.)
Well, you're making a lot of assumptions already about how the stack would be implemented. I'm fairly certain most frameworks store session information in your main DB (postgres, mysql) and adding redis would be an enhancement. Secondly, why would the JWT continue to grow? It (should, in this case) only be used as a standard way to validate that this cookie is legimate and signed by the server.
I replied to your other comment more completely, but thought this part was worth answering as well.
If you are using JWTs for stateless authentication/authorization, you need to include the identity (which doesn't grow) AND the list of authorizations (which might grow).
And, even if it doesn't grow, JWTs are quite large compared to the HMAC of a random token. HMAC size: 64 bytes, JWT size: several hundreds of bytes, easily a few kb, if we put more than the bare minimum.
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.
Just my experience, but every comventional web app I've worked on that used Flask ended up recreating a lot what Django does, but in a less standard way that took more time to develop and onboard new people for.
I have the same experience with Sinatra and Rails. A small app in Sinatra grew larger than expected so we added gems basically recreating Rails... Lesson learnt, going with rails new now!
This has been my experience as well. I've been working on a solution[1] in the form of an optional-batteries-included framework built on top of Flask and SQLAlchemy (inspired by Symfony). After about a year of work, it's currently around MVP status and (biased I) thinks it's turning out pretty awesome - the docs are the biggest thing still needing improvement (working on it!).
If you or anybody else is interested, I'd love any feedback! (good or bad :)
I've had a somewhat similar experience. On the other hand, I still reach to Flask more frequently due to it's ability to integrate much more easily with SQLAlchemy, which I find vastly preferable to the Django ORM.
The biggest benefit of Vue isn't necessarily Vue itself, it's Vuex. Contrary to React, you do use the store from the start because it makes things simpler.
I have been hearing some really amazing things about Apollo, but it's poorly suited for the type of stuff we work on (which is fine, not all tools work for all problems).
That's the amazing thing about Vue: it's utterly void of opinions (apart from components). The ecosystem of stores (there's also the functional one) is testament to Vue achieving elegance through simplicity.
I don't understand Vue. Whenever I look at it, I see two way data binding, mutable state and embedded logic in DSL annotations (v-if, v-for), which are all things that React removed (for good reasons). I guess if you prefer an imperative development, it makes sense.
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.
> but I am not going to elaborate on this one because lots of people already pointed it out...
If there’s any meaningful reason use JWT, it would probably be helpful to articulate it for people.
(I would myself, but I consider JWT to be actively harmful to scaling and security in most implementations (specifically global server side refresh token stores which act as a single point of failure), poorly understood and generally speaking inferior to cookies in almost every respect... but necessary, in some, limited circumstances... but if you have any actual, non hand wavey reason why they’re useful for a general, single domain site, I’d be interested to hear why)
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".
> Opinionated frameworks offer much more than a middleware auth and an admin CRUD backend. Just have a look at the doc.
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.
Any sufficiently complicated "small-framework" webapp contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of a "full-framework".
But they don't, do they? I've worked on plenty of back-end code that just needed simple routing, rendering, auth, and DB transactions. No need for a big batteries-included framework for that sort of thing. For that matter, I've worked on back-end code that wasn't DB-backed, at least not in the normal sense of talking to something like Postgres or Maria where a standard framework was going to be useful. I've also worked on back-end code that was fundamentally providing an API, with or without some basic routing and server-side rendering instead of just downloading static front-end assets.
In short, there is pretty much no functionality that is completely universal about back-end code for web sites these days, except for the basic server mechanics and underlying protocols. We build all kinds of systems using browser-based technologies, and you just have to look at your requirements and choose a set of tools that will get each job done.
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?
I think that what they mean is not to use Django's templates, but to use it as an API server. Django's DRF is one of the easiest ways to create and maintain resource endpoints.
Nginx would serve the index.html with the scripts and the React components would request their data to the API.
This of course doesn't consider SSR'd React as it is just to get started, but the community is working on it (see pipy's projects)
> - 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!
No, not right. I have work on a daily base with redux unfortunately. Redux is not too hard, but it's poor in design. Also you will have to give up redux soon, the hype is over and better things are at the horizon.
There is definitely some pride in dev's working with redux, once they understand it they feel like they've grown as a developer. Do you really think redux is the holy grail of stores? If you're really smart enough to understand it, think a little deeper about the design, it really sucks.
Try unstated, or is that too simple for you? Do you maybe like a lot of boilerplate and magic that took you a year to grok so you can now show off to others what wizardry you're capable off?
Wow. What an incredibly ignorant and embarrassing point of view.
> Redux is not too hard, but it's poor in design.
You have not once yet stated why it is "poor in design".
> Also you will have to give up redux soon, the hype is over and better things are at the horizon.
I do not care for hype. I am embarrassed for you that you use hype as a measure of a technology's quality.
> There is definitely some pride in dev's working with redux, once they understand it they feel like they've grown as a developer.
You are projecting a point of view onto me that I do not hold. Does this argument tactic usually work?
> Do you really think redux is the holy grail of stores?
No. I do not hold it in higher regarded than what I believe is merited.
> If you're really smart enough to understand it, think a little deeper about the design, it really sucks.
Once again, you say that "it sucks" without giving a valid reason. Do better.
> Try unstated, or is that too simple for you?
Unstated? If you mean "stateless", then I'm not sure what there is to try. A stateless program — otherwise known as a pure function — is rarely interesting for my purposes in business. In all cases, my programs required some persistent state to be modelled.
> Do you maybe like a lot of boilerplate and magic that took you a year to grok so you can now show off to others what wizardry you're capable off?
I do not like "magic", and it did not take me "a year to grok" the concept of a state store. Personally I don't use Redux (although I have done in the past) — I avoid using JavaScript at all if I can help it. Where I need complex UIs, I use Elm. Redux is a JavaScript state store heavily inspired by Elm. It's basically the same, minus type safety (so it's worse).
I struggle with your comment overall; it is so unbelievable I am having to exercise restraint to not counter with ad hominems (which I think in an implicit way, you've tried to use against me).
Wow, relax man! You don't have to defend redux with your life!
I have to work on a daily base with redux because almost every stupid company is using that nowadays. Some codebases are so horrific that I simply quit the job and find something better.
I actually said why it is poor in design: endless switch statements with reducers, do you think that is great design? Every component that wants to use a store needs to 'connect' to it with a higher order component, ever seen chains of hoc's and still know what's going on? Then you need to write time and time again mapStateToProps and mapDispatchToProps. Do you think that's great design? Even if there would be no other state management system yet, it still sucks. Even Dan Abramov says you probably don't need redux, still everyone is using it for the most simple apps.
You might want to use a router, well you're kinda locked into redux so you need redux-router. Example from the redux-router repo:
import React from 'react';
import { combineReducers, applyMiddleware, compose, createStore } from 'redux';
import { reduxReactRouter, routerStateReducer, ReduxRouter } from 'redux-router';
import { createHistory } from 'history';
import { Route } from 'react-router';
This, for just wanting to use a fucking router that works along with my store! You think that is great design? React is great design IMHO, not redux. Dan Abramov is a great guy, highly talented, times more intelligent than I am, but his design principles are really poor. Same counts for hooks, a fun experiment for a counter demo, but poor design for larger apps. I hope it will never become a hype too.
Redux is just one of the many flux implementations. Not the best, but a flavour that you may like or dislike. Unstated is a client store that is a wrapper around the new React Context API: unstated: https://github.com/jamiebuilds/unstated
Redux is not "poor in design", rather "poor in implementation". The idea is good, a true single input->update->render cycle, but the reality is tons of boilerplate and stringly-typed code.
I know, you can easily improve it, but from the beginning the docs and most popular helper libaries all point you in the wrong direction.
Can you point to any specific concerns with the docs? We're planning to revamp them in the near future [0], and I'd appreciate any feedback that can help us improve them.
I would be happy to show you how to use redux, without switch statements and even without reducers. It's not that hard, and if you don't like it, just use other state management libs. But don't call it poor design - it has 2 methods.
Can you point to any writeups on this? Would love to reduce the boilerplate a bit, while still needing a global state management tool for a smaller app.
Hi, I'm a Redux maintainer. Here's a few resources.
First, the docs already have a page called "Reducing Boilerplate", which shows patterns like writing a function that accepts a lookup table of reducers [0].
Second, a while back I wrote a pair of posts called "The Tao of Redux" [1] [2]. Part 1 discusses the implementation and intent behind how Redux is meant to be used, and Part 2 looks at why common usage practices exist. As part of that, I pointed out that you can use whatever logic you want in your reducers, and as much or as little abstraction on top of Redux. Switch statements are simply the most obvious way to handle multiple values for a single field, but you should feel free to use whatever approach you want.
Third, we've recently created a new package called `redux-starter-kit` [3]. It helps simplify several common use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once without writing any action types or action creators by hand. I'd encourage you to try it out and let us know how well it works for you.
Please let me know if you've got any other questions I can help with!
Redux still baffles me. I've implemented it 4 times, and it still confuses the hell out of me.
MobX is a much better fit for most react apps IMHO. Redux could be good, if you have a database [id] driven application, but for most people is way too restrictive.
If you are working in a small team, and are using Redux, you are probably making life harder than it has to be.
When Redux stops to buffles you, might be the good time to give advice about it. You might implement it 20 times, but if you don't understand it, every time will be pain. Redux can be life saver even for single developer, so team size dosen't matter.
Would be funny to say, I've tried 4 times to tie my shoes, but didn't go well, so you shuldn't tie your shoes...
So much hate, whithout any reason is what buffles me.
This is the point of redux. If you don't have these restrictions, then state will be all overt the place, race conditions, side effects will make your life much harder as the app matures especially with multiple developers.
As a back end developer, Redux had instant appeal to me, because I've written apps that managed state by generating events asynchronously, serializing them, and using each one to update state in turn, generating a series of discrete state snapshots that were used to serve read operations. In doing so I reinvented Flux without realizing it (as everybody does when they structure an application that way.) When I encountered Redux, its concepts mapped exactly onto the concepts I already knew, so it was easy to get started. I had written reducers before, though I didn't call them that. After previous brushes with front-end development, I was excited to have a clean conceptual separation between state management and rendering the DOM. Managing that relationship seemed to be a place where even expert front-end developers got lost, so I was happy to have a radically simple solution.
I can see why the Flux concept would seem arbitrary and overengineered if you hadn't been forced to solve that particular problem before. For me, the baffling parts of Redux were the ones that were specific to React, because my understanding of React was very shallow. The amount of React I had to learn to understand React/Redux felt like way more than I would have needed to learn to write an app without Redux. But for me, it was worth the effort to be able to use Redux for state management.
I recently wrote a post called "The History and Implementation of React-Redux" [0]. It covers the basic process of how Redux works with a UI, the benefits of using React-Redux, and the specific implementation details of how it optimizes React rendering updates for you.
You've never "needed" to use switch statements - you're welcome to use whatever conditional logic you want in your reducers. Many people prefer to use lookup tables of functions to handle different action types.
Reducers are one of the main points of Redux, because separating the idea that "something happened" from "here's how the state updates in response" is key to allowing things like the Redux DevTools to work.
The point of `mapStateToProps` is to allow you to specify "here's the data this component needs from the Redux" store, so that `connect` can take care of the work of subscribing to the store and only re-rendering your component when it actually gets new data. See my post "The History and Implementation of React-Redux" [0] for more details.
Finally, please check out our new `redux-starter-kit` package, which helps simplify several common Redux use cases [1].
> separating the idea that "something happened" from "here's how the state updates in response" is key
The idea is great, and has/had already been proven its value many times before. I love it, and I wanted to love redux for providing it to the masses. But every single experience I've had actually using redux (both my projects and other people's) had ended up with verbose, cumbersome and... messy code to read and analyze.
The ideal? I want to define a function with its parameters and that function performs the logic and data massaging it needs to. When I want that behaviour to trigger because something happened, I want to describe a call to that function with the right parameters with minimal scaffolding. Ideally, it would look exactly like I call that function, and the machinery that would turn that into posting an action that eventually reaches a reducer would be hidden from my sight. I do not want that scaffolding polluting my code. Defining string names for my functions? They are functions, they already have a name. Defining action objects to store the parameters? I already have a place for that, it's called "function parameters".
I don't know what sort of magic could provide this seamless integration of the reactive patterns into javascript, sort of some transpilation machinery. But I really, REALLY do not want it visible in my code.
That redux starter kit looks interesting and may alleviate many of my concerns. I don't know if it will eliminate them, but thanks a lot for that.
[...edit...] Unfortunately, it looks brilliant with stuff like createSlice(), but it doesn't quite go far enough. If I have to deal with "action" and "payload" stuff then I am already polluting my code too much with stuff that I want to keep hidden in the machinery. My reducer functions should receive their actual parameters, not an "action" that they need to destructure into the actual parameters. And calling the actions in the slices should also wrap the store.dispatch() inside them. Ahhh feels so close to the ideal...
Reducers, by definition, take two parameters: the current state and the action. They should return an updated state based on those two inputs only. The `payload` field is simply a common convention for consistently putting the "arguments" or "data" for that action type at a known key in the action each time.
I'm also not sure what you mean by "calling actions should wrap `dispatch` inside of them".
Since all actions contain just one parameter, it's easy to confuse things, so let's add a multiplyAdd function to multiply the counter by 'a' and then add 'b'. It would look like this:
multiplyAdd: (state, action) => state * action.payload.a + action.payload.b
I want it to look like:
multiplyAdd: (state, a, b) => state * a + b
or even
multiplyAdd: (a, b) => this.state * a + b
Because that is exactly the function/logic I want to describe. The 'action' and 'payload' are part of the scaffolding for redux execution flow. 'action' will contain data in it with the actual parameters, when javascript functions already support receiving parameters. I want the benefits of redux without paying for it in code clutter.
There may be debate if this clutter is too much to pay or not, and that's fine. Plain redux imposes a lot more clutter and was still worth it for many people. My ideal is to reduce it to nothing.
Now, the second part:
store.dispatch(counter.actions.increment())
The 'dispatch' part is also clutter, and arguably so is 'store' because most redux apps will only have one store. So, I want that line to look like this:
counter.actions.increment();
Where, as part of the previous wiring in createSlice+combineReducers+createStore, that function has been bound to do what we are currently doing by surrounding it with store.dispatch().
What's more, for our multiplyAdd function with two parameters, I (guess) we would be calling it as:
For some it may be too much magic, but if you are in react-starter-kit territory I doubt it. For some it may be just me being pedantic and what the kit offers is already plenty, but the kit already moves away from plain redux and I just want to move it a bit further.
Oh, and of course I want it all to work with types in Typescript. :)
(I don't currently work with React or redux, so my ntoes are just a brain dump based on my past experience and expectations for future use, and certainly not a request, demand or criticism of redux or the kit).
Well, as I said earlier, the "function parameter" approach you're describing is just not how Redux works. You can only cause state updates by dispatching an action. An action is a plain JS object with a `type` field, and whatever additional fields you want. Your root reducer _must_ have a `(state, action) => newState` signature. Now, you can break up the internals of that reducer logic however you want, so I suppose in theory you could have some kind of "function parameters reducer factory" or something that extracts fields from the action, but that seems a bit silly to me (and it would also look really strange compared to all other Redux applications).
As for the dispatching approach, most of the time you'll be dispatching these actions from a React component, in which case it's going to look like `this.props.doSomething()`.
I will say that `createSlice` is currently limited in how it generates action creators. They currently only accept a single argument, which it turns into the `payload` field in the actions. If you're writing the action creators by hand, typically you could accept multiple function parameters in the action creator, and then combine those into a single `payload` object. The limitation is something of a tradeoff for not writing the action creators by hand. `redux-starter-kit`'s `createSlice` function was inspired by https://github.com/ericelliott/autodux , which lets you optionally pass in some kind of a "payload creation callback" function. It would be reasonable to do something similar in our `createSlice`, but that's also more code you'd be writing by hand.
> the "function parameter" approach you're describing is just not how Redux works
That's not how redux works internally, and it makes all the sense in the world. My wish is to keep these details buried and not leak into the coding style used by the app. The logic in my function wants two arguments, the fact that those two arguments have been packed into an action (and into a field named 'payload') to work with the redux flow of dispatching & etc is not something that anything in the logic or body of my function needs to know. It is necessary because of how redux works, but everything in the kit is about adding glue between app code and redux, reducing the verbosity and presence of redux internals in app code, so this sounds like a natural way to continue that trend.
If I was working with React these days I'd surely set out some time to try and extend the kit in those directions. A few years ago (shortly after redux was first released) I gave it a shot, but there were too many pieces to build. The kit does a great job lifting a lot of newly developed packages like immer.
You can do what you want just in 17 lines of pure JavaScript. This is an example:
const
create_store = ({state, actions}) => {
const
after_update_do = [],
subscribe = fn => after_update_do.push(fn),
notify = () => after_update_do.forEach(fn => fn(state)),
create_action = action => (...args) => {
state = action(state, ...args);
notify()
};
return Object.entries(actions).reduce((bound_actions, [action_name, action]) =>
Object.assign({}, bound_actions, {[action_name]: create_action(action)}),
{subscribe})
},
counter = create_store({
state: 0,
actions: {
increase: state => state + 1,
decrease: state => state - 1,
multiply_add: (state, a, b) => state * a + b,
},
});
counter.subscribe(state => console.log('First reactive component was updated with: ' + state));
counter.subscribe(state => console.log('Second reactive component was updated with: ' + state));
Now you can call all actions directly from the counter and update all components in reactive manner.
counter.increase();
// First reactive component was updated with: 1
// Second reactive component was updated with: 1
counter.multiply_add(2, 3)
// First reactive component was updated with: 5
// Second reactive component was updated with: 5
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?
Are you only looking for people with prior Django experience? People who know Python and the web can pick it up pretty quickly. And I would have thought that Python knowledge is common now.
Spring Boot is pretty good actually. It doesn’t match some of Django’s features, but if I were to use JVM now, either Spring Boot or a standard Clojure stack with Ring (coupled with Honeywell) would be good enough. (Of course finding Clojure devs is harder, I have spent a lot of time evangelizing it in my country with little success.) I have used both last year in production without issues.
Still, Django and Rails makes many things a breeze.
Flipping your problem around, is it hard to find developers who can be productive in Django/Python?
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?
Play framework (with Slick or Quill for data access) can get you most of the way there, but you won't have Django's out-of-the-box admin interface, have to roll your own.
If you add in Akka or Akka Typed then you can pass state changes for connected websocket clients (i.e. for a SPA/Redux based frontend), which is quite awesome.
Scala and Scala.js are a powerful combination if you want to do everything in the same language. Performance is of course excellent compared to most of the dynamic language backed frameworks, and static typing is a huge win...for some of us at any rate :)
Will have to get your hands dirty to replicate Django, however.
I'm a JVM fan, but I've never been able to find good tutorials on documentation on play. It seems like everytime I find a resource its for some old version that isn't compatible.
Well, start with the play docs [1]; from there, yeah, you have to hunt around. Play's more of a framework for building frameworks than an out-of-the-box batteries included web framework like Rails, Django, etc. It provides the building blocks to create anything, the rest is up to you.
When I was learning Play I found digging through the sources to be immensely useful, not only for learning the framework itself, but for learning Scala as well.
Spring Boot is a good start and easy to evolve into custom assembly of the frameworks and libraries which compose it. Java ecosystem is still more mature and functional than anything else, so I‘m even wondering what’s there in Django, that doesn’t exist on Java platform?
What features from Django are you missing and in which frameworks?
Comparing Django(admittedly, from few years ago when I worked with it) with Spring, I'd say the latter is more feature-rich and way more customizable because of its modular design. Unfortunately, it's also much more complex and setting up a new project properly with all can be overwhelming so if you want to play around with it I'd recommend to start with JHipster template - it generates a React/Angular SPA with backend in Spring.
I found http://www.sparkjava.com to be better than Play framework personally if you want to work with Java. Play seems to be more Scala focussed when I tried it.
It’s rather minimal though, just providing the HTTP stack for you, so you have to do your own DB connections and the like.
Where are you looking for Python engineers? I'm surprised you're having trouble finding them, the language and ecosystem seems like it's thriving and more popular than ever.
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.
This is bad advice. Cookies should almost always be used in browser session management. This is due to the built-in security advantages that browsers give cookies e.g. HTTP Only. Even if your main auth strategy is using tokens, you should support a cookie wrapper for browser based clients. This is one of the main ways to decrease the attack surface area of XSS vulnerabilities.
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.
Rails is hard-core to maintain. Every company I know that used rails for their projects says it was a mistake. It is flaky with breaking changes all over and it is hard to find good developers.
Sane thing to do is to stick with Python. Django is boring but it is rock solid and it pays itself multiple times.
> 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.
Having used both Django and Rails extensively recently, I disagree. Maybe 5 years ago, yes.
which feature Rails Core simply taking a dump on widely requested features that some people need for more modern architectures. And a popular note from the second issue:
> Django has had a mechanism like this for years, and it's a delight to work with — it feels like the right balance of indirection and simplicity.
ActiveStorage is relatively new feature which also isn’t really big of a deal. Most issues mentioned in above links can indeed be solved by using the direct methods without given abstraction.
Using both Rails and Django I much prefer Rails, but I don’t see a point in bashing the other using single picked issues as a general argument for how crappy the framework/community is.
Also (IMO) python is a nice compromise between Ruby and JS and C/Java style. It's dynamically types but has classes out of the box, and it has Ruby "magic" methods but as double unders so you can actually tell that they are magic from the source.
i tried searching for the "Lucy ecosystem" in relation to C# and .Net but was not able to find any references to it. I'm guessing is an acronym for a stack, could you further clarify?
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.
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.
PostgreSQL is a good default choice because it is rigorously engineered and offers a wide variety of production equality extensions that mold it into whatever you need it to be.
If, halfway through your implementation, it turns out that you need to store GIS data or time series or you need a key-value document store, Postgres can easily do all of that, and you can have everything in one DB (unless it turns out that your requirements are truly special).
This article is extremely out-of-date, referring to numerous problems that were solved many years ago. Notice the repeated references to MySQL 5.5, and one reference to how "5.6 is due out soon" -- this indicates the article is 6 years old.
Additionally, a number of things in that article are misleadingly worded, and/or show a blatant disregard for information in MySQL's documentation. And a few things are just completely misstated or outright false. I would not consider it a "good article" on this subject.
What things are misstated? General arguments are worthless. Anyway I do not recall Postgres being broken few years ago. It had less features, was slower, but was working as expected. Whenever someone points out that some severe problems with given software are already fixed its not building a good rep for the product. If something was seriously broken, yet considered production ready its a bad sign for the feature of this product anyway.
MySQL wasn't "broken" 6 years ago either. It just required changing a few settings away from their defaults to avoid some of the behaviors in the article, in the few cases where the article's complaints are even valid.
A majority of the largest internet properties use MySQL as their primary storage, and have been doing so for years. Do you believe they're all "broken" in their ability to store and retrieve primary product data?
As for what's mistated in the article, it would take hours to correct in-depth, but in brief:
* All of the "silent data conversion" complaints -- as well as others -- are fixed by setting a strict sql_mode. This has been the default since MySQL 5.7 (2015), but has been available (and recommended as a best practice) since 2004. Literally, one single setting that has been available for 15 years wipes out a solid chunk of this article's complaints.
* The backup discussion makes no mention of xtrabackup, the most widely-used free-and-open-source InnoDB binary backup tool. This tool was already in common use when the article was written, so the author is conveniently choosing to ignore it.
* MyISAM storage engine is effectively dead, all of the complaints about it in this article are moot. There was no valid reason to use this storage engine when this article was written, let alone today.
* The article's discussion on nondeterministic binary logging is overly broad with no examples. Author is complaining that simple inserts with auto_increment aren't safe for binlog, which is completely ludicrous. And all of the rare legit nondeterministic cases are handled by modifying one setting (changing binlog format to either row or mixed; both available when the article was written, and now default since 5.7 in 2015).
* Character sets: 4-byte utf8 is the default in mysql 8.0. While the complaints about MySQL's old 3-byte utf8 are valid, the reason for it makes historical sense: when MySQL added utf8 support in early 2003, the utf8 standard originally permitted up to 6 bytes per char at that time, which had excessive storage implications. Emoji weren't yet in widespread use and 3 bytes were sufficient to store the majority of chars in use at that time.
I could go on and on. This article is simply not based in reality.
I'd say more than Rails. Rails actually doesn't make too many choices about the application itself. Django does - it kinda expect the application to be CMS-y (which is super useful for a _lot_ of work - but not if you're not doing anything CMSy), has default for authentication which aren't great (usernames that aren't emails, for example) and has a sub-standard (but not terrible) ORM. The admin interface is useful in the beginning, but becomes a drag on development as time goes by.
Django is workable, so I wouldn't say "stay away," but I wish more companies went with something like Flask + SQL Alchemy. My experience is that people who pick Django often leave companies after a year, leaving a mess for others to clean up.
> And why PostgreSQL by default?
PostGIS. I know projects that ended up with two databases, because they picked MySQL early, and later needed GIS features.
I agree. This is spot on. You don't "just use" Rails. I've been trying to learn the Rails conventions ("magic") for weeks now and I feel fucking stupid. It's not the MVC arrangement, it's the inherited behavior from ActiveWhatever that makes it frustrating. The Rails project might be open source but it definitely feels propietary in nature. For reference, I come from using vanilla PHP and Python with Bottle/Flask since ~2010 and I'm confused as hell with it.
Also, OP can leverage full stack modern JS now, so sticking to Node for the server side makes sense.
- 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
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.
whatever is better, it is good that there is strong competition out there. pushing both to their limits. while i like vue and react can be quite challenging for unexperienced devs: at some point you land in js land, so why not using it from day 1? react is super powerful and once it clicks you cam do everything superfast. at the end of the day it is js, not more not less. i have issues with templating languages like vue, they get better and better, can do everything and at some point you have... php.
> relational DBs are great but should never be the default
What??? Relational DBs are the cornerstone of storage for we applications. And with postgres, you can add jsonb columns when you need unstructured. What could possibly be the default that dethrones relational DBs?
bs sorry, only because there are many use cases for sql doesn't mean it should be default. there is great db tech out there which doesn't fit to all requirements but can save you tons of time.
> there are many use cases for sql doesn't mean it should be default
Software that is performant and meets multiple use cases makes for a poor default?
Give me some concrete examples. But keep in mind that this is a discussion of defaults. I'm not saying there aren't use cases you would want something besides something like Postgres, but unless you KNOW you have those requirements, relational DBs are an extremely strong choice.
JWT isn't necessarily a complete solution as it lacks revocation.
That can be handled in other ways, but some people insist on discouraging it rather than telling you how to properly handle them.
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.
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.
I also wouldn’t forget to mention GraphQL. Once you get a hang of it, it’s just beautiful to use. Hard to go back. If you use Sequelize with node you can hook it up in a morning.
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?
React hosted in an S3 bucket, API Gateway with one Lambda function per model, single DynamoDB table with overloaded indexes. This will cost you pennies to spin up and get traction with.
AFAIK most crawlers (including facebook etc) don't load javascript, so I'm always wondering how to allow dynamic pages (say a product's page) to be crawled and have a og meta tags.
If this had a great solution, boy things today would be much easier!
If you are relying on SEO to gain initial traction, your project is going to fail. Start worrying about SEO when you have a core base of users who are actually using your product and by then you'll be more interested in refining features for your userbase that you won't fall into the feng shui trap that is SEO.
edited to add: The reason I discount SEO like this is because SEO is essentially chasing a search result against competitors who likely have more budget, more resources, and more time to play that game. Spend your time on making your product better, aggressively market directly to people instead of relying on the passive results of SEO, and by the time your project takes off, you will hopefully be in a spot where you won't care very much about why using react-helmet doesn't help with Facebook shares.
Nobody mentioned initial traction or if it is too early to worry about SEO.
As I asked in my question, I also mentioned the need for og meta tags for social sharing, which is something that is often important for clients I talk to.
The appeal of a static SPA hosted on s3 is great, but I have trouble getting good responses about such fundamentals from people who advocate this architecture.
Google will load JavaScript but you can also use react-static to do static SSR if you’d like your first render to be fast or you’d like better SEO from crawlers that don’t read JS.
You can do the first render statically into s3 and then attach react. So basically your build does the SSR. It works if you have a smallish number of pages.
Personally I use Groovy & Grails, usually with Postgresql. Recently I've started using Hetzner for hosting since they have better pricing than a lot of the other options.
I did 4 months ago, I loved it at first but when I tried to use it in a more complex use case during hackathon I ended up hitting some weird compile bugs with it and decided to go back to webpack. Maybe ill try it again once it matures a bit more.
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.
Its an interesting stack, for sure. I'm only surprised by the sqlite choice. With such a concurrent and speedy backend, what do you do about concurrent writes and the lack of row/page level locking in sqlite?
Most things I do never get that big / popular so it’s not really an issue (especially for the convenience of SQLite when starting up a new project). The odd time I’ve run into issues I just migrate to postgres.
In the past years Laravel has helped us quickly build prototypes that we could conveniently grow into enterprise-scale apps.
Backend: PHP/Laravel
Frontend: Same, using VueJS as needed/wanted.
Database: Usually starting off with SQLite and switch to a more appropriate choice like Postgres, MariaDB or even MSSQL.
Laravel even more then rails and django comes with pretty much everything you need for modern web dev built in. Full auth system, feature and unit test infrastructure, background jobs, push notifications integrated with a scalable third party websocket service, integrated with vuejs, webpack wrapper and more. It also has a prebuilt development VM that has supporting services such as mysql and redis or you can use various docker solutions for that. There is also excellent laracasts video course platform with free series on getting started with laravel and there is also codecourse video casts that has examples of full blown websites built with laravel
Django for API (business logic, database access and authentication) and backend admin UI. Nodejs or Go for client facing web application. Riotjs and jquery for frontend.
My personal preference:
React on the Front-end,
PHP7+Symfony4 on the Back-end with Postgres, RabbitMQ for messaging and NodeJS for microservices that deal with various real-time tasks based on those messages.
I stopped using Symfony at early version 3, (php 5.3 I think ) started to use nodejs, express, which lead to start using react and code SPAs.
Last year I came back to php stack, and it was refreshing, Symfony 4 is really productive! composer flex system with recipes to finish the bundle configurations, and webpack encore makes really easy to bundle js,etc.
I think Symfony 4 is underrated when you see how popular React SPA are these days.
I find S4 to be really fun to develop with, it's just such a well put-together framework that it's a joy to use, even when you're digging into the more obscure bits. Especially when paired with PHPStorm.
- Python, PHP, GO, depending on what I need to do. No frameworks.
- Vanilla JavaScript and CSS. No frameworks.
- Relational db and Redis
- NGINX and Ubuntu. NGINX for caching.
- AWS or DigitalOcean depending on what I need to do. I strongly prefer working with DO whenever I can now vs eg AWS or Azure. I've had a good experience with Linode and Vultr in the past, however DO's ever-improving offerings keeps putting distance between them.
I've built up my own frameworks for authentication, APIs, etc. over many years that I evolve regularly. Over the last ~15 years I've strictly only been building my own things, so I don't have to consider other organizations or teams and what they want or their pre-existing approaches. My approach only makes sense because of that.
react & redux with typescript, firebase for authentication & hosting, database depends on the application. prettier & eslint. optional: commitizen for git commit standardization
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.
And yes of course, Go. Solid language, good tools, and a much richer set of libraries than Nim. First rate solution, and I have tried. Several times. But for some reason, Go and I always end up in a shouting match, and one of us inevitably slams a door. It's a purely personal thing.
If your experience is mainly in Python ecosystem Django is just hard to beat. If it's Java based then things are more complicated I think - these days I have been avoiding heavyweight back ends and using minimalist stacks of which Micronaut [1] is my favorite. I use it with Groovy (though it supports Java / Kotlin), Postgresql as database and combine it with VueJS on the front end for a very agile but highly performant and robust stack.
As someone coming to modern Java from the Python world, I've been pretty happy with Spark (no, not that Spark - it could really do with a more unique name): http://sparkjava.com . It's very simple, doesn't require any of the Spring madness, and looks a lot like Flask in its minimalistic approach. It has a (pretty rough) Kotlin version.
I've also dabbled with Ninja (http://www.ninjaframework.org) but that was ultimately disappointing. It relies heavily on dependency injection, which is not my cup of tea.
Thanks, Spark looks great! Very much like Micronaut actually. The only thing I see missing that I would want is handling of async ... not sure if I'm just missing it in the docs.
That is true, at least from here. But it sure is a pity, as the technology is fun and technically awesome, and the stack is not so esoteric - it is actually used by a lot of people.
Part of the reason is that libraries can be “finished” (as in, so stable that they don’t need frequent updates), so there is way less busywork and noise in the open.
Another reason is that clojure is open source but not free software, and this has affected the community. There was a big discussion lately about this, where some vocal leaders of the community complained about it: https://news.ycombinator.com/item?id=18538123
Could you elaborate on why or how libraries feel "finished" in Clojure versus in other languages?
Also, curious about the gradual typing bit. How sophisticated is Clojure's type system once applied, compared to one found in (say) Typescript, or as another extreme Scala?
452 comments
[ 2.9 ms ] story [ 329 ms ] threadReact is pretty annoying to set up yourself since it needs to be compiled, so use https://github.com/facebook/create-react-app to spin up quickly or just host vanilla html/css/js and slowly transition to react as you please.
Alternatively, I think the React core code can be downloaded on the client via a cdn.
On the other hand, I just got a vps and am planning on learning Golang ;-)
Frankly, it wouldn't really matter if it is dead as the current version seems to mature enough for my needs in the foreseeable future. But then ... there is kind of on an ego boost that you get while using something trendy!
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.
See: https://www.culttt.com/2016/07/27/understanding-concurrency-...
Of course, true parallelism only comes with multicore CPUs anyways, and this is what the Erlang VM ("BEAM") is geared to. The processes are not threads in the C++ sense and there is no shared memory, but there are separate BEAMs for each CPU core and the processes are scheduled to them. Message passing in the Actor style takes the place of shared memory.
http://jlouisramblings.blogspot.com/2011/07/erlangs-parallel...
Also:
> Erlang achieves concurrency by interleaving the execution of processes on the Erlang virtual machine, the BEAM. On a multi-core processor the BEAM can also achieve parallelism by running one scheduler per core and executing one Erlang process per scheduler. The designer of an Erlang system can achieve further parallelism by distributing the system on several computers. > https://happi.github.io/theBeamBook/
My understanding is that the BEAM will also do "work stealing" among schedulers to take better advantage of the available CPUs.
To run all of it i use docker compose in both prod and dev.
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
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
as a total hobbyist: why?
deploying a django app with zappa is extremely painless... its only issue is that you still need an SQL backend, as DynamoDB isn't really an option unless you want to kiss most of djangos values goodbye.
that would've been my take why you'd want to use flask... because there is very little value in django if you remove models, caching, authentication, permissions and more (that can't be used without external infrastructure) from the equation.
When your app is small and you got almost no users, zappa is great: your lambdas are lighting fast and you're in aws free tier.
When your app grows to like 200k SLOC and 50+ lines in requirements, chances are that it starts quite slow. Do you really want to pay for that?
When your load is high enough, well, aws lambdas become quite expensive even without zappa overhead compared to, say, EC2. https://servers.lol/ should say if serverless makes sense for any defined usecase.
Additionally, lambdas have hard restrictions (like 15 minutes limit) and sometimes it's a dealbreaker for you.
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.
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.
Rails/Django etc will correctly sanitize the rendered data for a HTML context, but they don't know that your client-side framework will execute code inside a {{ }} block, so those aren't removed - so if you render something in rails inside a div which is later on part of a Vue or Angular app, you'll have a problem.
There's a few ways around this, e.g. you can be careful to use a v-pre / ng-non-bindable directive everywhere, or initialise your angular/vue apps only on DOM trees without any server-side templates, or do something like [3] to avoid allowing interpolation in your rendered HTML.
1 - https://github.com/dotboris/vuejs-serverside-template-xss 2 - https://github.com/angular/angular.js/issues/5601 3 - https://github.com/dotboris/vuejs-serverside-template-xss/is...
Isn't that why they added a verbatim tag?
It doesn't just have possibilities for annoyance, because everything inside those curlies is actually _scope-limited Javascript execution_. Consider this in your Django template:
Now, if 'q' in your GET contained variable contained: e.g.: You've just created a nasty XSS.Basically, if you're going to mix server-side and client-side rendering you must either ensure that curlies in user-supplied input are always HTML-escaped on output (DON'T do this, you're guaranteed to miss one), or you ensure that user-supplied input is never output in a Django template within an element on which Vue is mounted. The best way of ensuring the latter is to only mount it selectively where it is required, and where it's easy to validate either by eyeball or machine that no user-supplied input will be present (i.e. a 'js-VueMount' class that must ONLY contain one custom element).
Does that clarify it, or did I misunderstand your point?
(edits: missing curlies, wording clarifications)
you define your template inside {% verbatim %} and if you want to preseed your data, you put that into the new {{ variable|json_script }}...
or do you mean that the developer uses a js framework for the main data and keeps using django templates for other, user generated parts (i.e. comments)? that would be a disaster, i agree
btw, the last letter is an 'i' :)
I should increase my font size on HN, sorry about that. :)
And that means I strip all "{{", "}}", "[[" and "]]" from any user input.
With React (at least the way I use it in those cases) is that my main Rails template only renders an empty div container with props for React to render in it. So my full rendering is handled by React, so there is no mix up between Rails and React with data/rendering.
There's is already a lot third party plugins and resources https://github.com/juliandavidmr/awesome-nestjs
[1] https://github.com/nestjs/nest/graphs/contributors
[2] https://github.com/django/django/graphs/contributors
[3] https://github.com/rails/rails/graphs/contributors
Just talking about node/Typescript though.
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'.
> My point is that this is a pedestrian, every-day problem that doesn't need a complicated solution.
then you should be able to answer the question below, yes?
> How do you think people solved this problem before Redux?
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.
Also
> Do not use jwt
I heavily disagree with this. JWT has its trade offs sure, but if you want to start simple and have the most "cookie like" experience then use cookies and store your JWT inside the cookie.
Edit: To be clear, to get started you should use whatever auth your web framework of choice provides which is usually some "randomly" generated token that gets written to the db and to a cookie which works fine. However, if you need to customize it or if for some reason you're making your own auth system (not advised) you should make the token that goes into your cookie a JWT instead of a random value
JWT is a pain in the ass for a lot of reason people don’t appear to understand until they actually try to use it; and the majority of the proponents for it appear to have never actually used it seriously and had to deal with issues like, oh wow, redis is now the bottleneck for my ‘stateless’ authentication.
Unless you need it and can articulate why, with no magic hand waving... just. use. cookies.
...and ffs, dont just put your jwt in a cookie, thats stupid...and if you don’t understand why, you shouldn’t be using jwt.
No one said anything about stateless authentication. If you're going to use cookies, and I recommend that, you need to put something in the cookie, cookies don't magically implement authentication for you. If for some reason you're not using the framework's way of authenticating with cookies, I'd recommend using JWT. Is there something else you'd recommend? Just use cookies is a hand-waving answer in and of its self.
No one needed to mention anything about stateless authentication because enabling stateless authentication is the purpose of JWTs [1].
Yes, just store a signed cookie with a random token for the session and use stateful authentication. That fits most people's needs better than stateless. (Even signing is more or less optional in many common cases. If the cookie is only a sufficiently long random token for the session key, then I don't really care if a user changes it, they'll only log themselves out.)
[1] - https://jobs.zalando.com/tech/blog/the-purpose-of-jwt-statel...
I replied to your other comment more completely, but thought this part was worth answering as well.
If you are using JWTs for stateless authentication/authorization, you need to include the identity (which doesn't grow) AND the list of authorizations (which might grow).
And, even if it doesn't grow, JWTs are quite large compared to the HMAC of a random token. HMAC size: 64 bytes, JWT size: several hundreds of bytes, easily a few kb, if we put more than the bare minimum.
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.
If you or anybody else is interested, I'd love any feedback! (good or bad :)
[1] https://github.com/briancappello/flask-unchained
That's the amazing thing about Vue: it's utterly void of opinions (apart from components). The ecosystem of stores (there's also the functional one) is testament to Vue achieving elegance through simplicity.
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.
If there’s any meaningful reason use JWT, it would probably be helpful to articulate it for people.
(I would myself, but I consider JWT to be actively harmful to scaling and security in most implementations (specifically global server side refresh token stores which act as a single point of failure), poorly understood and generally speaking inferior to cookies in almost every respect... but necessary, in some, limited circumstances... but if you have any actual, non hand wavey reason why they’re useful for a general, single domain site, I’d be interested to hear why)
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)
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.
But they don't, do they? I've worked on plenty of back-end code that just needed simple routing, rendering, auth, and DB transactions. No need for a big batteries-included framework for that sort of thing. For that matter, I've worked on back-end code that wasn't DB-backed, at least not in the normal sense of talking to something like Postgres or Maria where a standard framework was going to be useful. I've also worked on back-end code that was fundamentally providing an API, with or without some basic routing and server-side rendering instead of just downloading static front-end assets.
In short, there is pretty much no functionality that is completely universal about back-end code for web sites these days, except for the basic server mechanics and underlying protocols. We build all kinds of systems using browser-based technologies, and you just have to look at your requirements and choose a set of tools that will get each job done.
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?
Nginx would serve the index.html with the scripts and the React components would request their data to the API.
This of course doesn't consider SSR'd React as it is just to get started, but the community is working on it (see pipy's projects)
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!
> calling others noobs.
There is definitely some pride in dev's working with redux, once they understand it they feel like they've grown as a developer. Do you really think redux is the holy grail of stores? If you're really smart enough to understand it, think a little deeper about the design, it really sucks.
Try unstated, or is that too simple for you? Do you maybe like a lot of boilerplate and magic that took you a year to grok so you can now show off to others what wizardry you're capable off?
> Redux is not too hard, but it's poor in design.
You have not once yet stated why it is "poor in design".
> Also you will have to give up redux soon, the hype is over and better things are at the horizon.
I do not care for hype. I am embarrassed for you that you use hype as a measure of a technology's quality.
> There is definitely some pride in dev's working with redux, once they understand it they feel like they've grown as a developer.
You are projecting a point of view onto me that I do not hold. Does this argument tactic usually work?
> Do you really think redux is the holy grail of stores?
No. I do not hold it in higher regarded than what I believe is merited.
> If you're really smart enough to understand it, think a little deeper about the design, it really sucks.
Once again, you say that "it sucks" without giving a valid reason. Do better.
> Try unstated, or is that too simple for you?
Unstated? If you mean "stateless", then I'm not sure what there is to try. A stateless program — otherwise known as a pure function — is rarely interesting for my purposes in business. In all cases, my programs required some persistent state to be modelled.
> Do you maybe like a lot of boilerplate and magic that took you a year to grok so you can now show off to others what wizardry you're capable off?
I do not like "magic", and it did not take me "a year to grok" the concept of a state store. Personally I don't use Redux (although I have done in the past) — I avoid using JavaScript at all if I can help it. Where I need complex UIs, I use Elm. Redux is a JavaScript state store heavily inspired by Elm. It's basically the same, minus type safety (so it's worse).
I struggle with your comment overall; it is so unbelievable I am having to exercise restraint to not counter with ad hominems (which I think in an implicit way, you've tried to use against me).
I have to work on a daily base with redux because almost every stupid company is using that nowadays. Some codebases are so horrific that I simply quit the job and find something better.
I actually said why it is poor in design: endless switch statements with reducers, do you think that is great design? Every component that wants to use a store needs to 'connect' to it with a higher order component, ever seen chains of hoc's and still know what's going on? Then you need to write time and time again mapStateToProps and mapDispatchToProps. Do you think that's great design? Even if there would be no other state management system yet, it still sucks. Even Dan Abramov says you probably don't need redux, still everyone is using it for the most simple apps.
You might want to use a router, well you're kinda locked into redux so you need redux-router. Example from the redux-router repo:
This, for just wanting to use a fucking router that works along with my store! You think that is great design? React is great design IMHO, not redux. Dan Abramov is a great guy, highly talented, times more intelligent than I am, but his design principles are really poor. Same counts for hooks, a fun experiment for a counter demo, but poor design for larger apps. I hope it will never become a hype too.Redux is just one of the many flux implementations. Not the best, but a flavour that you may like or dislike. Unstated is a client store that is a wrapper around the new React Context API: unstated: https://github.com/jamiebuilds/unstated
In any action.ts file you can have as many actions as you wish. Every action has type, dispatch and reduce methods:
This is typescript namespace, but compiles to IIFE.This is how actions is combined:
You can call it: And here how to generate reducers from actions: No switch statements and reducers.I know, you can easily improve it, but from the beginning the docs and most popular helper libaries all point you in the wrong direction.
[0] https://github.com/reduxjs/redux/issues/2590
Anything in particular?
I've seen https://github.com/erikras/ducks-modular-redux and it's close to what I do.
Also you can check - https://github.com/reduxjs/redux/issues/1167#issuecomment-38...
First, the docs already have a page called "Reducing Boilerplate", which shows patterns like writing a function that accepts a lookup table of reducers [0].
Second, a while back I wrote a pair of posts called "The Tao of Redux" [1] [2]. Part 1 discusses the implementation and intent behind how Redux is meant to be used, and Part 2 looks at why common usage practices exist. As part of that, I pointed out that you can use whatever logic you want in your reducers, and as much or as little abstraction on top of Redux. Switch statements are simply the most obvious way to handle multiple values for a single field, but you should feel free to use whatever approach you want.
Third, we've recently created a new package called `redux-starter-kit` [3]. It helps simplify several common use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once without writing any action types or action creators by hand. I'd encourage you to try it out and let us know how well it works for you.
Please let me know if you've got any other questions I can help with!
[0] https://redux.js.org/recipes/reducing-boilerplate
[1] https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta...
[2] https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta...
[3] https://redux-starter-kit.js.org/
MobX is a much better fit for most react apps IMHO. Redux could be good, if you have a database [id] driven application, but for most people is way too restrictive.
If you are working in a small team, and are using Redux, you are probably making life harder than it has to be.
Would be funny to say, I've tried 4 times to tie my shoes, but didn't go well, so you shuldn't tie your shoes...
So much hate, whithout any reason is what buffles me.
This is the point of redux. If you don't have these restrictions, then state will be all overt the place, race conditions, side effects will make your life much harder as the app matures especially with multiple developers.
I can see why the Flux concept would seem arbitrary and overengineered if you hadn't been forced to solve that particular problem before. For me, the baffling parts of Redux were the ones that were specific to React, because my understanding of React was very shallow. The amount of React I had to learn to understand React/Redux felt like way more than I would have needed to learn to write an app without Redux. But for me, it was worth the effort to be able to use Redux for state management.
[0] https://blog.isquaredsoftware.com/2018/11/react-redux-histor...
Reducers are one of the main points of Redux, because separating the idea that "something happened" from "here's how the state updates in response" is key to allowing things like the Redux DevTools to work.
The point of `mapStateToProps` is to allow you to specify "here's the data this component needs from the Redux" store, so that `connect` can take care of the work of subscribing to the store and only re-rendering your component when it actually gets new data. See my post "The History and Implementation of React-Redux" [0] for more details.
Finally, please check out our new `redux-starter-kit` package, which helps simplify several common Redux use cases [1].
[0] https://blog.isquaredsoftware.com/2018/11/react-redux-histor...
[1] https://redux-starter-kit.js.org
The idea is great, and has/had already been proven its value many times before. I love it, and I wanted to love redux for providing it to the masses. But every single experience I've had actually using redux (both my projects and other people's) had ended up with verbose, cumbersome and... messy code to read and analyze.
The ideal? I want to define a function with its parameters and that function performs the logic and data massaging it needs to. When I want that behaviour to trigger because something happened, I want to describe a call to that function with the right parameters with minimal scaffolding. Ideally, it would look exactly like I call that function, and the machinery that would turn that into posting an action that eventually reaches a reducer would be hidden from my sight. I do not want that scaffolding polluting my code. Defining string names for my functions? They are functions, they already have a name. Defining action objects to store the parameters? I already have a place for that, it's called "function parameters".
I don't know what sort of magic could provide this seamless integration of the reactive patterns into javascript, sort of some transpilation machinery. But I really, REALLY do not want it visible in my code.
[...edit...] Unfortunately, it looks brilliant with stuff like createSlice(), but it doesn't quite go far enough. If I have to deal with "action" and "payload" stuff then I am already polluting my code too much with stuff that I want to keep hidden in the machinery. My reducer functions should receive their actual parameters, not an "action" that they need to destructure into the actual parameters. And calling the actions in the slices should also wrap the store.dispatch() inside them. Ahhh feels so close to the ideal...
Reducers, by definition, take two parameters: the current state and the action. They should return an updated state based on those two inputs only. The `payload` field is simply a common convention for consistently putting the "arguments" or "data" for that action type at a known key in the action each time.
I'm also not sure what you mean by "calling actions should wrap `dispatch` inside of them".
Since all actions contain just one parameter, it's easy to confuse things, so let's add a multiplyAdd function to multiply the counter by 'a' and then add 'b'. It would look like this:
I want it to look like: or even Because that is exactly the function/logic I want to describe. The 'action' and 'payload' are part of the scaffolding for redux execution flow. 'action' will contain data in it with the actual parameters, when javascript functions already support receiving parameters. I want the benefits of redux without paying for it in code clutter.There may be debate if this clutter is too much to pay or not, and that's fine. Plain redux imposes a lot more clutter and was still worth it for many people. My ideal is to reduce it to nothing.
Now, the second part:
The 'dispatch' part is also clutter, and arguably so is 'store' because most redux apps will only have one store. So, I want that line to look like this: Where, as part of the previous wiring in createSlice+combineReducers+createStore, that function has been bound to do what we are currently doing by surrounding it with store.dispatch().What's more, for our multiplyAdd function with two parameters, I (guess) we would be calling it as:
And I want to call it: For some it may be too much magic, but if you are in react-starter-kit territory I doubt it. For some it may be just me being pedantic and what the kit offers is already plenty, but the kit already moves away from plain redux and I just want to move it a bit further.Oh, and of course I want it all to work with types in Typescript. :)
(I don't currently work with React or redux, so my ntoes are just a brain dump based on my past experience and expectations for future use, and certainly not a request, demand or criticism of redux or the kit).
As for the dispatching approach, most of the time you'll be dispatching these actions from a React component, in which case it's going to look like `this.props.doSomething()`.
I will say that `createSlice` is currently limited in how it generates action creators. They currently only accept a single argument, which it turns into the `payload` field in the actions. If you're writing the action creators by hand, typically you could accept multiple function parameters in the action creator, and then combine those into a single `payload` object. The limitation is something of a tradeoff for not writing the action creators by hand. `redux-starter-kit`'s `createSlice` function was inspired by https://github.com/ericelliott/autodux , which lets you optionally pass in some kind of a "payload creation callback" function. It would be reasonable to do something similar in our `createSlice`, but that's also more code you'd be writing by hand.
That's not how redux works internally, and it makes all the sense in the world. My wish is to keep these details buried and not leak into the coding style used by the app. The logic in my function wants two arguments, the fact that those two arguments have been packed into an action (and into a field named 'payload') to work with the redux flow of dispatching & etc is not something that anything in the logic or body of my function needs to know. It is necessary because of how redux works, but everything in the kit is about adding glue between app code and redux, reducing the verbosity and presence of redux internals in app code, so this sounds like a natural way to continue that trend.
If I was working with React these days I'd surely set out some time to try and extend the kit in those directions. A few years ago (shortly after redux was first released) I gave it a shot, but there were too many pieces to build. The kit does a great job lifting a lot of newly developed packages like immer.
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?
Still, Django and Rails makes many things a breeze.
https://github.com/jkk/honeysql/blob/master/README.md
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?
If you add in Akka or Akka Typed then you can pass state changes for connected websocket clients (i.e. for a SPA/Redux based frontend), which is quite awesome.
Scala and Scala.js are a powerful combination if you want to do everything in the same language. Performance is of course excellent compared to most of the dynamic language backed frameworks, and static typing is a huge win...for some of us at any rate :)
Will have to get your hands dirty to replicate Django, however.
Do you have any recommendations?
When I was learning Play I found digging through the sources to be immensely useful, not only for learning the framework itself, but for learning Scala as well.
[1] https://www.playframework.com/documentation/2.6.x/ScalaHome
It’s rather minimal though, just providing the HTTP stack for you, so you have to do your own DB connections and the like.
It's more of a collection of libraries than a big framework but it's quite ok if you're building microservices.
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.
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.
Having used both Django and Rails extensively recently, I disagree. Maybe 5 years ago, yes.
For two examples I ran into yesterday, check out https://github.com/rails/rails/issues/32790 and https://github.com/rails/rails/issues/31419
which feature Rails Core simply taking a dump on widely requested features that some people need for more modern architectures. And a popular note from the second issue:
> Django has had a mechanism like this for years, and it's a delight to work with — it feels like the right balance of indirection and simplicity.
https://code.djangoproject.com/ticket/15619
ActiveStorage is relatively new feature which also isn’t really big of a deal. Most issues mentioned in above links can indeed be solved by using the direct methods without given abstraction.
Using both Rails and Django I much prefer Rails, but I don’t see a point in bashing the other using single picked issues as a general argument for how crappy the framework/community is.
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.
If, halfway through your implementation, it turns out that you need to store GIS data or time series or you need a key-value document store, Postgres can easily do all of that, and you can have everything in one DB (unless it turns out that your requirements are truly special).
Here's a good article about that: https://grimoire.ca/mysql/choose-something-else
Additionally, a number of things in that article are misleadingly worded, and/or show a blatant disregard for information in MySQL's documentation. And a few things are just completely misstated or outright false. I would not consider it a "good article" on this subject.
A majority of the largest internet properties use MySQL as their primary storage, and have been doing so for years. Do you believe they're all "broken" in their ability to store and retrieve primary product data?
As for what's mistated in the article, it would take hours to correct in-depth, but in brief:
* All of the "silent data conversion" complaints -- as well as others -- are fixed by setting a strict sql_mode. This has been the default since MySQL 5.7 (2015), but has been available (and recommended as a best practice) since 2004. Literally, one single setting that has been available for 15 years wipes out a solid chunk of this article's complaints.
* The backup discussion makes no mention of xtrabackup, the most widely-used free-and-open-source InnoDB binary backup tool. This tool was already in common use when the article was written, so the author is conveniently choosing to ignore it.
* MyISAM storage engine is effectively dead, all of the complaints about it in this article are moot. There was no valid reason to use this storage engine when this article was written, let alone today.
* The article's discussion on nondeterministic binary logging is overly broad with no examples. Author is complaining that simple inserts with auto_increment aren't safe for binlog, which is completely ludicrous. And all of the rare legit nondeterministic cases are handled by modifying one setting (changing binlog format to either row or mixed; both available when the article was written, and now default since 5.7 in 2015).
* Character sets: 4-byte utf8 is the default in mysql 8.0. While the complaints about MySQL's old 3-byte utf8 are valid, the reason for it makes historical sense: when MySQL added utf8 support in early 2003, the utf8 standard originally permitted up to 6 bytes per char at that time, which had excessive storage implications. Emoji weren't yet in widespread use and 3 bytes were sufficient to store the majority of chars in use at that time.
I could go on and on. This article is simply not based in reality.
I'd say more than Rails. Rails actually doesn't make too many choices about the application itself. Django does - it kinda expect the application to be CMS-y (which is super useful for a _lot_ of work - but not if you're not doing anything CMSy), has default for authentication which aren't great (usernames that aren't emails, for example) and has a sub-standard (but not terrible) ORM. The admin interface is useful in the beginning, but becomes a drag on development as time goes by.
Django is workable, so I wouldn't say "stay away," but I wish more companies went with something like Flask + SQL Alchemy. My experience is that people who pick Django often leave companies after a year, leaving a mess for others to clean up.
> And why PostgreSQL by default?
PostGIS. I know projects that ended up with two databases, because they picked MySQL early, and later needed GIS features.
Also, OP can leverage full stack modern JS now, so sticking to Node for the server side makes sense.
- 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?
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.
JSX is the worst invention of the decade. It's ugly, useless and solves a non-issue. I don't recommend it at all.
What??? Relational DBs are the cornerstone of storage for we applications. And with postgres, you can add jsonb columns when you need unstructured. What could possibly be the default that dethrones relational DBs?
Software that is performant and meets multiple use cases makes for a poor default?
Give me some concrete examples. But keep in mind that this is a discussion of defaults. I'm not saying there aren't use cases you would want something besides something like Postgres, but unless you KNOW you have those requirements, relational DBs are an extremely strong choice.
https://news.ycombinator.com/item?id=18767767
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.
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.
Here's a tutorial: https://blog.dmatoso.com/build-static-site-generator-nodejs-...
AFAIK most crawlers (including facebook etc) don't load javascript, so I'm always wondering how to allow dynamic pages (say a product's page) to be crawled and have a og meta tags.
If this had a great solution, boy things today would be much easier!
edited to add: The reason I discount SEO like this is because SEO is essentially chasing a search result against competitors who likely have more budget, more resources, and more time to play that game. Spend your time on making your product better, aggressively market directly to people instead of relying on the passive results of SEO, and by the time your project takes off, you will hopefully be in a spot where you won't care very much about why using react-helmet doesn't help with Facebook shares.
As I asked in my question, I also mentioned the need for og meta tags for social sharing, which is something that is often important for clients I talk to.
The appeal of a static SPA hosted on s3 is great, but I have trouble getting good responses about such fundamentals from people who advocate this architecture.
Ping me if you’d like to know more.
Backend: Node, Typescript, Express, TypeORM, Postgres, SocketIO, PugJS, BabylonJS
Webpack for bundling
Digital Ocean or Azure for Ubuntu vm hosting
I feel having the same language for front/back end really reduces mental overhead.
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.
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...
In the past years Laravel has helped us quickly build prototypes that we could conveniently grow into enterprise-scale apps.
Backend: PHP/Laravel Frontend: Same, using VueJS as needed/wanted. Database: Usually starting off with SQLite and switch to a more appropriate choice like Postgres, MariaDB or even MSSQL.
If it wasn't for PHP I think Laravel would have overtook Rails as the tools to build prototypes.
Python/Sanic for the API.
PostgreSQL for the database.
Kubernestes on DigitalOcean (or similar kaas provider) for hosting.
Last year I came back to php stack, and it was refreshing, Symfony 4 is really productive! composer flex system with recipes to finish the bundle configurations, and webpack encore makes really easy to bundle js,etc.
I think Symfony 4 is underrated when you see how popular React SPA are these days.
- Vanilla JavaScript and CSS. No frameworks.
- Relational db and Redis
- NGINX and Ubuntu. NGINX for caching.
- AWS or DigitalOcean depending on what I need to do. I strongly prefer working with DO whenever I can now vs eg AWS or Azure. I've had a good experience with Linode and Vultr in the past, however DO's ever-improving offerings keeps putting distance between them.
I've built up my own frameworks for authentication, APIs, etc. over many years that I evolve regularly. Over the last ~15 years I've strictly only been building my own things, so I don't have to consider other organizations or teams and what they want or their pre-existing approaches. My approach only makes sense because of that.
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.
It works marvellously well. I use VueJS when I have a page which requires more intensive JS.
For dead simple use case (no subdomains), I was even able to embed caddy within my static binary file.
Serving hundreds of users on a $5 VPS.
And yes of course, Go. Solid language, good tools, and a much richer set of libraries than Nim. First rate solution, and I have tried. Several times. But for some reason, Go and I always end up in a shouting match, and one of us inevitably slams a door. It's a purely personal thing.
https://crawshaw.io/blog/one-process-programming-notes
I've also dabbled with Ninja (http://www.ninjaframework.org) but that was ultimately disappointing. It relies heavily on dependency injection, which is not my cup of tea.
* 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.
Part of the reason is that libraries can be “finished” (as in, so stable that they don’t need frequent updates), so there is way less busywork and noise in the open.
Another reason is that clojure is open source but not free software, and this has affected the community. There was a big discussion lately about this, where some vocal leaders of the community complained about it: https://news.ycombinator.com/item?id=18538123
Could you elaborate on why or how libraries feel "finished" in Clojure versus in other languages?
Also, curious about the gradual typing bit. How sophisticated is Clojure's type system once applied, compared to one found in (say) Typescript, or as another extreme Scala?