we use jooq extensively it's probably the most valuable tech in our backend.
Also among various other tech stacks I've never seen something that hits the sweet spot between "plain sql" and "advantages of ORM-stuff" as well as jooq
I have never understood why typed languages make you slower at any point in time (early, late etc.).
Because you have to hit more keystrokes to write your program?
That doesn't compute. typing is the thing you do the least amount of when programming. In all best practices we are taught to not save keystrokes. Name your variables expressively. write small functions. document code. Write tests. All ""excess"" keystrokes nobody questions. But when you have to type " ... : number" it's slow velocity?
In my opinion people vastly over-estimate productivity boosts of saving keystrokes. It's the tedious, boring part of the work that you would like to skip entirely, hence excess keystrokes feel way more "slowing you down" than they acutally are.
Although it doesn't matter, you actualy save keystrokes: autocomplete, auto-refactors and less low level unit-tests compensate the couple of type annotations easily.
I'm personally in the "functional handler" way of doing HTTP Request camp.
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...
- 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
I agree. I exlusively write React Frontends since 2014, and very minor things have changed.
It feels a lot more stable than before, where every project had homegrown framework stuff on top of backbone.js or jquery, or then using ember.js. There was just an awful lot of difficult discussion on how to design event-bus abstractions, global state management and general architecture
To me it feels like the frontend ecosystem has stabilized a lot, since the react paradigm is very robust and versatile. For most difficult problems, the solution is somewhat clear. Sometimes more, sometimes less elegant, but at least the timeconsuming disussions have become less frequent within a team
TypeScript is an invaluable, mature technology that provides large productivity boosts to any team that maintains a mid-sized code base.
It plays extremely well with React too, and it's benefits are independent of the tech stack. If you are used to typed components/templates, you will NEVER want to go back.
I would argue that is more important to have static typing in the front-end compared to the back-end in a web-application context. There is more state, lot's of shared entities and unit tests are expensive to write and maintain.
I like it as well. I have yet to see tech stack that has comparable potential but is less complicated and can be stripped down as low as the web stack if your requirements permit it.
I mean yeah, if you have a big app, complex requirements, there is a bunch of stuff you need to take care of.
However, I would like to see the tech stack that allows you to do the same with less complexity.
It's not like Android (gradle?!, java 6?!, the android api!?) or iOS development is a walk in the park if you want to do anything with production quality.
These are a lot of tedious to write tests in a frontend codebase that mainly renders a lot of state into HTML.
Additionally, these are tests that you will have to tediously adjust every refactor since HTML frontends and it's data APIs behind it tend to change often over the lifecycle of a product.
From my experience, "only those tests" save you hours and hours of programming time.
TypeScript is the one technology I would discard last of the entire web stack.
Using TypeScript instead of JavaScript is such a productivity boost for a team developing a sizeable single page application, any other technical decision (which Framework, tooling decisions) is almost irrelevant relative to this major improvement.
TypeScript has ALL the properties that should make adoption a no-brainer:
1) Increases developer productivity, especially over long term maintenance timeframes. (My non-scientific, ymmv estimate is at least 30%)
2) Reduces production exception rate significantly
3) Can be adopted gradually
4) Full JavaScript ecosystem still at disposal
People seem to massively underestimate the benefit of a typed language in a frontend codebase. At gunpoint, I would rather have the backend in a dynamically typed language and keep TypeScript for the frontend. Chances are that the distance between your database and the API is not far, so static typing is not that useful.
However, if you have decided for a client side rendered application, your app is stateful, dynamic and probably quite big. Static typing really helps to avoid mistakes and increases the ability to refactor quickly and correctly by order of magnitude.
There are too many hardly ever visited code branches, and tests are very costly to write for an application where users can click a lot of things.
It will take a person a couple of days to "grok" Redux, and a quite a bit longer to fully understand the ins and outs so one can make informed, confident decisions on how to solve problems "the Redux way".
Now you gain "cool" things by doing it, but here is the catch: Is the benefit worth the time investment to get there?
His argument is that for a lot of simple apps it isn't. You get very far with plain React, and a project has to have significant complexity to pay back the costs of fully understanding Redux.
I would argue a lot of people picking the React ecosystem make the mistake of choosing too much architectural complexity, not too little.
The extreme pluggability helps to broaden usage of Redux. But it is overkill for many projects. Decoupling is important, but it is not free (see parts of the Java ecosystem).
Devs should consciously decide what to introduce, and leave out stuff that simply doesn't increase development efficiency given the nature of their project.
Not every application faces all the problems you mention:
A lot of teams don't have the "designer" problem and are just fine without JSX.
Passing data through dozens of children is not a problem in every application, a lot of simple CRUD stuff can do just fine without Flux.
Even bundling is not necessary for progressively enhanced websites, and for most SPAs a really simple, naive strategy will do just fine.
If the requirements of your project are ambitious, some complexity is not avoidable.
But the problem today is that a lot of unneeded complexity is introduced into projects because people want to adhere to "best practice" and don't question what they need and what they don't need.
In my opinion, it is a huge mistake to not actively resist complexity creeping into your project. You should only give in if it there is proof that it makes sense economically.
This issue is another variant of "premature optimization is the root of all evil"
For anyone that has the ability to pull off a project that needs seperate state management.
It's really just a days worth of looking at the original flux, redux and other implementations and figure out what's best for your team and project.
It doesn't take more energy / knowledge than to hack around patterns that don't perfectly fit your projects needs with the "everything included" frameworks.
I agree with your argument. I have seen people say on HN that 1 hour of setup to start a project is too much. If this is the case, React + stuff is really not the right thing for you.
However, the React ecosystem is really not that complex. You can write clean, sizable apps with vanilla React.
Then you might need a state management system like Redux. Its quite easy to roll out your own that fits your project and does not have all the pluggability whistles like Redux.
All other things are really not needed for most people, and if you do, you are facing problems so large, evaluation of libraries is a small fraction of the effort.
It's more the mindset of people "I'm missing something great" that drives them crazy and into framework fatigue. (OMG server-side rendering, falcor, relay, immutable.js arrgggh)
Usually, you are missing something you don't need, otherwise you would be looking for it actively.
you can use the functional way of setState by passing a transaction function (state: State) => State . This allows for typed, immutable updates since the function gets passed a copy of the state.
I really don't understand the underlying complaint of your comment that the React ecosystem is in constant flux (see what I did there?)
I've been writing React SPAs for roughly two years now.
Very few things have changed. The first app I've written roughly looks like the newest one. Couple of lessons learned here and there like everywhere else.
Yes, there are many Flux libraries and different implementations. However, a decent State management solution for React is roughly 200-300 LOC. So there are many of those 200-300 LOC libraries. So what?
If it's a big project, you should spend the time to figure out what fits YOUR project and YOUR team the best.
If it's a side project, use the most popular with the best documentation and be done with it.
From my experience, it is not about the FRP kool-aid. It's about the robustness of the concepts of React (DOM diff-ing, favor immutability, declarative views etc.)
Adopting something like elm might have its advantages, but also comes with practical disadvantages that, depending on your team and your project might be simply too big make the jump.
React got a lot of things right in my opinion. So much that to go from apple to fruit salad, you need roughly 200-300 additional LOCs, and you have a very robust Frontend system that, once you wrapped your head around React, has a very low knowledge barrier.
However, the good traits of React are not attributable to one concept like "FRP" but are simply "good concepts" that seem to influence other Frameworks to do "the same, a little different".
The adoption, the somewhat small API, the support from a large company, the possibility to integrate it easily in existing codebases that use other frameworks and react native has a much stronger pull than FRP in my opinion.
It is my main IDE for Typescript since v0.1. VSCode in combination with TypeScript provides a superior Frontend-Dev experience to any other Language - IDE combination in my opinion.
Apart from an occasional restart required it has been pretty solid. Performance(autocompletion etc) is very good and for TypeScript development, VSCode is pretty feature complete...
Also among various other tech stacks I've never seen something that hits the sweet spot between "plain sql" and "advantages of ORM-stuff" as well as jooq