Ask HN: Go-to web stack today?
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.
Create React App now makes it dead easy. Just do:
npx create-react-app myapp --typescript
- 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?
new Vue(...config...).mount('#app')
y4ml says: {{ comment }}
Hi guys, I just wanted to say {{ $&^%£&£%^% }}
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 }}"
{{ constructor.constructor(alert('hello y4ml')) }}
/search/?q=%7B%7B%20constructor.constructor%28alert%28%27hello%20y4ml%27%29%29%20%7D%7D
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.
var app = new Vue({ delimiters: ['${', '}'], ... });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
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 :)
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!
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:
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';
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:
export namespace indexSaveSsl {
export const type = 'INDEX_SAVE_SSL';
export const dispatch = (store, response) => {
store.dispatch({
type,
data: response.data
});
};
export const reduce = (state, action) => immutable(state)
.set('Reports.data.ssl', {})
.set('Reports.data.ssl.result', action.data)
.set('Tools.options.ssl.test_running', false)
.value();
}
This is how actions is combined:
export const actions = (() => {
// import main actions via webpack
const actionsMain = require.context('app/', true, /actions\.ts$/);
const mainFinal = actionsMain.keys().reduce((prev, key) => Object.assign(prev, actionsMain(key)), {});
return mainFinal;
})();
actions.indexSaveSsl.dispatch(store, resultSsl);
const reducer = (state = {}, action) => {
// main reducer
const result = Object.keys(actions)
.filter((item) => actions[item].type === action.type)
.map((item) => actions[item].reduce(state, action));
return result[0] || state;
};
createStore(reducer, hydrate, extension);
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.
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...
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...
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:
multiplyAdd: (state, action) => state * action.payload.a + action.payload.b
multiplyAdd: (state, a, b) => state * a + b
multiplyAdd: (a, b) => this.state * a + b
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())
counter.actions.increment();
What's more, for our multiplyAdd function with two parameters, I (guess) we would be calling it as:
store.dispatch(counter.actions.multiplyAdd({a:3,b:5}))
counter.actions.multiplyAdd(3, 5);
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.
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));
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: 5It'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.
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.
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.
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.
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.
When I need a more dynamic page, I create a react app specifically for this one page.
Whenever I need to write JS these days, I go for either TypeScript or F# using Fable (an F# to javascript compiler).
There certainly is nothing wrong with going with simplicity over a solution that's overengineered for one's case, tiger.
It's good to hear that maybe when the time comes, I can dip into React by using it as the sprinkle of JS that jQuery / jqxWidgets and such were for me the last time I did any of this.
What happens if you go the I'll-do-it-myself is that you still get a significant amount of code, and lots more bugs since you'll have to redevelop significant pieces of what the libraries and frameworks already have done (and tested) - and you'll ever be better than them.
Of course, you don't need to use Javascript to render your whole page. You can still use React or Vue to add these dynamic parts, and render the rest at the backend.
Imo this might be one of the most underrated ways of doing things. I guess human tend to go to the extremes without being rational about it necessarily (or thinking for themselves and just buying into the hype).
A dynamic client side UI is more expensive to build compared to static html rendered on the server. Our software usually aims to solve a business problem for as little money as possible so we only build these dynamic ui's when they're absolutely required.
I visit a major credit card company's account page and it shows the last time I visited as 'undefined' for a second until it grabs the data to render and it just looks shit.
And I also don't like seeing the page loaded with minimal placeholder, only having have to wait a few seconds for the page to finally render, which is more annoying than even waiting on a blank page because you can't easily tell if things are all loaded or not with placeholders all over.
A pure bad example of over engineering.
You need to make sure things don't look shit using client side framework.
Why? While server-side based web sites can load quickly, there's something dissatisfying (to me) about clicking around a site, waiting for server responses, when nothing has changed.
Sure, js, css, img, etc. assets are likely cached in the browser, and you're just downloading a blob of gzip'd html, but wouldn't it be better to flip the script and notify the client, rather than the client clicking around, uselessly consuming resources?
A SPA combined with websocket connections allows you to implement the, "don't call us, we'll call you pattern". Granted, for mostly static sites this isn't particularly useful, but still, in principle, only consuming server-side resources when state has changed is a "natural" goal I'd argue.
There are tradeoffs with both approaches, but I'm leaning toward SPAs more and more.
https://www.youtube.com/watch?v=SWEts0rlezA&t=3m22s
https://github.com/turbolinks/turbolinks
You can get all of the benefits of server-generated pages with the speed of an SPA. 90%+ of the sites built using SPAs would be better served by Turbolinks and Stimulus.
Really should add a gif or something.
Stimulus and Turbolinks 5 don't have to be used together, but when they are it's a beautiful thing. That's because Stimulus uses the MutationObserver API to observe for DOM changes (eg. loading a new view in response to a click). It is the nicest event handling concept I've ever worked with.
For what it's worth, if you are impressed by the reasoning and design-thinking that created these libraries, I encourage you to try Rails sometime as well. I still consider it the best way to build a web application for 90% of use cases. I'm happy to answer any questions you might have.
https://www.quora.com/Why-do-so-many-startups-use-Ruby-on-Ra...
Turbolinks will work great with Django, but I recommend configuring your stack to automate the inclusion of the Turbolinks-Location header in your responses.
I just did a quick Google and this came up: https://stackoverflow.com/questions/47240766/to-use-turbolin...
Let us know how you make out!
Also - using WebSockets for a one-way communication channel is ridiculous. I know it's the cool kid way to do things, but that invariably means it's over hyped and has a more appropriate alternative. In this case, it's EventSource/Server Sent Events.
I have some sympathy for your view here, but there are some other practical concerns as well in this case. For example, EventSource/SSE are not natively supported on IE/Edge but WebSockets are, so how well whatever you need to do works with your chosen polyfill is a factor.
Websockets requires explicit support on the backend, in every layer of your http stack that it’ll traverse.
If the goal is to simplify your stack, websockets is not the solution.
> flip the script and notify the client, rather than the client clicking around, uselessly consuming resources?
What are they clicking on that is being useless? Are you putting buttons on your page making requests for no reason?
When its server side you send them a mostly-static page with a bunch of links or submits to make more requests with. All those requests are for either sending data back or getting something new off the server. If your use case would involve a lot of user generated input in a streaming fashion then yes, SPA client side programs are th way to go, but if all you are doing is throwing mostly-static CRUD applications you aren't getting an efficiency advantage dumping all the data on the user at first request and then hoping to only get one response of everything they want changed later. You're burning a ton of client memory and CPU cycles to do work you could have done more efficiently with page caching on your end anyway.
Plain old Java and .NET frameworks or CMS, with server side rendering, with dynamic behaviour on as needed basis.
"Waiter, what can you suggest for me, I want to eat a fillet mignon?".
As for your view - I agree mostly. I'm definitely in favour of making things entirely in the 'classic' web model, adding javascript to enhance things where it makes sense (some of this now is just polyfilling html5 form controls where they're not native).
I just wanted to voice this and say if you live in a world where people do not need to integrate with your API then a regular MVC style app and little to no JS is fine. Also, JS helps when you need to do things like CRUD many-to-many relationships on your UI without a bunch of postbacks.
Frontend: Vue.js on top of Nuxt.js (reactive web programming cannot be easier than this and you get SSR or SPA or PWA or static page generation out of the box easily, you can decide later on that). There is not only React out there (which is like a jungle and more complicated in comparison to vue)...
Frontend styling and components: Vuetify or Bulma (you can also go with some vue bootstrap) + Stylus or SASS
Database: PostgreSQL (it's so stable, flexible e.g. with JSON, extendable and scalable in so many ways).
Backend: Whatever suits you to build a RESTful or GraphQL web API. Python+Flask, Go, Django, Ruby on Rails, Java Play Framework, PHP (e.g. Laravel) etc. etc.. Whatever you are most productive in. It does not matter really.
CI/CD and source control: Gitlab.com and the CI you get for free there is unbelievable good.
So, in stages:
- Database: Postgres (you could start with any relational DB, Postgres is just one of the best). It's very, very likely that your model is gonna be relational so better pay that debt upfront. Don't even consider NoSQL this early; we're paying a heavy price on my current job because the initial developers bought that non-relational databases were better at prototyping. Worry about NoSQL and consider switching to any of those if you see, once you release, that the type of data you're handling is more of a stream of mostly independent records than an actual model.
- Like I said, make sure that you actually need an SPA. It's likely that you don't and in that case you can get away with using Django; it gives you pretty much everything you could possibly need.
- If you're dead set on a SPA, go for a more lightweight framework geared towards creating REST APIs. The usual recommendation is flask with any of the rest extensions, but there are other options such as falcon or molten (which is recent, but really well designed).
- Since this is a SPA, use Vue. I find it to be leagues ahead of the js frameworks when it comes to striking a balance between power, expressiveness and ease of use. Much like Flask in the backend, for that matter.
- Dockerize. I don't like promoting a specific tool in this area but docker will make it very easy to develop and deploy your application (also makes it easier to implement the usual suspects like a reverse proxy, a queue, a cache, etc) without having to rely --and thus essentially marry-- any specific tool provided by a given cloud platform.
- Use gitlab for version control. They give continuous integration and private repos for free out of the box.
We don't even use relations, so this essentially means that we are paying a hefty price for something that we don't actually need. A much simpler solution would be to have used MongoDB together with Spring Data, where we can still have caching and object mapping.
We can also easily leverage reactive streams with reactive Spring Data. Technically you could also use JDBC in a reactive manner, but it looks unlikely to work with the frameworks we use with Postgres.
Schemata are good things. Migrations are the database insisting on tedious bureaucratic nonsense like "don't blow your foot off" and "don't regret this later".
> Technically you could also use JDBC in a reactive manner, but it looks unlikely to work with the frameworks we use with Postgres.
The Spring team are pretty keen on removing that gap: http://r2dbc.io/
JIC, this is exactly what I meant with "paying that debt upfront". If your model does turn out to be relational and you don't have this, you are going to get burnt, badly.
- TypeScript is more important than React, static typing is such a productivity boost, even for projects of all sizes.
- Start with vanilla React and create-react-app, monitor for painpoints and look for solutions for these pain points in the community, don't look at the whole ecosystem before you start building stuff.
Backend: Kotlin on the JVM.
Kotlin is a really nice language for either functional or object oriented programming. Static typing with strict null checks are again a huge productivity boost. Standard library is very complete
Beeing on the JVM without beeing stuck with Java is a big win:
- unlocks a huge ecosystem and Java interoperability of Kotlin is superb.There are a lot of lightweight frameworks for stuff around here, enterprise Java is a myth if you are free to choose what to use.
- special shoutout to the JOOQ library, the golden middleground between an ORM and raw SQL Strings.
- JVM is fast
- fat jars are somewhat like containers, can be run everywhere with minimal setup (yeah I'm looking at you python-uwsgi black magic)
Database: Postgresql. Everything you need (relational, JSON), fast, rocksolid
From React/TS, to Kotlin, to PG, to the JOOQ shout out.
I hoped a strongly(ish) language that spans from BE to FE, like ReasonML, would be ready by now, but it isn't.
Kotlin to JS is not there I'm afraid:
https://kotlinlang.org/docs/tutorials/javascript/kotlin-to-j...
I am not sure I find Spring an attractive proposition and Ktor seems rather young, slow and not that well documented.
What do you think is the best option?
We have a very small Ktor service in Production, and it works nice, for legacy reasons, we're using http://sparkjava.com/ for the heavy lifting. An alternative would be https://javalin.io/
I would not start with Sparkjava anymore. The way you write handlers is quite okey (compared to other frameworks), but there are issues with how it's connected to Jetty and relies on singletons that will be painful if you would like to do advanced stuff. It's on our todolist to swap Sparkjava with Ktor somewhere down the road.
To be honest, Ktor seems to have come a long way, the docs improved a lot last year and it seems well thought out. I would give it a try. It's quite easy do decouple your application Handlers from the underlying framework via functional composition, so there is no big lock-in Risk.
In my experience, all three Frameworks are way better than the regular Java-like approach with annotating classes. Request-Context specific information ("The user making the request") is very hard to get to this way and it's usually untyped. On top of it, you are locked in HARD to the Framework. Swapping out a Framework that just mounts Functional Handlers is way easier...
EDIT: Ktor does look a lot better today and now that Kotlin coroutines are actually stable, I'd definitely check it out.
Vert.x already did the Kotlin plumbing on their own so you can use coroutines and similar goodies out of the box, Spring Boot supports Kotlin natively AFAIK, and something like Dropwizard should be easy to use as well..
Seriously, don't limit yourself, part of Kotlin's beauty is how easy it is to use it with Java products and reap immediate gains!
Going back to old projects using various ORM products makes me cringe nowadays, JOOQ + Postgres are such a powerful combo!
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.
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.
Clojure
Datomic
Luminus
ClojureScript
Regent
Datascript
Datsync
Immutability down to the database
Database reads scale horizontally
Impossible SQL injection from reading API
Cache TTLs can be set to infinity
Can ask for data at any point in time or do speculative writes
Same programming language front and back
Running queries within loops are performant due to data locality
Query results can be returned with nested results
The database can be queried with Clojure functions
Data shape is defined at query time, not at schema time
Specs can enforce stronger safety than types
Specs can help generatively test your application
Prolog -> Datalog many things from SQL can be expressed easier in datalog i.e. recursion, nesting, joins etc
The equivalent would be a site were you could write SQL client side, to define your data for your application then add react code to complete your app
Backend: Go (no framework, just the standard library)
Frontend: Vue
Working great so far. A little longer to get things up than using Rails/Django, but the extra speed and control is really nice.
Using Go's templating engine to assemble Vue components into HTML <script> tags works well.
I haven't yet seen any concrete tutorials for getting this up and running with Vue and Go. All I've been able to google is augustoroman/V8 and dop251/jago and other derivatives.
My only dependency is Vue (and vuex), and I only send the components that the current page needs (packed into a single <script> by the template engine). I also send the initial data inlined in that script as js objects. So there's 1 fetch to get the the HTML (usually around 200-300Kb), then 4 fetches (vuejs, vuex, css, logo file) totalling around 500Kb (and all cached, so that only happens on the first load).
So far, no speed problem and no rendering lag worth worrying about. If that changes I'll look at methods of fixing it, but I'm learning to not solve problems that I don't have yet.
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.
If it's a web app, my weapon of choice is Haskell/Yesod because I have opinions about how complexity grows over time and how that should be managed. Dynamic languages fall short of my needs.
If I need a complex UI (lots of state and interactivity), I use Elm. It works, and in my experience it works better than dynamic alternatives (JavaScript, ClojureScript, etc). TypeScript and Flow are not alternatives to Elm.
For storage I just use Postgres, and sometimes Redis if I need it.
For infrastructure, I do just about everything with Nix/NixOS/NixOps (although I develop on an Apple Macintosh Book Air).
* 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?
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...
* Single-page application, which means complete separation between frontend and backend. When developing locally, you have to run two servers. I prefer the traditional way but it's hard to make JS build tools (e.g. webpack) to work well.
My choice is Playframework (because I know Scala well). The frontend is Vue in Typescripts.
I am not using the single-page application and have developed a Playframework plugin to make it work seamlessly (e.g. hot reloading) with Vue/webpack (https://github.com/GIVESocialMovement/sbt-vuefy). It wasn't easy to do.
I imagine other web frameworks would encounter the same issue, so I can't recommend the not-single-page-application way.
Using it for many years already, that's probably why I am most productive in it. However I try to look at other frameworks every now and then (Spring, Django) but I always come back to Play, because it just feels more "right" to me.
BTW: You can use Play without Scala, but Java only. No problem. There seems to be this wrong assumption that Play is a Scala only framework - which is wrong. Yes, Play is written mainly is Scala (69% according to GitHub stats) however as a framework user you can choose between Java or Scala. Or even mix both languages. Back in the early Play 2.x days some features/components of the framework where usable only via Scala, meaning you had to write Scala code to make use of them, however these days are long gone. We run major projects in production written entirely in Play Java.
Play 2.7 will be released soon, containing many nice enhancements and fixing many hickups (for Java users at least). It will be a really great release!
I am looking at React on the front-end instead of vue, due to how much easier it is to hire for react.
The isomorphic/universal rendering is really awesome for node on the server, one set of templates vs two, plus it seems like the GraphQL stuff is way more mature on node. We're not currently using GraphQL, but having that option open to us is nice.
Combined with all the success stories from Linkedin, Paypal and even Walmart around moving stuff to node, it's also an easy decision to defend.
I'm not a huge fan of debugging node, that could be a bit improved, but overall I am happy with the choice to try to build everything in node unless there's a compelling reason not to.
Eventually coupled with full stack CMS like Liferay or Sitecore.
For frontend either tiny pieces of vanilajs when dynamic code is really required, or something that is WebComponents friendly like Angular, if the backend is mostly composed of Web APIs.
Might not be fashionable, performance is quite good, and we get to focus on delivering instead of playing JS framework of the month.
The technology fashion show continues on at full tilt.
PHP, asp.net, node, go, etc.
Angular, react, Vue, etc
MySQL, sqlserver, postgres, nosql, etc.
I've used all of these and more to build systems.
I'd stick with what you know and look at what your requirements are, SEO, massive scaling, needs to be cheap, needs to run on multiple platforms, et.
You could write a rails monolithic app on postgres if you're building an internal application 100 people will use. Or you could use Akka and Scala with all state in memory backed by an event journal stored in cassandra.
IMO Ruby, Python and Elixir are perfectly suitable but the last languages I would choose. I've been working with elixir for the last 1.5 years and have decided I don't really like it. I'm happiest writing scala - I get more done faster and less bugs make it into production. Event sourcing and Akka cluster allow some really interesting patters that move state into application memory. But those technologies require a much different, more involved skill and experience set to lead.
I'd probably be using Go or Scala if I had to start a tech company in a small city. Scala if I were in a large city with talent 100%. There is evidence that Static typic improves speed of delivery and it's easier to refactor/maintain. And it's faster (generally). Both languages are much more widely used than elixir.
Meanwhile distillery has been broken on FreeBSD for months with no fix in sight and no actual community understanding of how things fit together. Dockyard also has a good blog post explaining how complex Elixir deployments get:
https://dockyard.com/blog/2018/02/28/elixir-deployment-tools...
No bueno. Generating a WAR or JAR to deploy is typically trivial in comparison. Capistrano? Easy peasy AND reliable. Distillery? I'm just glad I don't have any production Elixir apps.
- BEAM is slow for computation. - Static typing
Http4s is a great functional http service.
Guardrail generates stub services from an openapi spec and is well thought out enough that it doesn't get in the way.
Put React with Typescript on top of it.
check out: http://www.luminusweb.net/
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.
- Backend: Go (no framework) with monolith first approach with well defined internal logical interfaces that can be easily implemented as external services when they need to scale (session service, user service, notification service, slack integration service...)
- Storage: embedded BBoltDB or Badger, separate db for every logical service and PostgreSQL data structure is very very complex
- Services communication: Protobuf with GRPC
- Monitoring and alerting: Prometheus with Grafana
- Log aggregation: simple central rsyslog, indexing when really needed
- Editor/IDE: VS Code
As less operational maintenance is needed, the easier is to live with your creations.
Example: https://newreleases.io
No Javascript to learn and no worrying about ECMA versions or whatever today's new build tool is. Shared code between client and server. Type safe so you can get a proper IDE, refactoring and a lot less bugs. Full reuse of React + Javascript libraries as well as the incomparable JVM ecosystem on the backend.
Also probably the fastest and most scalable language you can use and is used at Twitter, Netflix, Linkedin, Spotify, Tumblr.
Backend: Django
Realtime/DB: Realm + Postgres
Frontend: Angular
Surprised few have mentioned Angular yet. It is highly opinionated unlike React, and backed by a giant unlike Vue. Seems like a safer enterprise choice.
I’d go further and say this is a good combination for any team who want sound frameworks with out-of-the-box functionality, without having to research the ecosystem and discriminate between lots of third party modules.
Agree on that point , I like Angular because it's opinionated compared to React.
> and backed by a giant unlike Vue
Strongly disagree , Vue is backed by many large corporations and unlike AngularJS was designed to guarantee backward compatibility.
AngularJS not being compatible with Angular is what has killed for good the frameworks and left thousands of entreprises in dust when they believed angular would become a standard because "it's backed by a giant".
Workings for banking sector , I've many customers build CRM or KYC applications on top of Nuxt. Developers love the Vue ecosystem.
> Seems like a safer enterprise choice.
Strongly disagree here as well.
Angular is a great framework but it has absolutely unacceptable build size,
A "Hello World" using Angular 7 with Ivy Rendering is 500KB+ ( tested this morning ). This is not acceptable for modern frameworks to be that big.
Vue and React stay largely under 100KB in terms of build size.
They are lots of scenarios where picking Angular over Vue & React would made things more complex for a project.
The best parts about Angular are; the dependency injection system and the opinionated component templates.
Worst case, if it's popular enough, the nature of open source will handle itself and finds a new maintainer.
Also Pyramid's traversal routing is awesome to build REST-applications and ACL authorization.
What ever stack you decide on, I recommend to stay away from too much magic as it complicates debugging and understanding the framework completely (Hibernate, Laravel). If a framework needs to dynamically generate proxy classes, either the framework has a bad approach or the language is not the right choice for the approach.
Regarding the joins:
j=t_user.join(t_address, t_user.c.id==t_address.c.user_id)
select([...], from_obj=j)
It builds on years of prior experiences and it shows in how mature and pleasant it is, they didn't have great marketing but the project deserves more recognition from community.
Pros:
- Setup is pretty quick, you can move quickly from scratch.
- Deployment is painless.
Cons:
- Firestore is NoSQL which is a huge caveat.
I had to scale the project and add some features later on. Faced some bumps here and there but nothing major (since firebase is still under development). AWS also has similar offerings (lambda, hosted DB etc.) in the same space. I haven't tried them out but look forward to doing so.
For frontend use Vue 10/10 especially if you're looking to put together something quickly. I felt Vue provides a lot more room for "hacking" quick solutions(and improving on top of it later) compared to Angular or even React.
I only prefer this stack for "reactive" web apps though that have a lot of dynamic components. For a traditional website I'd still go with jQuery/Django/SQL.
BUT...
When the client is 100% JavaScript on a browser (which nobody is avoiding) and you're marshalling JSON around and JS Objects, any other stack outside of Node is going to have to do the "JSON object" dance, which we all take for granted as "no biggie", but matters when your code base is spending 20% of the time doing that dance.
Node's also super fast and the community is massive. Not to say Python isn't another good choice but you give up performance in that choice.
Again, this is a "Web stack", so I'm assuming web client talking to the server. Right now, for me, it's Node / React.
My backend is Angel, a Dart framework which I wrote, and for the frontend, I just go with server-side templates. I go with vanilla JS or jQuery when needed.
The only reason I’ll make an SPA these days is if I’m also making a mobile app, and then I write everything in Dart and share common code.
But time is really a luxury for me as-is, so I try not to deviate from the server-side path.
Although modern frameworks & SPA are really fancy and feel great, there mostly comes a point in a project where " client needs X" and i feel that keeping tech oldschool and using a very widely used ecosystem as a CMS base earns me the most flexibility over the sites lifetime.
It's bloat and overkill for small sites, but it gets the job done just as quickly as other systems. And on larger or more complex sites it provides all I'll need without the need to "custom build it" everytime.
(Disclaimer: I'm talking "websites" here, not specific-purpose web applications where this workflow would be a horrendous workaround)
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.
FastAPI as the Python backend. Couchbase as the database. Vue.js with TypeScript, Vuex, etc. as the frontend. Celery for asynchronous jobs. All managed with Docker (including frontend compilation from source). All integrated with Traefik, so, automatic HTTPS.
Up to a month ago, I used my previous project generators based on Flask and several plugins, but now I'm doing all the backends with FastAPI as it's about 3 times faster to develop, and about 5 times or so faster (better performance).
- 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.
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: NodeJS with Hapi and Mongoose / Mongodb
- Auth module in Hapi (JWT)
- All in Typescript and VSCode
These libraries have been stable for a while now. Tried GraphQL / Apollo for a while but the amount of breaking updates made me go back to the stack mentioned above. Currently i'm exploring dotnet core (in C#) and blazor.
Backend: Django or Rails.
Database: PostgreSQL.
Deployment: Heroku
Code Sharing: GitHub or Gitlab.
CI: GitLab CI if you're on Gitlab or CircleCI if on GitHub.
CodeCov.io for code coverage
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.
Mobx is a bit more difficult to grok and debug for newcomers than Redux, but it's really really fast, easy to test and requires little boilerplate.
On the other hand you get reactive state management by default in Vue.
If you use Node for the backend I can recommend using Knex for database queries and migrations while using Postgres.
But if your app will be write heavy, you should consider NoSQL. Neo4j looks very promising in this area and Mongodb also works well.
You will have an easier time migrating data and keeping the data in a known, consistent state with an SQL database. So use that unless your app is write heavy.
I also like using Sqlite for smaller apps. Your database is a single file, you can use knex and switch to Postgres if needed.
As for the backend, I recommend using dependency injection and decouple the http layer from the APIs in all cases where it's possible. It makes things easier to test. Personally I rolled my own library (@adrianhelvik/container) for DI in Node.
I've been pioneering an AVA stack, Airtable, Vue.js, and AWS to create pluggable blogging components. I think you could mix-in GraphQL and end up with just about anything you'd need in an app for pennies a day, including switching out back-ends.
It's the server/client for https://lichess.org/ which is a powerful online chess server. Scalla with Akka actors is used to provide realtime multiplayer chess (bullet chess games, where each player only has a minute or two to play an entire game, are very popular there). The client-side is written in TypeScript, and rather than use React for the vdom, they're using a vdom called snabbdom. https://github.com/snabbdom/snabbdom
This is probably not the go-to stack but not for the reasons you've stated.
However, I don't think the technologies he/she mentioned are little known. Scala, Akka and TypeScript are certainly well known. The last I heard, Vue was based on a fork of Snabbdom.
BTW, it may be worth notice that the code base of Lichess.org also uses Mithril. I used Vue in the past but converted my choice to Mithril afterwards. To me, Mithril is simpler to learn or use. My code using it is cleaner and easier to maintain. But this is certainly anecdotal and YMMV.
Scala, Akka, TypeScript, React...uh, where have you been?
Lichess is an impressive project, their chess app is not only excellent compared to everything else out there, it's incredibly efficient, and handles a ton of traffic with ease. I don't think the creators chose the stack without reason.
For web applications
React with optional state management (Redux Saga / Mobx) for the front, hosted on Netlify.
Ruby on Rails in API mode, with Postgres running on Heroku if the API is non real-time or high traffic / spiky. Go with DynamoDB if it is.
For fun, any Rust Lang based web frameworks with PG and Angular
- React + Redux on AWS S3
- Redux: You know you will eventually need to add it, so just do it to avoid needless workarounds before you give up
- Admin interface to inspect your data + neat REST API with one line
- Plays very well with Django, new features are implemented in Django as soon as possible
Frontend : React for dynamic page only if i really need it. The rest would simply use any jinja provided by the backend framework.
Database : small project sqlite ( personal blog, MVP ), postgresql for production level.
For extremely fast and simple RESTful setup I would go for loopbackwhich has nice cli with lot's of middleware layer for data manipulation.
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.
To run all of it i use docker compose in both prod and dev.
On the other hand, I just got a vps and am planning on learning Golang ;-)
the nice thing about golang is that i don't need containers because my runtime package is basically a binary, golang is great about cross compiling for various platforms, too. when i used ruby or python, i'd have to package up all the dependencies and even get the runtime interpreter installed while using some tools like rbenv, etc. really, really annoying.
Back-end:
- backendless if possible (e.g. use GraphQL, Firebase, etc)
- minimal (1:1 with document store):
PostgreSQL/JSONB, FoundationDB, MongoDB, RethinkDB, CouchDB(mobile-sync)
- relational: PostgreSQL(master/replica), MySQL(multi-master), CockroachDB/TiDB (sharded)
languages: Elixir(Phoenix), Kotlin/Java(Javalin), Clojure(Liberator), Go, Kemal(Crystal)
- HTML+JS using Phoenix/LiveView (or Vaadin?)
- Vue.js (possibly Elm) for SPA
Spring - slow startup, JPA/Hibernate quirks, latency spikes (gc? of JPA/Hibernate)
Micronaut - could be the next big thing (too much like Spring, learning curve)
Ktor - coroutine support potential interesting, prefer a Kotlin+Java ecosystem
SparkJava - too bare (used with Sql2o), Javalin is a spiritual successor
DropWizard - older, poor documentation. But JDBI is sweet to use with other microframeworks
Amber (Crystal) - Kemal has a much faster edit/compile/run cycle
Rails/Sinatra/Web2py/Django/Flask/etc - prefer static typing and faster/smaller runtime
- node - express - passport (Use cookie based auth keeping the session in your storage. I wouldn’t waste time on JWT. There’s a decent amount of complexity if you want both the security of being able to revoke access to a bad actor and the convenience of long lived sessions, and at the end the auth server will most likely need to access storage and use cookies for that anyway (eliminating the benefits of JWT). So I’d start with cookie based auth and build up complexity as needed.)
- postgres - On the Node side, I don’t recommend adding the complexity of an ORM at first (or ever). The node pg driver will give you arrays of objects back for rows. It’s convenient enough not to need the extra overhead of an ORM. - As a side note, Postgres has modules for you to implement a decent first version of a lot of things, such as search for example, before you need to reach for a dedicated solution. This makes it amazing for startups in my opinion, as you can explore ideas very quickly.
- statsd / grafana (to monitor your app and learn from the behavior of your users)
- docker-colpose.yml to make spinning up your dev environment with node / db / stats as simple as “docker-compose up”
- DigitalOcean for hosting - Use their dokku image - Set up daily backups to Spaces since your DB will be hosted here at first too
- dokku for deployment with the Postgres, letsencrypt and grafana modules - deployments are as easy as “git push master dokku”
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.
Large or complex apps (such as those at work or things I intend to have a long lifetime):
- Backend: Rails
- Frontend: Ember
The combination of these two is really powerful. I can focus on my complex problem domain and not have to make too many choices about project structure, testing setup, and other decisions that lead to bike-shedding.
Smaller applications (such as side projects):
- Backend: Rails, Phoenix, or Amber
- Frontend: Ember, (P)react
Rails & Ember are still very productive for small apps, but I'm finding Amber (written in Crystal, similar ethos to Rails) to be a faster, smaller alternative when a side-project is resource limited (plus, it's an interesting new community). Preact and React are quite good for building small things quickly or dropping into existing projects, so I've enjoyed them in that context. Ember and Rails are phenomenal over a long period of time, because they tend to have a relatively smooth upgrade path (in many cases with Ember, there are automated tools.)
I'm a strong proponent of Postgres. It gets better with every version and is great for both development and production use, especially if you want to do zero-downtime deploys (Postgres has some cool tools for avoiding locking of whole tables during updates, e.g. concurrent indexing, etc.)
Just the bare minimum, favour loading speed on worst case ever (Edge/Bad 3G connections) over fancyness
- Bootstrap 4 (minified) - jQuery (minified) - Sass/Less (minified)
Backend
Solid programming languages/frameworks, avoid dynamically typed/interpreted languages, favour statically typed/compiled languages
- C++17, coupled with httpnh2, Beast or Wt framework - Java 11, with Thorntail (avoid Spring bloat) - Go - Rust
Also people mention nginx, again use apache because it has letsencrypt has easy support for HTTPS certificate.
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!
JS will eventually support types natively and will be similar to TS/Flow's API. I have more faith in ReasonML taking off than Dart/Flutter but I hope I'm wrong.
- React and React Native, even ReactXP/react-native-web if appropriate
Vue is good but not good enough to convince most of the community and the community makes it. Their native strategy needs more work, and it's too valuable not to have one.
- Apollo Client
So much boilerplate disappears, and it's powerful enough to be your one data source which enforces many best practices and capabilities.
- GraphQL Gateway stitching GraphQL Servers and serverless resolvers
GraphQL/serverless does for the backend via microservices what React did for the frontend via components. The benefits to the entire stack are countless. Apollo Server (even AppSync) make it simple.
- A serverless datastore
There's also many great GraphQL ORMs but managing infrastructure/scaling should be avoided.
But if I wanted to quickly put together a website to test some hypotheses, I would try https://github.com/sahat/hackathon-starter.
Azure for hosting and peripheral services
It is truly a breeze to put together server rendered apps with this stack. I come from a JS heavy background but find myself so much more productive with C#.
It's not trendy, but that's mostly because it's Microsoft. But it is powerful and productive.
I develop 100% on a macbook.
Python/Sanic for the API.
PostgreSQL for the database.
Kubernestes on DigitalOcean (or similar kaas provider) for hosting.
A. Simple static sites:
- Jekyll
B. Medium complexity, CRUD applications:
- Phoenix/Elixir - Coffeescript
Note: With the latest version of Phoenix, you absolutely don't any JS frontends at all. Watch they keynote presentation for the liveview demo: https://www.youtube.com/watch?v=Z2DU0qLfPIY
C. Complex Web applications:
- Phoenix/Elixir - GraphQL/Absinthe - VueJs + Vuex + Coffeescript
Developing with Phoenix/Elixir is so much better than any of the node frameworks in the ecosystem - this has consistently been my experience. So, give it a shot if you can.
And coffeescript is taken over by other transpilers like TS and even ES6 and above.
Check here for static site generators. There are good alternatives to Jekyll.
Coffeescript has not been taken over. It even supports JSX.
Last time I looked at React you had to pick & include separate libraries for things like routing or dependency injection yourself, and these are separate things by separate people and the libraries you pick may or may not work with others now or in the future - think DLL hell with conflicting versions and a rock and a hard palce in terms of what you upgrade. That was a deal breaker for me.
Angular on the other hand has a lot of this built-in already. Bonus points for Angular is that it has an extensive, mature and well-maintained official UI library (https://material.angular.io/) and now has a CLI tool for quickly scaffolding your app. As a result, putting together a website with Angular these days is trivially easy - its like lego. There are Long Term Support releases if you are worried about churn, but I've not found the changes between major versions to be anything to worry about.
Criticisms of Angular:
- feels like quite a lot of boilerplate code has to be written if you dont want to use the CLI tool (and if you do, a lot of the code it generates might look like "magic" unless you bother to go learn how modules and bootstrapping etc work)
- inter-component communication (beyond simple parent-child relationships) feels a bit awkward and "unclean" (parent-child is trivial though)
- learning curve for the RxJS stuff can be high if you are not familiar with it and are doing anything slightly complex.
For the backend, I've personally been using Golang. Not used node.js professionally, but I am very interested by node.js's replacement http://deno.land/ - deno+TypeScript on the backend and Angular+TypeScript on the frontend is very tempting.
VSCode is the absolute go-to editor for all of this stuff. It really is pretty decent.
- Golang + Postgres for backend
BTW, LitElement is the bleeding edge front-end framework from the Chrome team at Google.
For client I'm mostly using React and typescript.
For bigger projects, as others mentioned Postgres is a must. I use Node.js with express and knex when I'm able, but usually I'm limited to using either django/rails or MVC.net, all being pretty great.
Please do look into JHipster.tech It builds production grade web apps in a matter of minutes! The backend is Spring framework and you can choose your frontend to be React/Angular/VueJs (I recommend Vue). You can pick a DB, testing tools, monitoring tools etc.
The generated app is ready to go into production and all major cloud providers are supported out of the box.
All you need is a well-defined data model.
Vue on the front end, Django on the back end. That’s mostly because I know these frameworks quite well. And in the beginning of a project, all I want is an MVP as quickly as possible while maintaining some clean code standards.
I use firebase static hosting for the front end and a dockerized deployment on Heroku for the back end.
Later on, if the project grows and when I break components out into microservices, I may start to worry about other considerations such as performance and resource usage.
Storage: SQLite, assuming that in case of seeing actual load I migrate to Postgres.
Backend: Flask, I find it a nice tradeoff between features and simplicity.
Frontend: Angular, it seemed to bring some sanity to the frontend... But it seems rather bad at keeping backwards compatibility and I'm not sure if the bloat is worth it.
And also you should learn packaging to include dependencies by mentioning those in a single file. Parcel bundler has been working very good for me as it is fast (webpack is complicated and not fast) and incremental build is a fraction of a second.
Backend: - Language: Go, C# (.Net Core) or Rust - Database: Postgres. (Redis if needed)
Deployment: - Kubernetes or in simple cases a Unix based server running Docker. - CI: GitLab CI and/or Drone.io - Hosting: Google Cloud, AWS or Digital Ocean
Personally I stay away from Windows Servers, Standard .NET and MSSQL when possible.
Here's a tutorial: https://blog.dmatoso.com/build-static-site-generator-nodejs-...
- Linux
- Nginx
- Postgres
- Ruby (when I want all the Rails stuff) or Nodejs (when I don't)
- Elm (for anything app-like or Ajaxy in a browser)
- Utility classes for CSS (Tachyons or similar)
Static site: Jekyll
Dynamically generated site w/o real-time updates: Django/Flask (depends on the scope of the project)
Dynamic site with real-time updates: React ---------------------------
The general idea is old fashioned: keep the actual front end filesize low so that the user/customer doesn't have to wait for their browser to process a ton of JS.
We researched this to death recently and unless you have prior affinity or are saddled with technical debt the time has come to ditch React, Angular and Node for new from scratch development.
Vue.js for the frontend.
- Angular
- vanilla JS
Backend
- Springboot
- nodejs
DB
- MySQL
- MongoDB
HTTP server (if needed)
- Apache
OS
- centos
If the project is complex, Angular + Springboot are the best enterprise ready frameworks I've worked with.
If it's a simple project. NodeJS with Express for simple API requests. And on the frontend you rarely need a JS framework if the project is simple, not even a CSS framework.
As for the databases, MySQL, in my opinion, is the easiest RDB and MongoDB is a good all purpose DB.
Scala with Play
Postgres
Google K8S Engine
GoCD
Backend: MongoDB, Node.js, Express, RESTFul APIs, EJS Templates, AWS S3, AWS SQS, AWS EC2
Frontend: jQuery, Backbone.js, Vanila CSS, SPA Application.
For a real backend, Phoenix (Elixir) is the new Rails / Django. Google App Engine Elixir is a good place to deploy it.
Frontend: React - Unstated (or just setState) - Axios - Plain CSS (with BEM notation) - Create React App - Prettier - Jest
Backend: Node.JS - Express - Knex - PostgreSQL - Tape
VueJS (front-end) + Some theme support (bootstrap/framework7) + FireStore with Cloud functions
Oauth (google/facebook) for authentication.
So the "P"s of the "LAMP" stack of olden days might be a good first choice, probably switching out Ruby for Perl (as much as that pains me to say -- modern Perl + Mojolicious is awesome, but if you don't know this yet, it's probably too late).
Or C# / Java / Kotlin, if you've already got developers in this space or are willing to pay more and able to adjust to more mature management styles.
Go is somewhere between those two, and so is my current somewhat-happy place (old, but in a non-enterprisey org).
Node and Erlang/Elixir currently are good for some end points, i.e. if you really need a chat module. For the whole backend, I've got my doubts.
For the frontend, as others have said, if it's "just" a website, pick a good template system if you need to and just enhance it with some small javascript if needed (fancy selects and pickers). VanillaJS if you've got good JS programmers, jQuery if you just need fancy modules, (p)react if you need it on your resume.
If you either need to go SPA or need an REST API for other consumers anyway, writing the frontend in the devil's own language, 2015 edition might be necessary. I'm showing my biases again by suggesting something that already made a few choices, or you're bikeshedding again. One reason why React seems to be immensely popular with trainers/coaches. Just buy their 13-part video course and use their personal npms.
Sadly ember seems to be going the way of the dodo, ExtJS is proprietary and paleolithic and Angular strikes me as having a serious case of Java envy (which might be good. If you already picked that or C# for the backend and Struts ain't enough...).
The happy medium in this space seems to be Vue.
For the backend, use Postgres. Model your data properly, before you get to the shiny parts.
I'm not really happy with most of these parts, but that's webdev for you. The last time I enjoyed web programming was with Smalltalk/Seaside, but there's no going back...
For me, right now its: - Postgres - Go - Vue (considering Nuxt)
But for simpler/side projects, I'd seriously look at: - SQlite - PHP or Python/Flask - preact/htm for enhanced widgets
(And I would probably do the latter if I hadn't done Catalyst while everyone else was learning RoR)
The neo4j-graphql integration allows you to drive everything (including the database) from GraphQL type definitions. Resolvers are auto-implemented so no need to write boilerplate CRUD operations just to get your app up.
There’s a starter project here that bundles everything together: https://grandstack.io/docs/getting-started-grand-stack-start...
Backend: Self Hosted headless CMS such as Strapi
- React + Apollo on the frontend
- Postgres or some other database
If you don't need SEO: Heroku, NodeJS, React, Firebase authentication, Firebase db.
Misc: VSCode, Prettier, ESLint, Jest, Material UI, Enzyme
I'd only add NextJS as an option for the runway it offers and Meteor/Apollo/AWS as an alternative in that case.
I started to build a service in Elixir but found it lacked support for some crucial aspects (http/s tracing in this case). I've found it to be a very enjoyable language to work with (not just the Ruby bias talking), and a great cushion into functional programming.
Over there I've seen mention of Drab and Phoenix LiveView which piggyback on excellent websocket multiplexing to create an event channel between Elixir and JavaScript. This essentially means you can interact with the frontend of the application from the backend framework. There is a lot of discussion around performance/security implications, of course, but it is a great experience if you're backend driven.
Where Elixir couldn't meet my demands, Go did. It has `http/trace` in the standard library. It has static typing, it's fast, simple. Go has worked perfectly here as an "agent" of my main service. It is used purely to make requests and spit out results. I've found it much easier to deploy than Elixir (which usually involves distillery). Static typing in Elixir is often done through Dialyzer (annotated type-checking). In short, I'm saying I need both and that they complement each other.
I use a message broker to speak between the main service and the agents. Because I was using Elixir for the core service, I went with RabbitMQ. I've found that working very well on very modest hardware, and it is has been a big help having a well-known messaging standard to work with with available clients in different languages. To note - I only use this internally. Not sure if I'd expose this publicly in any way.
The database is always Postgres :P I use that with wal-e for backing up to s3. Still unsure on clustering. This is on a VPS because RDS and any other managed Postgres service was charging way too much for the hardware. With clients I would use RDS from the beginning.. and I would use Postgres as a document store before reaching for Mongo.
For managing servers, I either use the cloud provided cli (gcloud) or ansible on my own. I try to make sure I only ever use ansible to provision and modify them and everything is version controlled. This way I have a record of any changes I've made. I used ansible to setup wal-e backups on my Postgres instance. I'll also use it to setup clustering.
Other great tools on that may be Chef, Puppet, Terraform. Leaning more towards Terraform as it is agentless and declarative.
For application deployment I'm very much containerised. I've found Docker to have greatly simplified my deployment process once Docker itself is installed. As for clustering, Swarm is simple to setup. I was lured by Nomad, but I've decided to fully invest into Kubernetes instead.
I spent a good 4 months trying to setup a Kubernetes federation (cross DC) on a budget. Not easy. It was very painful. Best on my own was through Rancher after trying kubespray. Best in the cloud was through GKE. However, not happy with Google's pricing considering what else I can get. Digital Ocean released a Kubernetes offering and I can fire up a one node cluster (with free master plane) for $10/m which has 2gb ram on an ssd. For comparison, I think Google were charging me about $20+/m for 1.6gb ram with no ssd.
Within 10 minutes I can have a new cluster. I can apply my manifests to the cluster which have security policies, environment secrets, deployment strategies, health-checking. I can deploy my applications to it within minutes and easily integrate it with my CI/CD pipeline. I'm sure I could achieve similar with some cloud-native offerings (Google App Engine, etc), too, but I'd rather invest in something cloud-agnostic.
.. that's before even touching the frontend.
I decided to jump into TypeScript and VueJS. I'm still looking for that "unified" environment where all the layers and processes just seem to fit together. I've found the frontend ecosystem to be far too fragmented.
I don't see much point in creating any more complexity than VueJS already has. I use Haml for templating, SASS for extending CSS. Still unsure on a component/style framework. I think possibly Vuetify.
With all that said, my GO TO stack will eventually look like this:
* frontend: TypeScript/VueJS
* backend: Ruby, Elixir, Go
* database: Postgres
* message broker: RabbitMQ
* packaging: Docker
* container orchestration: Kubernetes
* CI/CD: Gitlab
* monitoring: Prometheus/Munin/Cloud tools
* logging: ?
* exception management: Sentry
* email: SendGrid
..man, could probably go on. It is never ending! I also think this is largely dependent on the size of the project. However, I still use those tools above on small projects because it forces me to become more familiar with the tools which I inevitably use on more important projects.
On the server side I use Perl to code whatever few chores I need there.
It's probably fair to say React is a good alternative to jQuery but I've yet to find a compelling reason to spend the time learning React as opposed to getting stuff done with what I already know.
In the end it's really all about productivity and after spending some time with most all the tools mentioned here looking for what was "best" I decided instead to look for what was "easiest" and ended up with the above "stack".
I just released a blog app made with these tools that's distributed in a 10k "blog.html" file that will run on any web server. Nothing else needs to be installed on your server to run the app. You can get it Azartiz.com along with a secure CouchDB backend and upload it to your website to check out how this approach works.
It demonstrates a "single page", run anywhere app, with user authentication, CRUD, full text search, user and admin accesses, and shifting the load of dependencies to 3rd party CDNs to reduce loads on the server hosting the app. Adding "Service Workers" to make it run "Offline First" is a snap using Google's "Workbox" toolset.
I believe the learning curve to use CouchDB as a backend is the main reason most developers have shied away from this approach. They're kinda "stuck" using SQL and haven't realized how much easier it is to build an app that uses a backend DB designed from the ground up for "web apps".
But... it's really easy to dip you toes in it now using the Azartiz backend and that blog app on your server. PouchDB.com also has a "Todo" app demo that can be plugged into the Azartiz CouchDB backend that you can learn with and it demonstrates a somewhat different approach than the blog app and CouchDB's "live sync" features that are really cool.
There's also CouchDB backend services available at Couchbase (https://www.couchbase.com) and Cloudant (https://www.ibm.com/cloud/cloudant), and CouchDB is pretty easy to install on a vps service like DigitalOcean.
Plus, you can install CouchDB on a desktop Mac, Windows, and even a Raspberry Pi, and use it to create backups and snapshots of your remote CouchDB databases, and of course, to develop your apps.
This is an amazingly powerful, flexible, and easy to get and use stack. I've never been as productive with any other toolset. But I didn't have any love to lose or time invested in using SQL backends. That's a lot of baggage to leave behind for most developers.
- https://github.com/mcohen01/amazonica with CIDER (in emacs) all set in a literate org file for setup (but still customization). So it's easy to ramp up new websites and web services.
- for advanced compute, deploy clojure to lambda or ec2. for simple compute, deploy node to lambda.
- for authentication and other boilerplate web services, use the aws services that exist. to deploy, again use literate org files (org-babel) and upload your jars where needed.
- you have to invent as you go along (for inspiration i like https://www.amazon.com/Everything-I-Know-Paul-Jarvis-ebook/d... - just started reading it last night, new book coming out soon), but it's more fun and efficient that way.
The most efficient stack is probably [you] <-> [20% elisp] <-> [60% clojure/cljs] <-> [20% html and js]. A good set of learnings for understanding how to get started with AWS services (without the clojure/cljs/elisp part) can be found in:
https://github.com/aws-samples/aws-serverless-workshops https://github.com/aws-samples/aws-modern-application-worksh...
As a caveat, this is what I'm exploring currently. This is what I'd love to work on (now unfortunately I gotta go back and do my normal day job stuff that I didn't finish last week, and then some husbandly errands and things). But if I had time, I would continue to grow in this area. You can briefly read about my journey to emacs in the past several months under Emacs here: https://github.com/tmsh/home (c'est la z's tutorials + evil mode + clojure/conj presentations are really useful). I haven't found any of the cloudformation or serverless frameworks easy to use (but maybe that's just me - kinda slow to start). But I'm optimistic about org mode + amazonica.
But don't take my word for it! Probably the most senior engineer in the entire world uses org-mode (https://www.reddit.com/r/emacs/comments/a2smk0/emacs_and_org...). And the guy who wrote HN originally was a fan of repl-based development as a strategic advantage (http://www.paulgraham.com/avg.html). If you don't like parentheses, you haven't been staring at the screen long enough so that they fade away (or use https://www.emacswiki.org/emacs/DimParentheses).
You have to learn the underlying target languages (JS, HTML, CSS, Xcode+Swift, Android Studio+Kotlin/Java; i.e., develop in emacs, press run in Xcode/AS) through various paths. And then you learn to program the programming of them with org mode/org-babel and to iterate faster with clojure and cljs. That's the growing theory.
The vibe I'm picking up lately is that react + typescript is not completely horrible for frontend development and my impression is that I can hire people to work on such projects. Nothing wrong with this stack. A solid conservative choice. But what about five years from now?
Some trends that I'm picking up lately that could start changing web stacks in the next five years and should be kept in mind when choosing stacks right now:
- Statically compiled languages are now a thing on the frontend. Most of the senior frontend people I know are very opinionated about which transpilers and tools they use but writing "native" javascript seems much less of a thing then it used to be. E.g. Typescript seems popular now. Just a few years ago I would have seen a lot of people pull up their noses for e.g. coffeescript but typescript seems to have broken through that. Probably for a new project, you should go statically compiled from day one across your entire stack from day one.
- WASM and PWAs mean that most current javascript frameworks will not be the only game in town for developing complex UIs in browsers. I'm seeing a lot of activity around Kotlin and Rust lately and they are looking to provide full end to end solutions that effectively replace large parts of the stacks that were common in the last decade or so across web, desktop and mobile development. People seem to dislike things like Electron, yet it clearly fills a need. WASM and PWAs take that to the next level.
- This also means that fullstack no longer means node.js and browsers: other languages are now becoming full stack. For example, Rust is a proper full stack language and you can do anything from OS kernels to browser apps in it. Likewise, Kotlin can compile to the jvm, javascript, wasm, and native code. C# and a few other languages are also moving into browsers. This means javascript or transpiled javascript are not going to be the only way to do full stack in the next few years. This also means that new frameworks more appropriate to these languages will start competing with e.g. React. I recommend keeping an eye on this space but being conservative in rushing in as a lot of this stuff is changing rapidly.
- VS Code seems to slowly bring frontend work out of the stone age where it has been stuck since the decline of the likes of Visual Basic, Delphi, and other IDEs for UI work in the late nineties. Code completion, real time feedback about syntax issues, and even some refactoring support are now possible. It's still horribly primitive to what I'm used to for backend development. But things have improved a lot since VS Code came out. Using editors that don't tell you your code is broken still seems to be a bit of a macho thing. But these days there is much less excuse for committing code that demonstrably is syntactically incorrect, has unused/redundant code, imports, etc. Or includes things that obviously won't work as intended. Whatever you pick, make sure there is awesome tool and IDE support for it.
Maybe I'm overly negative but JS, React etc are a can of worms short-term that are likely to take a lot of more time than creating a simple website. IIRC there even exist quite good static website generators nowadays.
and how are you doing this in Scala.js? As far as I can tell, outside of rolling your own, there's Binding.scala, Monadic-Html, Scala.rx, and a handful of other, perhaps maintained, in-house libraries for building SPAs (i.e. not dependent on the "cool kids" libraries, like scalajs-react).
Just curious what your approach is as I had a great time doing a project in Scala.js a year or so ago, and am looking to possibly build a Scala/Scala.js SPA for the next project (instead of the default: Angular/React + TypeScript on the frontend).
I use Scala.js for plain well written client code.
If you're into spa, there's also monix, outwatch and a few others I think.