Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: What's your favorite way of getting a web app up quickly in 2018?
542 points by westoncb on June 3, 2018 | hide | past | favorite | 558 comments
I am still frustrated with the amount of incidental complexity required whenever I want to do this. My latest attempt was to use a Digital Ocean droplet with Django pre-installed. I guess the biggest issue there was setting up something so that I could easily deploy my local version to the droplet (ended up using git/Github), and ensuring those two environments were in sync. I looked into Docker in some detail about a year ago, and I think it's the only pretty good solution for this I've come across—but there's a steep up front cost in learning/setup etc. (or so it seems).

What services and technologies do you use when you'd like to quickly build a web app which may never be more than a prototype, but may also turn into something real? A big aspect of what I'm wondering is about automatically setting something up for keeping local/production environments in sync, quickly deploying to production, and not having to mess with a bunch of server configuration things, user accounts, security, etc.




Vanilla php + html5up + sqlite3.

Everyone else here is trying to be stylish and fancy.

Your customers don't care what language it's in or whether the code is beautiful.

No cutting edge incomplete frameworks, convoluted tooling, piles of inaccurate documentation to read, inexplicable cryptic error messages with a bunch of incorrect solutions on stack overflow, or other incompetently over engineered bullshit.

Just go as vanilla, basic, and standard as possible.

True speed comes when you don't have to deal with other people's bugs and poorly designed mistakes.

Don't rely on code written by flocks of people you'd never hire in a million years.


>No cutting edge incomplete frameworks

So what, you rewrite a templating engine every time you want to make an application that outputs user data? Or are you reliant on making damn sure you always call htmlentities every time you echo something to prevent XSS? Are you sure you've not slipped up anywhere?

What about CSRF? Do you write your own filtering mechanism every time you make a web app to check for the existence of a CSRF token in all state-altering (e.g. POST) requests?

There are reasons people use frameworks. Security is one of them - I _love_ assessing apps which are written in plain PHP because they're almost always a trainwreck. You don't tend to see SQLi from devs who tend to use ORMs, nor do normally you see stuff like LFI if they're using a well-known templating engine.

Can you write secure code in PHP? Absolutely. But it's more effort and easier to get wrong.

Your client may not care about the technical details, but when the security assessment report says your PHP app has a stored XSS and an equivalent ASP.NET MVC app is safe..


The other side of the coin is whether you do a full security audit of every framework and dependency graph before you use it? When you write your own code you know there is nothing hidden.


That's a highly simplistic and incorrect way of looking at it. Do you know what CSRF is? Do you want to implement it every time you create a website? And all the other XSS vulnerabilities that could occur because you weren't careful.

Frameworks are much better at handling most security needs.


Most of the higher level code like that is written by incompetent people who make amateur hour mistakes and only release overengineered under documented slow broken code that is never supported and gets deprecated in a week.

I'm constantly shocked and amazed at the beginner mistakes riddled throughout these hip cool kid frameworks. And the dependencies of that code, and their dependencies, and the build system, and the management of the build system. It's a 5,000 hour a week job fixing all that and someone else will just go in and break it again.

So no, don't tell me to stop my life and fix everyone's mistakes. This is why there's 10 person teams to build an ecommerce site these days. This used to be a weekend project before all these slick stylish tools took up everyone's time.

Most people are incompetent and the more complexity you have, the greater your chances of getting crap code tearing your system apart

Why would I use something as a core piece of infrastructure written by people I'd never even consider hiring in a million years?

All too often you're standing on the shoulders of people tripping over their own shoelaces.

No thank you.


>>There are reasons people use frameworks. Security is one of them - I _love_ assessing apps which are written in plain PHP because they're almost always a trainwreck.

It’s totally OK for a prototype to be a trainwreck because its purpose is to give you the ability to launch it in front of potential users, show them a few features and get their feedback.


If it is open to the public, your train wreck cannot be open to common vulnerabilities like sql injection. Full stop. You can avoid unit or integration tests, not complete features, or cut any corner you want aside from basic security.


Don't presume anyone writing PHP is a trainwreck. With PHP7+ you can write modern applications that are perfectly secure, as much as anything you'd write with any other scripting language.


> Don't presume anyone writing PHP is a trainwreck.

I'm unsure anyone here is disputing this - my original comment said as much:

> Can you write secure code in PHP? Absolutely. But it's more effort and easier to get wrong.

It's undeniably more work to get right, though. As an example, if I create a new django app "the CSRF middleware is activated by default in the MIDDLEWARE setting" - you're safe by default.

I mean, even as a basic DiD measure PHP could use SameSite cookies by default for its sessions - but does it?


Sure it can. Almost every website on the internet right now has undiscovered security holes. Obviously you won't be leaving them open on purpose, but not using a framework is a legit choice and "it provides security that you can't implement without one" is a bad argument.

Yes there's convenience in "somebody already thought about everything you need before you did" but there are also security libraries, checklists, tutorials, and other tools besides a full framework with all its baggage to help developers write secure code.


I'm not saying anything either way on frameworks. But SQL injection is into to web development stuff. You can worry about cross site scripting or other security stuff later for a PoC,but not SQL injection.


This comment is highly presumptuous about the actual development experience of more modern languages and tools.

> True speed comes when you don't have to deal with other people's bugs and poorly designed mistakes.

PHP is often, in practice, a language where bugs are more likely compared to these "stylish" other languages you mention. [0]

[0] http://delivery.acm.org/10.1145/3130000/3126905/p91-ray.pdf?...

" For [languages] with positive coefficients we can expect that the language is associated with a greater number of defect fixes. These languages include C, C++, Objective-C, Php, and Python. The languages Clojure, Haskell, Ruby, and Scala, all have negative coefficients implying that these languages are less likely than average to result in defect fixing commits."


It's too late for me to edit my comment, but here is the proper link:

http://dx.doi.org/10.1145/3126905


I wonder why Ruby ended up in the negative coefficient group instead of exhibiting similar characteristics to Python, for example.


It's quite an interesting study to read, and not long. I recommend giving it a few minutes to answer that question.


Thanks, assumed it would be too academic or technical to understand and didn’t look at it. Will check now..

Actually, the link is not working on mobile. Maybe it will work on my desktop.


Try this permalink instead: http://dx.doi.org/10.1145/3126905


I wish they included Haskell in the concurrency bugs section, given how popular Software Transactional Memory – which eliminates many concurrency bugs – is there.


Thank you. I've never come across html5up [1] before, but the templates there are just what I'm after at the moment.

1. https://html5up.net/


I don't get it. They all look practically the same, just with different color schemes and splash backgrounds?


Agreed, this is a great resource. Is there anything else like this out there?


You seem to know a lot about what everyone else's motives are :)

There's nothing less "vanilla" or "standard" with python/go/RoR/whatever vs. PHP. It just so happens that you know PHP well, so, by all means, YOU should use that.


One can put together a set of (Fast)CGI scripts in almost any language, given environment variables and some IPC is supported (IDK what IPC FastCGI uses exactly, bug CGI is envvars). Same goes with exposing a custom socket server. I guess people associate languages with frameworks and that's why they think these things are not possible in them. Or they like the <?php ?> style intermingling of 4 programming languages, which is a pathetic bad practice that turns the program into a pseudo-quine immediately. Just read the source of a WordPress plugin (keep a nylon bag handy because it's gonna give you nausea, to say the least).


As someone in a position who's primary job has [had] little to do with WordPress plugin work, but is at the same time increasingly exposed to that due to sales department directives...

you've understated it.

And while I'm not a huge fan of working in PHP, it has its place— my remark is unrelated to that.


Except OP made no mention of Wordpress, its notoriously bad and any decent developer who also happens to use PHP knows not to touch it with a ten foot pole.


You're wrong. This is a case where whatever you're comfortable with is the best solution. Just because you personally don't know frameworks, or js frontends, doesn't mean the people who do are inferior or less secure.

I guarantee someone who knows how to work a framework can turn out the same work much more quickly and more maintainable than someone who is working from Vanilla PHP and having to implement basic logins and email templates on their own. And a "throwaway project" can also be turned into something customer facing much more quickly as well.

I agree, you don't need to pick bleeding edge tech, but you should pick something stable and well documented and run with it rather than basically having to rewrite the same project in the framework once you've got it up and running in vanilla PHP.


