Are you able to talk a bit about your server-side Javascript setup? What was your decision making process for using something other than Node? How does the ecosystem of libraries and supporting infrastructure look like?
It's not something that I chose in particular. I work at a Salesforce Commerce Cloud[0] partner, with half a dozen clients. The language syntax is Javascript (in fact, I'm sure that it's built on the JVM's JS engine), but uses a proprietary API. The platform is laser focused on doing scaleable e-commerce, although it has somewhat competent CMS and CDN functionality, at least enough as necessary to load pages fast and sell things. Once you start doing things like newsletter list management, file uploads, and even product reviews, its less than optimal.
If you haven't heard of it, check out https://vapor.codes. It's an absolutely amazing framework that is non-blocking in version 3. The performance you can squeeze out of it is unbelievable.
That site has some serious problems on my OS X Sierra/Chrome. Every time I load the tab it just freezes the whole browser. Great advert for all the claims they're making.
It depends on what you mean by a website. If it's one level above a static page, a static site with frequent changes, I'll make my own build chain in Node.js with Gulp and host the pages in S3 and Cloudfront.
Or I will use Rails behind Nginx if the site is more dynamic. Each release would get built into a Docker image and be deployed that way. HAProxy would be there mostly to forward requests to multiple apps if there are any.
For a site that needs a lot of client side scripting, I use Ember. I'm so happy with it that I will probably use it with Fastboot for those times I would have used Rails. In terms of databases, I've been using CouchDB unless I had an overwhelming need for relational records. It saves time because CRUD and websocket/eventsource/longpolling come with it out of the box.
I don't think it's that important what technology you decide to learn first, largely because learning new languages / tech stacks gets easier as your frame of reference grows.
What I think is important is sticking to one thing until you have a good grasp of it.
If I were you I'd want to really good with plain Python (or Node) before learning a framework, but that's because I'm the kind of person who wants to know how everything works. Once you've written a few CRUD apps you'll wish there was a tool to do some of the common stuff for you, and Django will be waiting for you.
But, if you're not that kind of person it's perfectly OK to jump straight into Django. You'll certainly get further more quickly, even if you won't be able to explain exactly what your code is doing.
47 comments
[ 4.1 ms ] story [ 110 ms ] threadI use libsass with bourbon.io and I have a Makefile to compile the binary, generate the css, minify things.
For blogging, I have used Wordpress
But I have recently started looking on moving over to Hugo to generate html using a bootstrap 4 template.
For fun, Java servlets/JSPs
[0] https://www.demandware.com/
If you haven't heard of it, check out https://vapor.codes. It's an absolutely amazing framework that is non-blocking in version 3. The performance you can squeeze out of it is unbelievable.
Experimenting with Laravel/Lumen API only for backend, and NuxtJS with SSR.
Also AdonisJS is looking promising to go into that JS world with both front and back ends.
for experimenting: golang + react (want to see what the fuss is all about)
for fun: elixir + pheonix (since I never got on the rails bandwagon)
For a quick prototype, I'd use Vue.js and Spectre for CSS. I suck at frontend anyway.
Deployed behind nginx.
Or I will use Rails behind Nginx if the site is more dynamic. Each release would get built into a Docker image and be deployed that way. HAProxy would be there mostly to forward requests to multiple apps if there are any.
For a site that needs a lot of client side scripting, I use Ember. I'm so happy with it that I will probably use it with Fastboot for those times I would have used Rails. In terms of databases, I've been using CouchDB unless I had an overwhelming need for relational records. It saves time because CRUD and websocket/eventsource/longpolling come with it out of the box.
Jekyll hosted with Netlify for static sites.
Ha. Of course it is!
We are really pleased with the performance of BEAM and the functional flavor of elixir clearly leads to code that is easier do read and to test.
We have been toying with Elm lately.
For dynamic apps that don't fit the Django model, I'll bust out Node.js, and for static sites, just a plain Python script to generate HTML files.
Boring choices, but the older I get, the more I'm OK with that :)
What I think is important is sticking to one thing until you have a good grasp of it.
But, if you're not that kind of person it's perfectly OK to jump straight into Django. You'll certainly get further more quickly, even if you won't be able to explain exactly what your code is doing.
Web apps: ReactJS on s3 hitting NodeJS API on AWS EB.
For my personal site, I rebuild it in whatever language I'm trying to learn. In this case, I'm rewriting part of it in golang which I use at work.
Jekyll if it doesn't need to by dynamic.
This is a great solution for general-purpose use, dropping React of course if there’s no need for interactivity.
Otherwise Rails with PostgreSQL.