I completely agree with this. Whatever's most familiar for you, but hopefully, it should be familiar for other people too. Try to write it in a way that you can switch out parts if you really needed to. For example, I'm still a Rails programmer but I've been structuring my apps differently from traditional Rails (oftentimes just doing the API backend).
However, that's only because I still have the luxury of time. If I had a gun to my head and a finite number of hours to code an app, then I'd go with vanilla Rails. If I was given a few weeks to study a new framework, I'd go with Elixir/Phoenix, but only because I spent a few days trying it around and while I'm not particularly fluent with it yet, I like its design and speed a lot more than Rails.
I think this is why we perfect our craft. We have to be able to code fast or code pretty, depending on the circumstances.
What Dart library/framework do you use for the backend? The recent DartConf has only 5 mins of talk of Dart server end. The emphasis seems to switch to use Dart for front end clients.
Most of the times a good old non-SPA with NodeJS / Express / Some ORM with vanilla JS / Handlebars and SASS will do the job without having a huge technical debt.
If on the other hand the requirements are to have a more complicated SPA, I would go with React / Redux and a NodeJS / Express / ORM for the API. Hosting the front-end on an S3 and the backend on a Digital Ocean Droplet.
I build lots of CRUD apps very fast with JHipster, which is designed to handle the initial bootstrapping of traditional CRUD apps very well, while also allowing you to choose your tech stack (in some ways). Because it's giving you a nice boilerplate, you can customize it as you go.
The stack ist mostly Java with Spring and AngularJS on the frontend.
Back end: Java 9 JVM, Spring Boot web service, Kotlin, plain SQL via JdbcTemplate working with Kotlin data classes, Liquibase for DDL and migrations, Spring caching with redis if need be, Postgres, deployment via docker to AWS Fargate
Front end: Angular... but I’d like to try Vue. Nginx and docker to Fargate
I tried Vue a few months back and I could not be happier. The single-file components (html/css/js) make development a breeze. I now need to make changes in relatively complex components I created 2 months ago, and my learning curve is small. Most things in Vue are expressed as expected and just work.
I cannot wait for full ES6 support in vue - it will get massively better by then.
I'm really in love with just having v-if available. Ternary operators in React are ugly and the alternative of hoisting control flow makes things much more complicated to read through.
This. Might not be hip and trendy, but we've been using this stack (just with React on the frontend) and it's probably the best that I've ever worked with.
Anyone who knows Java/Kotlin will have experience with Spring Boot so it's easy to find good people. The whole platform is as mature as it gets at this point and the docs/questions cover pretty much everything.
It's really easy to get started when working on smaller projects, but you can also easily scale and integrate loads of other technologies if/when you need to. You might not need a complex caching layer, monitoring, metrics etc when you're starting out, but you know you can add it in if needed.
I hadn’t seen this before. It’s really cool. It’s quite validating to see a lot of things I’ve handrolled implemented into a framework like this, for example the environment corner ribbon. I’d use it for sure for a new project.
I would use rails for the API and react on the front end. Rails 5.1 makes it super easy to do this and Rails 5.2 which is coming out soon (5.2.rc1 I'd already available) also adds some neat features. Database I usually pick is postgres.
Server side rendered templates with Rails or Flask using Postgres + Redis + background worker of choice.
I'm starting to build some apps with Phoenix now, but it's not because I feel the above 2 are poor choices. I just like learning new things, especially when I see big wins of potentially using it. It's another tool in my tool belt, not an all-in replacement of the previous thing.
100% agree - unless you're doing anything especially novel, or know you're getting 10's of millions of connections from day 1, with the ecosystem around it, I wouldn't hesitate choosing Rails + Postgres + Redis + Sidekiq.
99% agree. I just don't feel like using Sidekiq or Celery anymore for short lived jobs when I can do it without any additional infrastructure using Elixir and Phoenix (same for websockets.) However anything else is easier with those older languages including deployment, especially for Rails (capistrano or mina.)
- Clojure and clojurescript give nearly identical experiences on the front and back end, with the ability to actually share some code between the two.
- Clojure is dynamic and spec gives some really awesome validation and generative test capabilities
- There is a lot of fuss around javascript frameworks and dealing with html / css build tools and their arbitrary syntax. Clojure front end frameworks provide tools that make templating html look just like regular data structures in clojure, styles too. With stylefy you can also keep all styles inline while supporting media queries. It really is a low cognitive load setup once you get going. I love it.
- re-frame is basically redux but easier and with less boilerplate. I use it for small and large projects.
- Pure immutable functions are such a game changer. Even poorly written projects with tons of features can be reasoned about and broken down for long term maintenance if the language supports immutability and pure functions. Re-frame really plays to this strength for managing state and I can't say enough good things about it. Been working with it for 2+ years and I can't imagine switching for anything else I've seen out there.
Twenty years ago, a simple CRUD app would have been written in Visual Basic or Delphi. It would have needed one programming language, and one framework. The tool support would be good: everything would talk to everything else. Heck, you'd even have an IDE with autocomplete!
Today, a typical web app requires no fewer than five different languages (JS, HTML, CSS, Python/Ruby/whatever on the server, SQL). And that's before you even start on the frameworks:
- Something to make JS bearable (eg React)
- Something to make CSS bearable (eg Bootstrap)
- Possibly another JS framework (eg Redux)
- A framework to make web serving bearable (eg Flask)
- Something to make database access easier (eg SQLAlchemy)
- Did I mention Webpack, Docker, AWS, CI/CD...?
Now, I'm sure we're going to have a big lively thread, debating which technology we should choose for each of these slots (and whether the answer has changed since last week). But the ecosystem which requires so many components, for a simple CRUD app, is utterly insane.
We designed Anvil (https://anvil.works) to be the complete opposite of this. It's a development environment that lets you build and deploy full-stack web apps, from your browser, with nothing but Python. There's a visual designer, client code, server code, and a built-in database. Unsurprisingly, when we did the head-to-head tests, a typical CRUD app is about seven times faster to build with Anvil than with traditional tools. Looking at the list above, are you surprised?
I do really enjoy making apps with the modern web stack, but when I look at how many moving pieces are required to make something simple, I do start to wonder if it's all a bit pants-on-head crazy.
It's probably because those tools are not made to "make something simple".
If you have a simple need, just go for simple solutions: a Django/symfony/whatever without JS on frontend (I suppose that's not even the simplest, but wil get you a long long way)
I think this is at a tipping point and will be solved soon (for better or worse) because network effects. Technology at each layer consolidates once the next layer is identified, which I think is functional programming everywhere and thus anticipate a consolidation is already underway.
Hmm, according to wikipedia lisp appeared 60 years ago, so it's had some chance to gain ground and functional is popular currently but everywhere, soon seems like a stretch
Not sure if trolling. FP requires fast immutable data structures. Okasaki was published in 1998. Persistent data structures require amazing GC. JVM got good in 2000s. To do it in the database requires cloud scale compute and storage. AWS got good in 2010s. Datomic (functional paradigm postgres killer) got good in 2018.
You need neither JS nor CSS to build a simple CRUD app. Just use the server technology of your liking and a database. Sure, it will look ugly but so did apps 20 years ago.
The landscape got complicated because now we build beautiful and elaborate things. We have apps that serve hundreds if not thousands of users simultaneously. Modern databases get hammered with requests every single second. What was the average case scenario for a CRUD app 20 years ago? Some godforsaken company that had a couple hundred employees at best and no more than 10 at time were accessing the data. And lets not forget the endless hours we used to spend trying to get reports printed properly. With web apps whatever you see on the screen you get on the paper.
> The landscape got complicated because now we build beautiful and elaborate things
As someone who works at a large company which has TONS of crud web apps, let me just say ...
No.
We don't.
We build ugly disasters, badly, with loads of bugs and unusable interfaces.
And of course, only very rarely are 2 crud apps built using the same stack. We have everything from Oracle WebForms to Ruby on Rails, to AngularJS on NodeJS.
And may I add, the "beautiful" ones are the worst in terms of usability. Can we place take all the frameworks that don't have a very good and built-in data grid and shoot them ?
As someone who builds SaaS sites the shit I build now are miles more elegant and functional than the apps I used to build back in the Visual Basic days, or even earlier when I was writing software for DOS. We may bitch and moan all we like but the fact is that the average web app of today is way more usable than the average windows app some twenty years ago.
I won't argue that the situation with web development is ludicrous, we have a bazillion of js frameworks that last no more than two to three years until the next shinny thing pops-up not to mention changes in pretty much every aspect of the stack, from devops to server-side languages and whatnot.
As a testament, take a look at the available dashboard templates in the major template sites. Some of them are so beautiful they make me droll. We never had so gorgeous interfaces in recent history.
Well, perhaps it's that I used Delphi back in the days, but I have a different experience. Delphi apps the equivalent of tiny webapps were orders of magnitude simpler.
Yep, it's a hosted service - you can publish your app with one click! Self-hosting requires an on-site Anvil installation. This is because many of the things we do to make things easy (eg returning live database rows from server to client in a function call, then manipulating them directly there) require server-side report.
We think it's worth it - for example, it saves you building a new REST API each time you blow your nose - but the trade-off is that we can't just provide a "download as Flask app" button.
If you want to run server code on your own machine, though, check out the Uplink. It's a library you 'pip install', connect to your app, and then you can drive your code from the web. Here's an example driving a Raspberry Pi: https://anvil.works/blog/uplink
While Anvil sounds interesting, one thing that pops to mind before buying into such a technology is "what are the limitations?" Could I build a multi-tenant app? Can I integrate JS components, like a sophisticated datagrid? Will I be able to query the DB with SQL as I wish? Does it use AJAX behind the scenes to speed up the responses? etc.
> Will I be able to query the DB with SQL as I wish?
Our built-in DB is shared, so you can't run SQL against it on a standard plan. Dedicated-plan customers can do that. Or just spin up another database and access it with the standard Python tools - example: https://anvil.works/blog/dashboard
> Does it use AJAX behind the scenes to speed up the responses?
I'd really like to use a tool like Anvil, but my experience with one-click magic solution tools is that it oftens greatly limits the customization options or doing something outside what it's built for.
Well, all I can say is that this is a known design trap that we have strained every sinew to avoid.
Anvil provides a toolbox of help you can take or leave, all driven by a real industrial-strength programming language (Python). And if all else fails, you can always drop down to the HTML and Javascript, and/or a REST API.
Being an Oracle consultant by trade I'm probably biased, but I've always enjoyed the simplicity of Apex from a developer's perspective. Simple CRUD forms can be built and published in minutes that are both functional and beautiful. The language stack is SQL/PLSQL/HTML/CSS/JS, and most all of the Javascript you'd ever need to write for field validations, etc. is built for you. I think folks tend to ignore it because it's not open source, but as a tool it's underrated. Not the most performant solution out there, granted, but suitable for most cases. If your backend database is Oracle, it should absolutely be in consideration.
Great question. The funny thing is, 6 years ago, if you'd ask the same question (and I'm guess that's what you're coming from) the go-to answer on HN would've been Rails / Django something. Where both will allow you to build a basic crud app in 20 minutes.
Since then, everybody has gone heavily into various javascript stacks, and the norm has become to deal with 20 different packages to build (somewhat) the same thing. And the first hour will easily be spent researching different dependencies, trying to get them all to work how you'd want etc.
It's easy to see this as a horrible backwards progression, but the reality might be a bit nuanced.
The easiest way to get a basic crud app up and running these days is probably still some sort of rails/django stack. But today's requirements in terms of UX / dynamism (is that a word?) require you to end up building things differently, so even if you get up and running fast with a rails app, you'd end up having to build up a pretty hefty JS stack in the end, so you'd basically be delaying the inevitable.
So the answer really depends on what level of "good enough" you're going for.
> But today's requirements in terms of UX / dynamism (is that a word?) require you to end up building things differently, so even if you get up and running fast with a rails app, you'd end up having to build up a pretty hefty JS stack in the end, so you'd basically be delaying the inevitable.
I'm starting to wonder to what degree this is actually true.
Most people I know, all along the spectrum of 'computer literacy', complain about the slowness and brokenness of many sites and web apps. On the other hand I've never heard anyone complain about a lack of 'dynamism'.
To be clear, some degree of interactivity is often useful. But I can't help but feel that it's quite often not at all necessary to move things like routing, validation, and (almost) complete page changes to the client side, at least not as long as it increases complexity to such a degree.
I came to say something similar, it’s easy in tech to see something could be “better” but from the outside most people just want something that works and is easy to use (pretty is bonus).
Secondly I’d argue that if “dynamicism” matters, choosing rails or Django doesn’t hinder that ability as a lot of that is simply presentation layer concerns.
If the application is going to be around longer than 5 years, roll your own MVC or ROA pattern in Java. Write your own DAO and database calls (stay away from ORMs). Keep 3rd party library use down to a minimum, limiting your vulnerability exposure and rewrites due to upgrades.
As a developer who has worked on code bases that were home rolled, and built with popular frameworks (spring, rails). The worst code bases I've ever worked on were home rolled. Obviously that's only my experience, but I have a hard time agreeing with this advice.
Home-grown means every other developer that ever has to touch it is going to have huge additional overhead getting started with the codebase (because your documentation is going to be nonexistent), and you're going to spend a ton of time unnecessarily reinventing the basics.
These days it's never worth it to home roll in the CRUD world. There's way too much good tooling out there.
While it is true that there is additional overhead, they did say "if the application is going to be around for more than 5 years".
After 5 years there is a better chance you can make changes to a pure language coded app, than try and get what ever stack was common at that time working.
Basically, it could be the difference between throwing away your app and rewriting it.
> than try and get what ever stack was common at that time working
Doesn't seem like a problem for languages with sane package management solutions, of which there are plenty. A Java app on Maven is going to work just fine in 5 years, and on the latest version of java to boot.
Maven is a build tool and can help manage dependencies. It doesn't ensure your code base is compatible with the latest version of the dependency or ensure the dependency is still supported.
I'm working on code bases that are 10 years old today, built on asp.net webforms and mvc. If you don't choose a FOTM you'll be ok, all the answers are still on SO.
183 comments
[ 2.9 ms ] story [ 166 ms ] threadHowever, that's only because I still have the luxury of time. If I had a gun to my head and a finite number of hours to code an app, then I'd go with vanilla Rails. If I was given a few weeks to study a new framework, I'd go with Elixir/Phoenix, but only because I spent a few days trying it around and while I'm not particularly fluent with it yet, I like its design and speed a lot more than Rails.
I think this is why we perfect our craft. We have to be able to code fast or code pretty, depending on the circumstances.
Most of the times a good old non-SPA with NodeJS / Express / Some ORM with vanilla JS / Handlebars and SASS will do the job without having a huge technical debt.
If on the other hand the requirements are to have a more complicated SPA, I would go with React / Redux and a NodeJS / Express / ORM for the API. Hosting the front-end on an S3 and the backend on a Digital Ocean Droplet.
And we use Angular on the front end.
And I'd recommend GraphQL, takes a lot of worry about API design and wiring off your shoulders.
For JS, Vue.js probably. Though I'm still using Backbone + Marionette.
The stack ist mostly Java with Spring and AngularJS on the frontend.
http://www.jhipster.tech/
Back end: Java 9 JVM, Spring Boot web service, Kotlin, plain SQL via JdbcTemplate working with Kotlin data classes, Liquibase for DDL and migrations, Spring caching with redis if need be, Postgres, deployment via docker to AWS Fargate
Front end: Angular... but I’d like to try Vue. Nginx and docker to Fargate
I cannot wait for full ES6 support in vue - it will get massively better by then.
Anyone who knows Java/Kotlin will have experience with Spring Boot so it's easy to find good people. The whole platform is as mature as it gets at this point and the docs/questions cover pretty much everything.
It's really easy to get started when working on smaller projects, but you can also easily scale and integrate loads of other technologies if/when you need to. You might not need a complex caching layer, monitoring, metrics etc when you're starting out, but you know you can add it in if needed.
Interesting enough, it probably means the market is still growing.
Server side rendered templates with Rails or Flask using Postgres + Redis + background worker of choice.
I'm starting to build some apps with Phoenix now, but it's not because I feel the above 2 are poor choices. I just like learning new things, especially when I see big wins of potentially using it. It's another tool in my tool belt, not an all-in replacement of the previous thing.
https://github.com/Day8/re-frame http://www.luminusweb.net/
edit: Should probably say why...
- Clojure and clojurescript give nearly identical experiences on the front and back end, with the ability to actually share some code between the two.
- Clojure is dynamic and spec gives some really awesome validation and generative test capabilities
- There is a lot of fuss around javascript frameworks and dealing with html / css build tools and their arbitrary syntax. Clojure front end frameworks provide tools that make templating html look just like regular data structures in clojure, styles too. With stylefy you can also keep all styles inline while supporting media queries. It really is a low cognitive load setup once you get going. I love it.
https://github.com/Jarzka/stylefy
edit-2: More whys...
- re-frame is basically redux but easier and with less boilerplate. I use it for small and large projects.
- Pure immutable functions are such a game changer. Even poorly written projects with tons of features can be reasoned about and broken down for long term maintenance if the language supports immutability and pure functions. Re-frame really plays to this strength for managing state and I can't say enough good things about it. Been working with it for 2+ years and I can't imagine switching for anything else I've seen out there.
The back end is way more mature than front end SPA stuff so I'll just list some things I'm really glad to have in that space
- re-frame : like redux but better
- re-learn : lets you create tutorials for application with no changes to dom
- cljsjs/filesaverjs : cross browser file download dialog
- cljs-react-material-ui : material ui react library port
- camel-snake-kebab :useful for changing casing
- com.rpl/specter : easy way to deal with large nested data structures
- stylefy : inline styles with support for media queries and animations (all with clojure data structures!)
Today, a typical web app requires no fewer than five different languages (JS, HTML, CSS, Python/Ruby/whatever on the server, SQL). And that's before you even start on the frameworks:
Now, I'm sure we're going to have a big lively thread, debating which technology we should choose for each of these slots (and whether the answer has changed since last week). But the ecosystem which requires so many components, for a simple CRUD app, is utterly insane.We designed Anvil (https://anvil.works) to be the complete opposite of this. It's a development environment that lets you build and deploy full-stack web apps, from your browser, with nothing but Python. There's a visual designer, client code, server code, and a built-in database. Unsurprisingly, when we did the head-to-head tests, a typical CRUD app is about seven times faster to build with Anvil than with traditional tools. Looking at the list above, are you surprised?
I do really enjoy making apps with the modern web stack, but when I look at how many moving pieces are required to make something simple, I do start to wonder if it's all a bit pants-on-head crazy.
The landscape got complicated because now we build beautiful and elaborate things. We have apps that serve hundreds if not thousands of users simultaneously. Modern databases get hammered with requests every single second. What was the average case scenario for a CRUD app 20 years ago? Some godforsaken company that had a couple hundred employees at best and no more than 10 at time were accessing the data. And lets not forget the endless hours we used to spend trying to get reports printed properly. With web apps whatever you see on the screen you get on the paper.
As someone who works at a large company which has TONS of crud web apps, let me just say ...
No.
We don't.
We build ugly disasters, badly, with loads of bugs and unusable interfaces.
And of course, only very rarely are 2 crud apps built using the same stack. We have everything from Oracle WebForms to Ruby on Rails, to AngularJS on NodeJS.
And may I add, the "beautiful" ones are the worst in terms of usability. Can we place take all the frameworks that don't have a very good and built-in data grid and shoot them ?
I won't argue that the situation with web development is ludicrous, we have a bazillion of js frameworks that last no more than two to three years until the next shinny thing pops-up not to mention changes in pretty much every aspect of the stack, from devops to server-side languages and whatnot.
As a testament, take a look at the available dashboard templates in the major template sites. Some of them are so beautiful they make me droll. We never had so gorgeous interfaces in recent history.
Of course as always YMMV.
We think it's worth it - for example, it saves you building a new REST API each time you blow your nose - but the trade-off is that we can't just provide a "download as Flask app" button.
If you want to run server code on your own machine, though, check out the Uplink. It's a library you 'pip install', connect to your app, and then you can drive your code from the web. Here's an example driving a Raspberry Pi: https://anvil.works/blog/uplink
Yep! We have customers who have.
> Can I integrate JS components, like a sophisticated datagrid?
Yep! Reference docs: https://anvil.works/doc#js_interop
> Will I be able to query the DB with SQL as I wish?
Our built-in DB is shared, so you can't run SQL against it on a standard plan. Dedicated-plan customers can do that. Or just spin up another database and access it with the standard Python tools - example: https://anvil.works/blog/dashboard
> Does it use AJAX behind the scenes to speed up the responses?
The client/server RPC runs on websockets. More info: https://anvil.works/doc#runtime_details
Happy to answer more questions - check out our forums: https://anvil.works/forum
Anvil provides a toolbox of help you can take or leave, all driven by a real industrial-strength programming language (Python). And if all else fails, you can always drop down to the HTML and Javascript, and/or a REST API.
frontend : VueJS
Since then, everybody has gone heavily into various javascript stacks, and the norm has become to deal with 20 different packages to build (somewhat) the same thing. And the first hour will easily be spent researching different dependencies, trying to get them all to work how you'd want etc.
It's easy to see this as a horrible backwards progression, but the reality might be a bit nuanced.
The easiest way to get a basic crud app up and running these days is probably still some sort of rails/django stack. But today's requirements in terms of UX / dynamism (is that a word?) require you to end up building things differently, so even if you get up and running fast with a rails app, you'd end up having to build up a pretty hefty JS stack in the end, so you'd basically be delaying the inevitable.
So the answer really depends on what level of "good enough" you're going for.
I'm starting to wonder to what degree this is actually true.
Most people I know, all along the spectrum of 'computer literacy', complain about the slowness and brokenness of many sites and web apps. On the other hand I've never heard anyone complain about a lack of 'dynamism'.
To be clear, some degree of interactivity is often useful. But I can't help but feel that it's quite often not at all necessary to move things like routing, validation, and (almost) complete page changes to the client side, at least not as long as it increases complexity to such a degree.
Secondly I’d argue that if “dynamicism” matters, choosing rails or Django doesn’t hinder that ability as a lot of that is simply presentation layer concerns.
These days it's never worth it to home roll in the CRUD world. There's way too much good tooling out there.
After 5 years there is a better chance you can make changes to a pure language coded app, than try and get what ever stack was common at that time working.
Basically, it could be the difference between throwing away your app and rewriting it.
Doesn't seem like a problem for languages with sane package management solutions, of which there are plenty. A Java app on Maven is going to work just fine in 5 years, and on the latest version of java to boot.