Please correct me if I am wrong, but as far as I remember the combination of PHP and sqlite fails fairly quickly when if comes to concurrent users?

Don't get me wrong, I am very fond of sqlite, but to use it efficiently you have to manage the connections to the database and from what I have heard, that doesn't work particularly well with PHP.

This doesn't mean that the above recommendation is wrong (in fact, I used similar approaches in the past), I just thought that it should be mentioned and if someone wants to build something that has a lot of concurrent users by design, he knows which part will be the first bottle neck.


Sqlite's limitations have nothing to do with PHP. But you're correct that it's not intended for use as a multi user database. The limitation is in concurrent writes. If your app is read-oriented, then there is not a problem.

However, I'd personally always use postgres in this case, myself.


>Your customers don't care what language it's in or whether the code is beautiful.

Yes, but the person who has to code it cares. No reason to choose the worst of widely used programming languages and the worst possible database for asynchronous read/write patterns inherent to web apps, except as an exercise in masochism.


>the worst of widely used programming languages

Oh, you mean javascript?


:eyeroll:


This might be true if you're creating a very simple web site that is never meant to be a real app. If you're creating a more complex web app, with authentication, user management, billing, admin pages, etc. you are better off with frameworks such as Laravel, Symphony or Slim if you are using PHP.


This is correct.

...it is also why php is not really any significantly better choice than any other framework/language combination.

The benefits of ‘plain php’ (simplicity) disappear quite quickly when you’re doing anything non trivial.

I would never choose php without one of those framework stacks; it doesn’t scale, its prone to hideous security issues and its a fugly mess of reinventing the wheel.

Frankly, anyone doing this these days has no idea what they’re doing.


Let's be frank. This is a place for marketing the newest thing where skepticism and scrutiny is not welcome and likely to be dismissed as 'grey beards' and 'people scared of change'.

So there is never any scrutiny, no experienced person is going to expose themselves to ridicule so all the problems are discovered years later only for a new one to take its place.

Ruby for instance has huge deployment problems, why the hell do you need a build environment on deployment and expose end users to installing hundreds of gems that may need to be compiled and can fail anytime? Same with the wild lands of NPM. It's as if people have endless time to go down all the rabbit holes.

On the other hand Facebook, Wikipedia, Wordpress, Slack and some of the most scalable sites online today use PHP. Yet according to the the hivemind PHP is somehow a disaster, and the next over-engineered complexity is the panacea. This is just not credible.

Unless there can be a way to apply scrutiny during the hype phase the cycle of over-engineering, needless complexity and offloading bad engineering on end users is going to continue.


Since you listed PHP - take a lot at Laravel (https://laravel.com/)

Like Rails, you can get a a site/app up in minutes. .


Symfony 4 can be spun up as fast as Laravel 5 and (this is my opinion) Symfony has all the benefits of Laravel with a better ORM (if you want it) and they have never broken backwards compatability in my experience.

Throw in the utterly fantastic documentation (that is both more detailed, thorough and better organised) and I'm not sure why Laravel took off the way it did.

I used Laravel for 3 years at a previous job (from 3 to 4 to 5) and I still think Symfony is the better basis for anything that isn't a relatively small application.

Also Symfony components are genuinely de-coupled, documented on how to use them stand alone and useful for that (I gradually brought them in on an inherited project with few issues).


I have a huge complex behemoth of an application which is written in CodeIgniter 3 with a whole bunch of changes that I have made over the years to the core. To call it CI 3 is a bit of an understatement.

I hadn't upgraded sooner because it had worked, but then due to issues with my stack. I decided recently to start from scratch and upgrade my toolset as well.

So I was deciding to either go symfony or laravel. Laravel won by a huge margin. From the perspective of a newbie. Even though I have 10+ years developing in PHP, I like to debase myself and approach with no baggage.

Laravel has so many more tutorials than Symfony 4 on Youtube. I wanted to learn and very very fast. So going through videos in 2x speed and getting the gist of how things worked was great.

Continuing on, there were many tutorials which had actually built apps using Laravel 5.5/5.6. So I was able to quickly get up to speed using Validation, Eloquent, Passport, Middlewares, Query Builder, etc.

On the documentation side. It's very easy to use and describes simply how to get things done.

Next was that Laravel had VueJS integration. So out of the box, I could have an SPA and use Laravel effectively as an API. Of course, right now I am one developer so 1 codebase is fine. But later on, if I need to split and have two codebases (VueJS front-end, Laravel API), then I can do that.

With Laravel I've gone from writing straight SQL to using the ORM. Which surprisingly for me, reduced my codebase by a significant margin and surface area for bugs.

I have found that there are a lot of Laravel composer packages compared to what I was using before and again makes my life so much easier.

Finally, there is a bit of synergy between Vue and Laravel. For example, I'm able to post a form with Vue using Vee-Validate for the validation. Then get laravel to post back any errors for Vee-Validate to consume. In jQuery and using my old codebase. I had to jump through hoops to get it done and much more code.

I will also say, that I had actually decided to go with Symfony in the beginning. The main reason was that Symfony was more pure and I have developer friends who recommended it as the way forward.

> and I'm not sure why Laravel took off the way it did.

It took off because with Symfony, try as I might. I just couldnt get on with it. It wasn't as pleasant experience with Laravel and honestly. Even if I persisted. The time that I took to go from zero, to duplicating my own stack was a few weeks.

I don't think I could have done that with Symfony. Yes, I could probably achieve the same result with Symfony. But not in the same amount of time.

As still a new laravel developer. I want to be able to deploy new features very fast. I can do this now.


Fair enough, it founds like you found a good fit for your use case (and that's a good thing).

In a year or two when you have a bit of time it might be worth going back and having a look at Symfony anyway, you'll likely find that going from Laravel to Symfony will make more sense than CI to Symfony (underneath Laravel uses a fair few symfony things).


PHP is like the Javascript of backend. Hate it all you want but there is nothing better to get shit done esp if you're a small team or working solo.

Also it is super flexible too (much like JavaScript and babel) as in you can write strict OOP code or you can write plain php code inside Html in static files.


The first paragraph is plain wrong. JS is the JS of frontend because there are no replacements. Use a language compiled to it, but still you'll have to know and use JS. PHP on the other hand is a caricature of a language that you can avoid.

The second paragraph is correct, but it's just equally correct for Python, Ruby, Perl, Lisp, Shell languages etc., as they all support multiline strings and string interpolation too. The only difference is that you'll have to wrap strings in delimiting markers, instead of code with <? ?>.


Agreed. I've worked with PHP for years. It's not my choice unless it's a requirement. There are plenty of other more durable and scalable languages for the backend (as you've listed) that are just as easy and quick to get going if not more so.


Isn't NodeJS the Javascript of backend?


+1 for NodeJS, seriously no offence to PHP folks, but Nodejs or Python is not much different from PHP in terms of developer productivity.


The reference implementation of PHP, Zend, is objectively not good (blocking I/O) and encourages server side templating, which is basically something you can perfectly do in the client and serve on a CDN at much lower cost (orders of magnitude lower, for processing, memory and transfer).

That being said, doing server side templating in node.js is even worse since it usually wrecks the entire event loop with long lived CPU-bound operations flushing your server performance doing the toilet.


What exactly is the benefit of using sqlite over mysql in this case?

Is the 10-15 minutes you might save looking up a quick setup tutorial for the system provided packages really worth the later problems? Postgres is slightly more complex (but pays for itself with additional capabilities), so I can see avoiding that unless your are already familiar with it.

As for PHP, at this point it's not really any easier or harder to get up initially then Python, Ruby or Perl, so it really comes down to personal experience. Whichever one you know best, use it. Whichever framework you know best that has some solutions for what you want to do, use it. That will be quickest.


I don't run a MySQL server on my personal computer. I don't want to run one. If I want to start writing code right away to flesh out an idea, SQLite is the tool I can use, it enables me to develop locally with no SSH/FTP overhead or setting up a VM. It lets me start writing code instantly. And it's performant enough for most any MVP, and the SQL dialect is pretty standard so you can upgrade to Postgres or SQLAnywhere or whatever you please when the time comes.


What I hear you saying is:

1. You don't necessarily want to develop in the same environment you deploy to.

2. You don't want to install some things on your development machine.

Together, those are dictating some development directions for you. That's fine. Those are perfectly valid choices. But I think it's easily summed up in your case as "You use sqlite because it fits well with your current development pipeline."

On the flip side, I do development on remote servers using vim. For me, sqlite provides little-to-no additional benefits, since MySQL or Postgres are a package install away (if not already installed), and that's a small price to pay for their additional benefits (for example, a much richer set of data types). At the same time, this type of development pipeline makes certain types of development harder (there's lots of tools for vim/emacs, but some things graphical IDEs provide are harder to achieve).

There is a middle ground, which is emulating the target environment through a VM on the development machine. It should provide the best of both worlds, for a cost of a little most complexity. I've never really gone for that, as I'm happy with the remote dev setup I have, and it's easier not to have to devote local resources to that for me. It's a popular choice as I understand it though.


I think you should be able to understand that sqlite's "the database is a file, ONE file" is superior to getting a fully configured and setup mysql up and running in speed, ease, and simplicity. Of course, it presents limits in terms of scalability (however because it is linked into the application rather than using TCP, if you want to do 400 sql queries per page view sqlite will be MUCH faster than mysql or postgres is going to be)

And in fact Sqlite is linked with the application, so it presents a development environment much more consistent with production (if that's also using sqlite of course) than any mysql or postgres ever will.


> What exactly is the benefit of using sqlite over mysql in this case?

I'll just let you read this: https://www.sqlite.org/whentouse.html


I usually go for Postgres, but I suppose one advantage is that backing up involves the filesystem rather than figuring out how to do a db dump. Not entirely sure if it's that simple though.


And plus, it works on cheap shared websites that can cost $10 a year + domain name.


Isn't the "PHP works on cheap hosting" schtick a bit dated now you can get a dual-cpu VPS with 8GB RAM at hetzner.com for 8.90 Euros per month? Commodity hosting now makes JVM apps feasible at the lowest price points.


8.90 EUR per month is about $130 a year, so still an order of magnitude more expensive than cheap PHP hosting.


I was just going for a figure similar to the $10/month cited. You can get a 2GB RAM VPS at Hetzner for as little as 2.50 Euros per month.


The cited price was $10/year, not $10/month. That's a huge difference.


Ok, so yesterday's shared hosting prices are today's VPS rates. The point is they've both become commoditised so the PHP/cheap hosting argument is no longer valid.


So instead of admitting mistake you insist that 10x higher prices are somehow invalid argument. You have convinced me!


Just wait until you see cloud pricing ! That is far "superior" (you know, bigger numbers) than either of the quoted prices.


s/php/python and flask or django, depending on the project/ and i agree with the whole comment!


And it makes more sense as OP mentioned Django, not PHP.


Ok. But that does not mean that you have to use the worst thing that is out there.

Why not Python?


it's worse to you, not the client. client actuality doesn't care and PHP is legacy I guess?


Actually they do if they have to maintain it or want hire really good developers to maintain it. Not saying PHP doesn't meet those criteria, it might in a given region or situation, but just saying your dismissal of this consideration is way off base. Good luck hiring anyone passionate about good software development or recently graduating from decent CS department to work on your PHP apps. I'm sure you are a great developer with a real passion for your craft but you do realize that plus PHP makes you a very uncommon find, right?


"plus PHP makes you a very uncommon find, right"

What? Half the programmers I know in NYC write PHP. The other half write a combo of Java/C#/Python. These aren't programmers working for startups - they are working for companies and the government.

PHP is used everywhere. Except maybe in SFO (and surrounding area).

I mean look at the job listings for NYC, DC, Miami, Baltimore, Louisville, etc, etc.

Look I know this board is focused on Silicon Valley, but it's a big world out there.


Calling out the regional dimension to the popularity of PHP is totally valid. I think the thing I'm really reacting to is people repeatedly saying "the client doesn't care" which I vehemently disagree with.


Some clients care. But many don't. They just want something to work.

And even if they did what is wrong about choosing PHP?


If the client does not not care, why suffer by using something that is worse for you? I mean, you might as well use something that you like.

I don't get the logic here.

Another thing is that, if it it worse for you, it is automatically worse for the client. I am not sure why it is so hard to see. if your tool is bad, then your work ll suffer, and thus the client. So it is worse for them also..


liking php is unfathomable


In many areas of the US (the entire west coast for example), PHP is dead - plain and simple. Independent of whether it is good or not, selecting dead or obscure technologies for your clients is completely irresponsible and leaves them with a maintenance catastrophe just because you like php. Yes there is a lot of hipster-ism out there in platform choice but there are plenty of mature, fast, and popular options out there. PHP is not one of them.


PHP is not mature or fast or popular? And PHP is very far from dead no matter where you are. In fact is getting a lot more interest now since PHP 7.

If you don't like PHP that's one thing but what you said is just wrong.


PHP isn't dead, and it will never be dead, but as a long time and continuing professional Perl developer myself, let me tell you that you're better off just accepting that your language of choice isn't in vogue anymore.

It's not all bad once you're on the ass-end of history. I'm sure you can easily identify a few negatives being the language de jour bring (such as lots of shitty programmers joining the community all the time). Welcome to middle-age. ;)


Perl 5 is pulling me like a superstrong magnet. I haven't had time to read the basics and things like choosing the correct sigil + accessor trim me up, but still, it has many niceties. To begin with, you can have a statement "use v5.x;" and be done with which interpreter problem: it can tell you it needs sth. different, and does not fail because you have python3 to be 3.x, but the script needs 3.x+y, or you have the shebang as python3.x but the system has 3.x+y which is compatible, but you can only have one full path in the shebang... Then the context variable $_ is just lovely. The availability of mature libraries for everything is a trait Perl shares with a small number of languages. Its integration to Unix and its expressivity are second to none. The documentation, while not as accessible as Emacs', is available on you computer offline in man pages, and perldoc can give you proper docs on functions (unlike crappy help() in Python which never shows you anything useful and you have to go to the docs, usually online), add to that POD being a very nice way to add documentation to your scripts and also view them (if its in the path you can "perldoc <script>" and get help. And once you know your way around perl* man pages, you can just program independently, with little or no need to go online for Perl stuff. All niceties other languages/communities could've had, but just don't, because, well IDK why.

I'm a 25yo, so when I started programming Perl hatred was the hot thing already. Well, luckily as a curious person I discovered its just baseless cargo cult. Perl is one of the best tools to have in your toolbox.


Well said!


PHP is not dead - plain and simple. Independent of whether it is good or not, selecting technologies based on your biases for your client is completely irresponsible. There are plenty of mature, fast and popular options out there. PHP is one of them.


denial!


There are many successful companies and start ups that use PHP. The same way they exist for other languages and platforms.

No start up became a unicorn because of the programming language they used.


With the possible exception of Clojure :). See Paul Graham on Lisp as the secret weapon.


What's the biggest Clojure start-up at the moment? Is it CircleCI?

Wal-Mart is pretty big into Clojure these days, but they were already huge.


Here in London there's Funding Circle and uSwitch. The Daily Mail (MailOnline) also uses quite a lot of Clojure.


Whatsapp.


whats whatsapp built on?


Erlang and FreeBSD


This is just bs. PHP is thriving everywhere expect Silicon Valley.


Even there, aren’t Facebook and Etsy using it, at least?


And WordPress, Yahoo, Salesforce, Adobe, eBay and on and on. You'll have a hard time finding any tech company that doesn't use it to some extent.


And Wikipedia


And slack


I don't know which planet you're living on but all you need to do is search Indeed.com for title:php and you'll find PHP is up there with Java, C# and Javascript in terms of the number of jobs. In some countries Java, JS and PHP are the only languages used in any significant numbers. Likewise in more technologically advanced countries once you get away from the tech hubs. I'm not a fan of PHP and I wish it was true but dead it certainly ain't.


For some reason people seem to constant doubt Ruby-ists and Rails Devs.

I completely get that other languages have huge benefits over Ruby. Golang being compiled or Java running anywhere, etc... And ruby is slow, totally understood.

But if youre talking about getting a functioning webapp up and running quickly... no way anyone is beating a Rails dev in setting one up. The piping and scaffolding are all built in and the gem ecosystem (for web apps specifically) is so well maintained and robust that you can drop it in to your app and get a functioning product with ease.

I know that's a loaded statement bc Rails becomes not so great in other cases like building speedy backend jobs. But for a small user-facing web app it's hands down the best.


I’d say the slowness of Ruby is really over exaggerated. For most web applications it’s good enough, and the speed of development (how fast you can ship) almost always outweighs any costs from it being slow.

You can always replace the endpoints that are slow with something written in a more performant language like Golang or Erlang later.

I’ve worked on all sorts of applications from corporate CRUD to mobile billing gateways written in Ruby (usually Rails), and in very few cases has Ruby itself been the bottleneck.


There are some properly large companies like github and shopify that run a large rails stack, it seems to work out pretty well for them. At my current workplace we have some streaming servers pushing about 15 gigabyte/second at peak load and the ruby processes easily saturate the available bandwidth on the EC2 instances. Like you say, the slowness of Ruby is greatly exaggerated. Sure we could rewrite the whole thing in Go/C++/Rust/etc, but it would not work any better and the gain of using 10% CPU instead of 20 is not really relevant since it's the NIC that is the bottleneck.


I second that resources consumption with Rails on the production system is only a problem in specific settings (e.g. when your business model depends on many cheap transactions, or when you are running on diverse sets of hosts outside of your control… I'm looking at you, GitLab).

Nonetheless, as a junior Rails developer coming into a 5 people team on a mid-sized project, I saw a diverse set of performance problems during the development phase. E.g. asset pipelines that take ages to compile so that rapid development cycles become impossible or a test suite that took heroic efforts to get down to 15 minutes despite not really doing much computationally-wise. I'm open to alternative interpretations, but I've got the impression that in more performance oriented frameworks the best practice would not turn out to be setting up and tearing down half your server stack before and after each controller test, but instead we would have chosen abstractions that can be plugged together more efficiently.


I think the rise of Mastodon is really pouring some hot water on that meme. Lots of really small VPSs are running some fairly big instances. Although I'm only personally using one of them, it's very fast, and the general view is that isn't unusual.

I get that it won't hit Twitter scale but that matches the majority of "how do I build a prototype" use cases.


"Twitter scale" wasn't so much a Ruby/Rails problem as it was an RDBMS (write-many + read-many = road to fail) and writing their own in-house message queue problem. Starling performed worse than just about everything else out there (and their Scala replacement Kestrel isn't much better).

One really insipid blog post and thousands of mindless followers later and the damage to Rails has been done.

That's not to say Rails doesn't/didn't have other issues -- it did. It's just telling that Twitter is the first example people reach for instead of anything else.


Agreed. I've been working mostly in Ruby since 2006, over hundreds or thousands of apps, depending on how you count, and I have only worked on 2 apps that actually had scaling problems with Ruby. The rest were 100% improperly designed or scaled databases.

Twitter is certainly of a scale that I would not be using Ruby on the primary load points. But even billion dollar companies don't often reach that scale.


at twitter’s scale, its not jus ruby, you would also have problems with php, python, node, and maybe even java. only language that will work well at that point are languages built for concurrencies such as scala, elixir, and go.


Or you break out your infrastructure into smaller components and move the more demanding/critical parts of your infrastructure to that other language and keep everything else you've built!


iirc, the ruby 3x3 benchmark project is getting a ruby game (i think mario) to run at 60fps, and ruby 2.5 already hit that target.

even if it's slow today; the runtime is being improved regularly and making a lot of code just faster with a version bump.


> You can always replace the endpoints that are slow with something written in a more performant language like Golang or Erlang later.

Maybe in an API server. But this is nontrivial in a monolithic application where you end up yakshaving the whole middleware stack to parity just to replace an endpoint.


Totally agree. Rails is really powerful; it not only gets you up and running fast, but it can carry you very far. Like, years and years. And for a lot of places (like github, hulu) they seem to manage fine with it as their stack.

> Rails becomes not so great in other cases like building speedy backend jobs

Rails is still pretttty good for this. I mean, gosh; maybe not a game engine or something like THAT - but for much of what is done on the web rails can be optimized to complete requests in ~25ms.

> But for a small user-facing web app

"small" as in 95% of websites out there that aren't facebook/google. I mean, shopify handles 80,000/req/sec on a rails stack and they are the backbone of a lot of small (and not so small) e-commerce stores.


I started building a SaaS in Java/Spring and months in realised Ruby/Rails would have been stunningly faster to get the same result. The full write-up is here for reference http://tayler.io/5-lessons-learned-as-an-indie-hacker/


Your site completely refuses to load with noscript.

Are you sure the complexity needed for it warrants this?


> no way anyone is beating a Rails dev in setting one up

I disagree. Elixir/Phoenix is as simple as Ruby/Rails and an order of magnitude more performant out of the box. Especially if you already know Ruby and the basics of functional programming. Plus, unlike Rails, you probably won't need separate servers for background jobs, websockets and caching.


Sorry to fact check here but on my Rails app I am getting 200ms return times. This is running a web application and a few hybrid mobile applications. Are you saying that basically out of the box with Elixir/Phoenix I would get 20ms return times? That would be amazing but I find that highly unlikely.


Yes, and likely faster.

http://www.akitaonrails.com/2015/10/27/how-fast-is-elixir-ph...


That’s quite interesting. I’m going to have to give this a try under real world condition. This gives a pretty good argument for massive improvement.


For my load balancer heartbeat checks, I'm returning responses in 200µs.


That’s a highly unrealistic real world scenario. I’d like to see a page under load with actual queries. Heartbeat checks are far from actual real world examples of much of anything.


I guess my point was: that’s the baseline. It’s an order of magnitude faster the 20ms your saying is unlikely. That leaves a lot of headroom for hitting the db and things done. The api I’m working on isn’t currently being hit super hard, but for most of my endpoints 25ms is pretty average.


And if the next order of magnitude of performance is needed, there's always Crystal


But since it is much newer, the docs and examples are much thinner than Phoenix.

Plus, except for unoptimized database actions (which would equally affect Crystal), Phoenix responses are usually sub 200ms. Some are sub 1ms. So it really isn't in need of performance increase.

Ecto, however, is really not pleasant imo.


I looked into rails in some detail about a year ago, and I think it's the only pretty good solution for this I've come across—but there's a steep up front cost in learning/setup etc. (or so it seems).


It's best to pick a project and try to build it, rather than learn things from the outside. In isolation, Ruby can be annoying to learn because it's syntactic sugar seems unnecessary. In context of an app, though, it's great. The sugar makes sense.

Rails has a bit of a learning curve, but that learning curve is well rationalized. To borrow a Steve Jobs-ism: you're starting on the 10th floor, when everyone else is starting on the 2nd floor. Out of the box, you get a killer asset pipeline and complete MVC system that's standardized and conventional.

You can throw together a well built webapp without cutting corners in a fraction of the time doing it by hand. Things like a solid REST API practically come free with Rails. That's really valuable.


What are the best resources to learn Ruby/Rails these days?


https://www.railstutorial.org/book is quite good


This is what I used to jump from "I've hacked on a rails 3 app and gone through some ruby Katas" to "I am building out a full fledged SaaS product in a Rails 4 app as technical co-founder".

Highly recommended.


I, personally, just used the Rails docs, and watched DHH's introduction. The Rails guides are really good (the official guides, that is).


Pick up rails book from pragmatic bookshelf. Give it a quick read. Then watch railscast videos. Then to rails doc and gorails.


Another vote for Gorails. It's certainly the next step from beginner Rails dev to, well, not beginner.


The community is so big, and so focused on conventions over configurations, usually googling "rails <questions>" returns a LOT of links to stack overflows and blogs that clearly explains everything. Rails offer so much syntactic sugar/plug and play gem systems that usually things are setup in fewer lines of code than anywhere else.

The downside is that it's easy to build something while barely having any idea how it works, but if you want something up quickly (or if you already know how things work) then it's perfect.


Yeah, I never found Rails as easy to learn as others did. Maybe it’s because I was younger and less experienced than now.

Or maybe I’m dumb.


There is definitely a learning curve. For me, Rails was unapproachable until I started to give up the idea that I needed a ton of custom stuff in my stack. The "allure" I saw of pulling together a basic routing system and hooking things up by hand completely disappeared after building a pretty substantial web app in _Sinatra_.

Rails makes a lot of decisions for you, but the decisions it makes are the _right_ ones. It's like having a "best practices" box that you can just shove your custom system into, rather than trying to build them in yourself. It's really quite something.

For context: I basically learned Rails by way of building a proof of concept election management system in Rails in about three weeks (more like 1.5 in actual programming time). It also stored votes on a blockchain (ethereum). Even with a relatively complex storage system and interaction model, the Rails best practices left me with a really satisfactory application in no time flat. Perfect for a fast PoC.


Depending on how long ago, I've noticed that the comprehensiveness of third party documentation (i.e. googling "how do I x?") can really change the experience.

My memories of trying to install Linux circa 2000? Not favorable. Though to be fair I was a lot younger then too.


Laravel. It's PHP and (assuming you know Laravel) you can get a it up in minutes. It's development time is as fast as Rails.

I'm not taking any chips from Rails. Rails was the first and is still one of the best. Just pointing out that there are other frameworks that are designed to move to production fast.


If backend speed/scale is your concern I'd also throw a vote in for Phoenix. Lots of similar heritage to Rails but built on Elixir/Erlang instead.


Phoenix loses my vote for being quick to set up for a web application, because last time I used it, it didn't have a good authentication framework that worked with JSON APIs. What took ten minutes to set up using Devise in Rails took me two days using Coherence in Phoenix.

Unless that's changed since I last tried Phoenix, I'd be hesitant to use it in the same niche as Rails.


I'm a huge fan of Phoenix, in part because it addresses the main issue I had with Rails (too much magic).

But I do agree that losing the huge ecosystem of gems is a significant downside. Hopefully that'll change over time, because other than that, Phoenix really feels like the next iteration of Rails to me.


That's my biggest gripe with Phoenix--so much good stuff can't be used. I understand that sometimes moving on the next thing requires this, but man, it isn't just Rails that has tremendous value when creating a web app. The entire ecosystem has so much good "drop in"/"near drop in" functionality.


Guardian has worked great for us for JWT auth


Well, here's one reason: the amount of time saved when standing up a webapp on Rails is absolutely insignificant compared to the life of that webapp in all situations where that webapp is anything serious.

Not to say that Rails apps aren't serious! I'm just saying that the time saved in standing up a webapp with Rails vs., say, Java, is miniscule compared to the develooment life of that application, overall.

In short: you don't save any time at all, in the big picture, and now you have all the long-term disadvantages of Ruby.


Ah, that's an interesting perspective. Having written and supported websites in both Java and Ruby (plus some other languages), I think that your perspective is valid. Long term costs are worth considering. However, sometimes you can take a long term hit in order to deliver quickly.

> compared to the life of that webapp in all situations where that webapp is anything serious.

Actually there is a situation where the short term life of the webapp matters far more than the long term. That's when you are not sure if there is going to be a long term. This could be a startup, a spike to explore a new business model, or even just a prototype of an internal app.

In all those cases, delivering something that has value in a short time outweighs the value of something that might be more supportable/extensible in the long term.


You're absolutely right.

We should all over engineer our applications by picking the most complicated stack possible because the long term goal may slightly benefit the short term goal of you know.. actually making money out of our business.

Why pick a simple Rails + Postgres stack when you can setup Oracle + Java because you will require enterprise level scaling for your first 1-100k users

Oh and just for the record, I am sure you are already aware but Rails gets you very..very far. Github, Gitlab, Shopify, AirBnb, Basecamp, Groupon,.. I could go on.

My vote goes to rails.


That's like saying that php is a good choice because so many sites use it. Php is never a good choice. Neither is Rails.

Shower me with downvotes. IDGAF; Ruby is rubbish.


I entirely disagree with this.

Rails is optimised for fast development. That isn’t just about first bring-up, but about long-term velocity too. You will almost certainly save time over pretty much any other available solution, even over the long term.

Where Rails and Ruby fall down is going to be in performance and complexity. If your “simple” web app becomes a sprawling and complex mess, Rails won’t deal with that elegantly. And if you suddenly have to scale to millions of users, you might struggle.


Everytime I say anything on this orange website anymore it is immediately voted down.

I guess the orange website isn't for me anymore.


Well, your comment contained a bit of a generalisation. It may or may not be true depending on the size of the app, its purpose, the number of developers, their level of experience, and a bunch of other factors.

The response contained a generalisation too. Horses for courses.


I agree.

I'd describe my professional experience with Rails as: Rails optimizes for Day 1. Devise is a great example.

But I left Rails when I couldn't help but notice that it tends to break down over time without eternal vigilance. And even simple tasks required me to hold quite a bit of Rails trivia in my head.

These days I'm far less likely to give up simplicity so easily.


Assuming we’re talking about a startup, the expected lifetime of your product is ~0 and so is the number of customers. If you’re somehow lucky enough to ever have so many users that you have issues with rails, you will have the money (VC or otherwise) to deal with it.


The benefit of Golang isn't that it's compiled. It's that it has a good IO and concurrency model and the language is strict enough to force certain good practices on developers.

IMO it would be almost as good even if the code execution were as slow as Python or Ruby.


I hear this a lot about Go, but doesn't the webserver handle concurrency for you in most cases? I don't do a whole lot of explicit threading work when I write webservers in Java for example. Or is there something I'm missing that you use the Go primitives for in these cases?


I'm not as familiar with Java but It's more about concurrency than threads. I have more familiarity with Python, so using that as an example...

There are Tornado and asyncio libraries for Python that give you asynchronous networking. But you have to totally rework how you write Python code within those request handlers to factor out blocking IO which makes using existing libraries for DB and such a pain.

Go is built from the ground up to handle IO like that asynchronously so all of your libraries and stuff will just work in that context.

NodeJS is similar to Go in that regard, but the JS language has baggage that gives you weird blends of callback asynchronicity mixed with async/await and it generally just doesn't feel as nature as Go.

Sometimes a simple request/response model isn't enough. Maybe you need a streamed (chunked encoding) API or WebSockets where the performance for massive numbers of connections using threaded servers is going to tank quickly compared to a language like Go that handles the IO and concurrency better from the ground up.


On a side note, if someone asks me to prototype anything on Java world, will pick Grails. Getting a webpage up and running in Grails is so easy.


Which version of Grails was that? If you mean version 3, why is virtually no-one starting new projects in it, or upgraded from v.2 ? Grails 3 looks like nothing more than a wrapper around Spring Boot, so why not just use that? If you're talking about version 2, why has its plugin ecosystem died?


Are you aware that Flask exists for Python? I might take that bet about no one being able to go quicker than a Rails dev.


From the Ruby side Sinatra is just as fast as flask to get something going. Having supported all three ( Rails, flask, Sinatra ) if it's going to be an API. I usually start with Sinatra.


Agreed. Flask or Aiohttp + templating engine of choice + flask-login or aiohttp-security is extremely fast and simple.


Pyramid - https://trypyramid.com/ - lightweight like flask but with that little extra that makes life easier (authentication, sqlalchemy integration). Not as heavy/opinionated as django. In fact, would argue, not opinionated at all.. just the right balance.


You left out persistence, which is the most annoying bit of setting up a Flask project, imo.


You can literally start and publish a C# web app to azure in minutes if you wanted to. They have built in deploy from GitHub.

I usually rip a bunch of stuff out of their default app template and actually get the app doing something useful first before I deploy but it's really easy.


Agreed! I have a template built that allows me to spin up a basic web app with all my baseline common dependencies ready to go and a handful of little nice-to-haves in place and deploy to Heroku in well under an hour. I love Rails!


I keep on running into this problem where I try to use a new framework/language for backend, like Go, Kotlin, even Node, but I just get so damn bored with writing the same boilerplate. Say what you will about Rails, but at least the maintainers try to automate the boring parts. Not to mention between Elastic Beanstalk, Heroku and even plain old Capistrano on a VPS, deploying Rails is a breeze. Maybe some people take some perverse joy from writing CRUD operations for the millionth time, but I don't.


I’m curious: once one has written a CRUD app, why can’t they use that as the boilerplate for other CRUDs they need to write? Replace the bits specific to each individual app. If the program is designed in a sufficiently modular fashion, shouldn’t this be doable?


That assumes you're allowed to use the code you wrote in a previous project in your new project.


Eh, are you perhaps hinting at that horrible lawsuit where Oracle sued Google(?) for a lot of money for copying about 9(?) lines of code that was basically a looping routine?

That notwithstanding, I was asking about code that could be considered “boilerplate”, not things that could be considered proprietary business logic. So the code to do a login, or check for cookies, or get something from a db, or anything of that sort should be broadly reusable (for a general CRUD app).


Somewhere around 2006, after my first enthusiasm about Rails I realised I could get almost the same, with a language that is more natural for me, has more developers here, as well as cheap hosting options (less of a concern now) by going with php/symfony.

Later I've been enjoying

- a php microframework that slips my mind

- python/flask/sqlalchemy

- JavaEE (yup, except JSF)


It's hard for us to train new devs in Ruby and Rails. We've found Go to be superior in deployment + speed up on new developers.


Curious about specific difficulties with Rails?

And what web frameworks do you use with Go?


Quickly? Firebase + React.

Seriously, don’t overlook this combo. Auth just works. Hosting built in, no backend or database server to maintain. No API, just subscribe to a collection right from the view. It just works (and is easily swapped for the real deal if you need it).

I made a guide/boilerplate to show you how (includes auth, CRUD, full text search, stripe subscriptions):

http://getfirefly.org/


Too expensive to be worth it. I'm totally fine with outsourcing stuff that is difficult and third parties can do better, but in this case the amount of stuff you're playing egregious "cloud" pricing for is too much. Just spend a handful of days learning one of the open source stacks and you'll be set for life. It's totally worth it assuming you'll be making more than 1 app ever.


Firebase's free tier is more than enough to play with an idea, and the next tier up is (100k concurrent users) $25/month ... if that's too expensive then there's something very wrong with your pricing model. Obviously this assumes you're not storing much data per user - you wouldn't build a imgur clone with it - but it's not that expensive for any typical SaaS app.


Concurrent users are not the only limitation. Your app needs to fit the bandwith limits as well. I had to shutdown a very simple app with a few users because of ridiculous billing.


And it's actually way cheaper for small apps if you "upgrade" to the Blaze plan and do pay-as-you-go billing. I often pay between $0 and %0.05/mo...

Full pricing: https://firebase.google.com/pricing/


Guess it depends on what you consider expensive.

For me, time I’m writing unnecessary code or learning libraries I don’t already know is time I’m not spending thinking about the product. I’m a designer who just wants to ship.

I am open to suggestions though. What would you recommend for, say, auth instead? I’ve tried rails, Django, node/mongo, etc; even hosting a small db on compose.io comes with a chunky base fee, and I still have to do way too much work for user accounts/search/APIs/ORM. There’s a reason Firebase is popular with the yoof.

Change my mind though!


My startup is betting on parse server platform [0]. For us its the most of 2 worlds.

- huge community supporting a codebase initially private

- open source now so you can host it anywhere

- 3rd party online instances to quickly start [1][2]

[0][http://parseplatform.org/]

[1][https://sashido.io]

[2][https://back4app.com]

[3][https://https://www.nodechef.com/parse-server]


"Just spend a handful of days learning one of the open source stacks"

Sure, but which one? :)


Opensource alternative to firebase: couchdb . Less features but the essentials are there...


If you use couchdb+rxdb, you have the same subscribe-to-collection thing but without the google lock in


While firebase has an expensive first tier, Firestore bills more for what you use, like AWS does.


This.

Maybe I am biased because I develop most of my applications in React. But if you don't want to bother with any backend application and just want to get out quickly, build your React application with Firebase. That's how I do it and that's why I also covered my whole boilerplate process in a comprehensive tutorial [0].

- [0] https://www.robinwieruch.de/complete-firebase-authentication...


I still love the Meteor framework, even if it's not as popular these days. Auth "just works", The Mongo<->Server<->Client dataflow is super easy, and there's lots of tools to quickly and easily deploy it.

Now that React is supported, it's even easier for throwing together web apps.


I just dropped firebase after nearly a month of development. Firestore lacks so many features that i consider basic. For example you can't even do a count query on the db and have jump hoops to even achieve this simple feature.


I was gonna say the same thing. It’s cheap/nearly free if it’s just a little side project or low traffic thing. And a joy of a stack to work in.


yerp, by 2018, UI + SaaS backends is often the easiest way to get something deployed ... provided you want to deploy essentially the same thing other people already have + some customization ..

.. what's going to be neat to see is how that "essentially the same thing" changes over time.

deepstreamhub.com is another neat SaaS that's worth looking into for some cases that Firebase might not handle as well ... there are probably yet other SaaS products that cover other specifics and will be still more in the future..

.. obvious mention re. SaaS products is that they could evaporate at any time. warranty void where prohibited. all states except ... idk, AK, for some reason.


the hub product shutdown https://github.com/deepstreamIO/deepstream.io/issues/867


I'm having trouble building with this. Can you elaborate a little bit more about the steps after adding adding all three project. I can't understand this

>> " Now let's connect our databases to our app by adding their "keys" to our app's environment ("env") files. You should generally keep connection keys like this secret, so first we'll rename our environment files to keep them from getting committed into git (the new filenames are listed in .gitignore). "


My fault--I've re-added the sample env files, you can copy these, remove ".example" from the name, and add your keys:

https://github.com/sampl/firefly

Thanks for trying it out!


> Quickly? Firebase + React.

Came here to recommend this myself.

I built an SPA with React + Firebase (auth, db, hosting, and all) to help my wife and I track our kids allowance and spending in just over a day: https://parentbank.actridge.com/ (did I mention Firebase hosting allows HTTPS on custom domains?)

It's an awesome combo that is seriously under-utilized.


Good idea. Gonna look into this!


Just stripe subscription? Customers of my consultancy also require Bitcoin, Wire transfers and other payments. We use http://killbill.io/ now. It supports multi tenancy.


Full-stack Clojure with Clojurescript front-end is about the fastest workflow I’ve ever used. The front-end part in particular with Reagent (a Clojurescript React library) is a very quick workflow compared to all front-end alternatives. There are perhaps more valid options for server, but even still, having the same language in both browser and server is very convenient both for reduction in cognitive dissonance and automatic transfer of language-specific data structures back and forth.

Highly recommend.

I should add that on both server and in browser your code base will usually be a lot smaller than most other languages, which greatly speeds workflow as well. As an example I once ported an Elm project to Clojurescript and it was a 4x reduction in lines.

Using Heroku to just git push the project works well too. Deploys in seconds.

If your project becomes more, it all scales well. Clojure is quite fast compared to Ruby or Python, and Heroku scales with the click of a button. You won’t have to port to a more performant language or host if you suddenly get popular.


I've had the same experience. On the front-end, reagent is a joy to use. Haven't found a framework that feels more elegant/smooth than what reagent does with components and hiccup (maybe adding re-frame for state management).

There are some great choices for the server side too. Plus libraries for pretty much every DB. When something is missing, there's definitely a fallback option in Java.

Plus you get hot-reloading on both sides (e.g. boot-reload and ring-reload). And the ability to bundle everything into one neat jar file so the only dependency for deployment is Java.

Here's a getting started project that I found helpful: https://github.com/oakes/full-stack-boot-example


Although Clojure is my favourite language I find web development difficult with it due to auth for which Buddy is the standard. Buddy's integration with Luminus is opaque at best and the Buddy docs themselves I found unhelpful. You're left with the impression that Clojure web development is for experts who already understand how it all works. Total contrast with Rails where there are great resources for average developers and newcomers. I think this stems from the Clojure community's reluctance to embrace web frameworks.


Does Clojurescript support stuff like hot code reloading? And does Clojure have any good framework for an actor system implementation?

Because I've been interesting to get an excuse and try Clojure out and what you're saying is really interesting.


Clojure has its own very effective strategy for multi-threading, and it is not the actor model. The language is built for concurrency and much careful language design was tailor-made for the challenges on modern threaded applications. Rich Hickey investigated the actor model considerably, and decided on a different model. In the core language, you have the choice of using its normal futures/threads with highly efficient and lock-free data structures, or using core.async, which is a model like Go channels. The latter is particularly popular in the community and generally the recommended approach.

Clojurescript offered the first and still (in my opinion) best option for hot reloading via "figwheel" which nearly all Clojurescript developers use. It automatically updates the UI as you code it.

Clojure, on the server, being a proper lisp with a real REPL, lets you poke and inspect and reload parts of the running program with no recompile cycle. A typical workflow there is to reload individual expressions or functions in the context of the running program to alter behavior as you develop.


Yeah, that's nice for multi-threading but it does not seem as good for distributed systems. This is why I still don't know if I should invest in Clojure or Elixir.

Can the REPL on the server be used to update production systems with no downtime?


Yes you can easily REPL into a live remote server and work with it while it is running. But more typically, the REPL-driven development happens on your own machine while you build, and then you just deploy the whole app. But it can be useful for remote debugging when necessary.

For distributed computing across multiple machines, you are right that the actor model has an edge there. Most applications don't require that, however. There is however Onyx and other tools for this in Clojure:

http://www.onyxplatform.org/index.html

I think the choice between Clojure and Elixir really comes down to how much your particular idea or requirement genuinely depends on the actor model. The vast majority of applications don't specifically require that, in which case you have more flexibility.


I was just looking into Onyx right now actually, haha. It's the first result when googling for distributed clojure. Not quite sold on the model, I don't yet know how the internals work so it feels a bit too magic. But I only got a quick peek so it would be unfair to dismiss it.

The vast majority of apps don't require distribution but I'd like to use a model of computation that would support it when needed so as to avoid large refactoring. And, preferably, allow for code reuse with systems that are distributed.

EDIT: Watching a talk about the internals of Onyx made by the creator. I gotta say, I'm liking it more and more.


Don't forget that with Clojure, anything you would do in Java or on the JVM using any language, you can do in Clojure. So for example, Scala has Akka, a powerful actor model. And of course, you can use that in Clojure if you want:

https://github.com/gaverhae/okku

(This is just one way to use Akka).


Interesting, okku seems completely outdated but I'll try to look out for an Akka integration as it is a really powerful and stable actor model implementation. Has backpressure and all of the other reactive niceties too.

You might just have converted me to clojure, haha.


I think most Clojure developers will tell you that it is wise at first to just use Java libraries directly, if you can. Look at wrapper libraries to see how the author approached the Java interop, then do it yourself. You are more likely to attain something that is maintainable, flexible and appropriate for your individual style and needs than using what someone else built for the purpose of interop for their needs.


Yeah, I'll probably do just that. Thankfully, I can research it more in my spare time.

I think I'll start with a hobby-project and see how well it goes.


The Clojurians Slack channel can be very helpful if you hit any snags.


Thanks for letting me know and for the many replies.


It does support hot-code reloading, the preeminent build tool for Clojurescript:

https://github.com/bhauman/lein-figwheel

has that out of the box. As for an actor model implementation, there is pulsar:

http://docs.paralleluniverse.co/pulsar/

Which has erlang-like actors, though some might suggest that core.async and its channel implementation provides everything you might need an actor for, YMMV.


Hmm, I guess I better look deeper into Clojure. Finally I get to play with a Lisp.

My main interest with actors is that these can be made to support hot code reloading on the server side. They also tend to be easily composable. Also also, they can be optimized by locality (eg. same-node, same-cluster, different-cluster)

I'm biased though, having not worked with CSP or other models.


I think you will find that as far as composability and hot code reloading, the combination of proper functional programming with a true REPL make this a powerful combination in Clojure that will at least match what you would get in a language built around actors.


For interactive Clojure/Script prototyping with Datomic, check out http://www.hyperfiddle.net/


> As an example I once ported an Elm project to Clojurescript and it was a 4x reduction in lines.

I'm curious to hear more about this. I'm someone who's used Elm at work, and on the side is interested in Lisp.


I think it is much easier to get real-world nontrivial work done in Clojurescript compared to Elm.


Can you go into any more specifics? I'm genuinely interested! Do you think it'll stay true as Elm matures?


Personally I think Elm is dying. It relies on a single language designer who works very very slowly. Since Elm came on the scene, vibrant languages with static typing for the front end have sprouted up and are better alternatives, like ReasonML if you want a language with static guarantees and workflow.

Elm could have been something, but I don’t expect it gain any mindshare, and the boat has sailed.

Clojurescript is a dynamic language, with easy JS interop and nearly zero boilerplate, so I still think it is the fastest route to a production app.


I write the server-side in Go, cross-compile to a Linux binary, and set that up as a service on a vanilla Ubuntu box (usually Digital Ocean). Deploying a new version is a matter of sftp'ing the new binary (and any templates, images, etc) over the top of the old one and restarting the service.

If I need a database then I use Postgres, and the setup for that can be a pain, so I get it documented/scripted using Ansible.

If I need something more complex than plain HTML on the client side then I use a Makefile to synchronise Webpack + Babel + React (and the hot reload during development), and the compiled bundle.js becomes another file to copy over.

I realise it's not very 2018, but to be honest I've kinda lost the will to live over learning anything more meta at this point.


This is about as 2018 as it gets. Go and Rust are the only modern languages where you don't have to second-guess the stdlib for bad choices (looking at you php/ruby/javascript/etc..) yet provide amazing performance.

Backend: Go (optional embed db: ledisdb / boltdb / leveldb / rocksdb / etc...)

+

Frontend: create-react-app / create-react-native-app


I find Ruby’s stdlib a pleasure to use.


How many web apps can you name that don’t rely on any external gems? Packaging that mess is a pain in every scripting language.


How far do you make it writing a web app in rust or go without pulling in external packages, then? Or a front-end using only javascript and html?


In Rust, it’s pretty quick. You could write a server yourself, but it would take a lot of work. It’s trivial with a package though.


Steve, what is Rust's equivalent to Go's cross-compilation-- plain old cargo build?


$ cargo build --target=TARGET

a list of default targets-- $ rustc --print target-list aarch64-linux-android aarch64-unknown-cloudabi aarch64-unknown-freebsd aarch64-unknown-fuchsia aarch64-unknown-linux-gnu aarch64-unknown-linux-musl arm-linux-androideabi arm-unknown-linux-gnueabi arm-unknown-linux-gnueabihf arm-unknown-linux-musleabi arm-unknown-linux-musleabihf armv4t-unknown-linux-gnueabi armv5te-unknown-linux-gnueabi armv7-linux-androideabi armv7-unknown-cloudabi-eabihf armv7-unknown-linux-gnueabihf armv7-unknown-linux-musleabihf asmjs-unknown-emscripten i586-pc-windows-msvc i586-unknown-linux-gnu i586-unknown-linux-musl i686-apple-darwin i686-linux-android i686-pc-windows-gnu i686-pc-windows-msvc i686-unknown-cloudabi i686-unknown-dragonfly i686-unknown-freebsd i686-unknown-haiku i686-unknown-linux-gnu i686-unknown-linux-musl i686-unknown-netbsd i686-unknown-openbsd mips-unknown-linux-gnu mips-unknown-linux-musl mips-unknown-linux-uclibc mips64-unknown-linux-gnuabi64 mips64el-unknown-linux-gnuabi64 mipsel-unknown-linux-gnu mipsel-unknown-linux-musl mipsel-unknown-linux-uclibc msp430-none-elf powerpc-unknown-linux-gnu powerpc-unknown-linux-gnuspe powerpc-unknown-netbsd powerpc64-unknown-linux-gnu powerpc64le-unknown-linux-gnu s390x-unknown-linux-gnu sparc-unknown-linux-gnu sparc64-unknown-linux-gnu sparc64-unknown-netbsd sparcv9-sun-solaris thumbv6m-none-eabi thumbv7em-none-eabi thumbv7em-none-eabihf thumbv7m-none-eabi wasm32-experimental-emscripten wasm32-unknown-emscripten wasm32-unknown-unknown x86_64-apple-darwin x86_64-linux-android x86_64-pc-windows-gnu x86_64-pc-windows-msvc x86_64-rumprun-netbsd x86_64-sun-solaris x86_64-unknown-bitrig x86_64-unknown-cloudabi x86_64-unknown-dragonfly x86_64-unknown-freebsd x86_64-unknown-fuchsia x86_64-unknown-haiku x86_64-unknown-l4re-uclibc x86_64-unknown-linux-gnu x86_64-unknown-linux-gnux32 x86_64-unknown-linux-musl x86_64-unknown-netbsd x86_64-unknown-openbsd x86_64-unknown-redox


Thank you


Note that you also may want to use xargo or cargo-xbuild to build other custom targets, and rustup to fetch the stdlib for the targets listed above.


Aren't there also linker issues with cross-building for some targets like i686-pc-windows-msvc? At least, I don't think I ever got it to work properly but I don't recall what the exact problem was.


Some platforms are harder than others, it’s true. And if you link to any C code, you have to deal with that as well. As an example, I just saw this: http://zork.net/~st/jottings/rust-windows-and-debian.html

We’ll get there!


I never use server-side external packages when writing web apps (well, except the bcrypt crypto package, which is an official package but not technically part of the stdlib yet).

Dependencies are evil.


Anything that runs on JRuby can be packaged as a single file.


And even with MRI, it's not as painful as people make out. Set `$GEM_HOME`, `bundle install`, tar up your app and the gems, stick them on the server.


> as 2018 as it gets

sftp'ing a binary to your deploy target? That's more 2008 iyam...


How is this setting things up "quickly" when OP is asking to limit complexity? You're suggesting:

1. Server side in Go 2. Cross-compiling it 3. sftp'ing and restarting the service everytime 4. postgres 5. ansible 6. Makefiles 7. Webpack 8. Babel 9. React


Writing web servers in Go is extremely easy. https://golang.org/doc/articles/wiki/

Cross-compiling with Go is done by setting two environment variables. That's it. This is not like the mess of C++ cross-compiling. In LiteIDE it is simply a matter of choosing Linux from a drop-down: https://www.wut.de/pics/screenshot/e-505ww-07-pide-000.png

SFTP is not exactly hard. Nor is `nohup ./server &`.

From 5 on I agree though - is that 4 build systems? Insanity. I would just make a static web page with normal HTML forms or whatever and Go templates. If you really need client-side Javascript, I'd just use jQuery, or something similar and lightweight like minifiedjs.


yeah, I use straight HTML wherever possible. But for some things it isn't possible, or suitable. I'd love a simpler client-side environment. Any suggestions welcome... I'm looking at Vue.js now, recommended from comments here.


I've enjoyed using Elm for client side development.


I second this; Go + React.js (Vue.js in my case)

I talked about it just a couple of hours ago [1].

[1] https://news.ycombinator.com/item?id=17215658


That's interesting... I think I'll spend a couple of days playing with Vue to see if I can get rid of Webpack and Babel, because they're an enormous pain to set up (especially as they keep changing their config schema every major version release - I think I've climbed Webpack's config learning cliff three times now).


I try dozen of tools for a cross-platform app and finally settle on use vue.

Every time I use node and look at his insanity and get depressed.

So, I dislike STRONGLY the use of Webpack and friends. Is a chore because JS is even more nuts now, and everything assume you want node nonsense everywhere.

So, I persist and do this:

I introduce:

> Non non-sense javascript front-end setup with vue

https://gist.github.com/mamcx/1d3aa692b0d34b0fae696c12292a1a...

Using local .js/.css files downloaded from a cdn, then using cat to concat in the correct order all the deps, and finally let to build your css/js as you please for your logic.

Build time is zero after the first try.

P.D: Maybe using unix pipes I could minimify and stuff like that, but I don't need that.


Vue apps depends on webpack as well. But the vue-cli makes the whole set up a breeze. Especially v3 (currently in beta)

If the website you're building is simple you could even have vanilla html pages then attach vue to the divs that need that extra interactivity, then you won't any fancy loaders.


React doesn't need webpack or babel. People just see lots of benefit in using them, but there are tutorials out there on how to use just React.

It can be as simple as a script tag at the bottom of your html and then writing ES5 React.


If you just have a Vue file script tag in your document, you're good to go. If you want single file components, hot module reloading, Babel features, etc, you'll need Webpack. Luckily, the current and beta versions of the vue-cli make these non-existant problems. Just install using the cli and it's good to go, no setup needed.


How do you handle server side rendering? This is one of the reasons I chose to go full Node+React.


Check out gatsbyjs.org for server side react rendering.


nuxt.js is an all in one vue framework that has ssr and a really cool file based routing functionality


Vue also has server side rendering.


Look up express-vue


Your start is good but you add complexity on top of it. Install Golang on your VPS, clone the source code on it and compile it there instead of messing with cross compilation.

Also use sqlite to avoid the pain of setting up a SQL server, there is no need for it.

You can then easily get systemd to supervise your binary.

This is how I host all my web apps, the main difference is that I don't use Go but Nim. If you want a great framework match up then check out Jester + Karax, see how I developed the Nim Forum using this combination.


> instead of messing with cross compilation.

To be fair, cross-compilation in Go is as simple as setting and environment variable.


Why put the source on the VPS? Go cross compilation is much easier then you make it sound.

    GOOS=linux GOARCH=amd64 go build
Nim can't beat that.


That's awesome, I didn't realise it was that easy with Go.

Of course, I would say keeping the source on the VPS is just as easy.


And what about zero downtime deploy (upgrading the app binary and updating the database schema)? It's difficult to do without some kind of reverse proxy and without a database server.


How often is that really required? OP asked for a quick deploy, for most apps it's enough to put the db into read-only mode and then update the schema. Upgrading the app binary is as simple as replacing it on the file system and then restarting the service.


The more often we deploy with CI/CD, the more we need zero downtime deploy. Putting the DB in read-only mode is not that simple, because the app needs to be able to work in a degraded read-only mode.


Yeah DB migrations are a pain in the bum. I do them manually because I still haven't found a tool that handles them properly.

But by the time there's significant data to migrate to the new schema, any schema change is usually due to a major version change or feature implementation, and the migration is part of a wider pain-in-the-bum situation.


Better would be to just use docker.


Please explain. I still don't understand the use-case for docker...

How is docker going to make my life easier in this example?


For me this is the response to 'how do you build stable/scaleable/.../good web apps in 2018', but sadly not to 'favorite way of getting a web app up quickly in 2018?'.

The whole process of starting a new VM for every little project seems to me like overkill and developing components if you just want to get a prototype out the door can be difficult as the components will most likely have such a poor quality that you can't reuse them for anything else.

With that said, I am 100% pro Golang Server + Vue.js UI when it comes to building something which will be definitely more than a prototype (no shortcuts taken).


whats the level of your app's complexity?

Your description would seem good for something management etc has down on paper / a design document.


How is it possible that you sftp the new binary while the sever is running? It won’t let you because the file is in use.


Unlike windows, Linux allows you to delete a binary while it's running (the binary file is not locked).


Windows allows you to rename it.


%s/react/vuejs/


Heroku and Heroku Addons are freely available at my company, so it’s the preferred deployment target. I work on a developer productivity team so being able to stamp out apps fast is one of our most important requirements.

Heroku has given us a ton of flexibility, and with that we’ve been able to become very opinionated and standardize on one stack. 12 factor design patterns (and the opinions of Django-cookiecutter) allowed us to stop arguing about how to do something and just get it done.

We use GitHub for source control and Heroku Pipelines for CI and testing. Every push runs functional tests, every PR spins up a “review app” with full dependencies and test data.

Heroku Postgres is our system of record database. Postgres is stable, fast, and full featured. With jsonb fields we’re able to store complex structured build log data and quickly aggregate on it. Heroku Data Clips are super useful for quick reviews of the data without building a report into an app.

Heroku Redis and S3 are the only other data stores. S3 stores build results and end user assets, and Redis handles anything in memory. We use Brandur’s transactionally drained job queue pattern (https://brandur.org/job-drain) to defer tasks.

The apps currently all render to plain ol HTML and for the most part take a document centric approach to front end. Additionally, our apps are all API first and we use CoreAPI to create CLI clients automatically. Those are usually our administration tools which help make sure we are API complete.


I'll chime in on the pro-CI discussion and leave the language discussions to "what's the best front end lang" posts.

I just got done revamping my decade-old PHP experience to full OO, and really upped productivity with the Slim framework to build a REST API for our app. I'm using Salesforce platform as the database backend, which is slow but I encapsulate all the business logic there. That's all cool, but, it didn't seem like I was hitting the mainstream of productivity.

Long story short, I'm on the Google/TypeScript/Material/Node bandwagon now. The dev environment is easy, and there's a wide choice of Node deployment platforms. I believe we can get the kind of deployment productivity we want with using a CI pipeline based on Github or Bitbucket that squirts commits to Google App Engine.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: