Ask HN: What are the best web tools to build basic web apps as of October 2016?

114 points by arikr ↗ HN
Questions:

1: Which technologies are popular and what do people like about them? (To help someone deciding between). Seems like React frontend, or perhaps Vue? and Node being the popular backend?

2: Is there a site that keeps track of the various options for frontend and backend frameworks and how their popularity progresses?

84 comments

[ 2.9 ms ] story [ 160 ms ] thread
Best tools are the ones that are appropriate for solving a given problem and that your team is productive with. React seams to be the most popular for new projects at the moment, but it tells you nothing about it being a good choice for your particular problem or situation. React is significantly more popular than Vue but say you happen to be planning a Laravel project and in that community Vue is way more popular than React. It would appear that Vue is a solid choice for you new Laravel project, but then you get a requirement that you have to build mobile apps and they should share as much code as possible with your SPA yet use native widgets, now it appears you better of using React. So in general it's pointless trying to base your choice on how popular something is.
I agree. IMO if youre coding something for fun, just find some new tech that interests you and do it. Getting paid? Find what works well, learn it, and use it. You want stability and good community support / documentation. Dont follow fads for professional work.
I would say mithril.js for the frontend and Flask for the backend is pretty good, but that's just my favorites. There are plenty of other good ones, and neither of those are particularly popular.
Personally, it's more important for me to have fun while coding than using "popular" tools. In the end, your end users don't care as long as it works.
I use flask for a personal project of mine, but instead of Mithril for the frontend, I use http://riotjs.com/. I find it much more readable for someone who has been working with HTML/CSS for quite some time.
Yeah, it amounts to what you like.

Do you like HTML-like templating and a lot of sugar? Riot is the way to go. Do you like minimal magic, JS-style templates, and/or Lisp? Mithril is the frontend for you.

What problem are you trying to solve? Are you building a basic todo app or a massive CRM tool? Are you more concerned with performance or speed of development?
http://stateofjs.com/

If you're really unpatient, I'll click on the first link for you[0]...which reveals the popular frameworks. This is based on real data since it's a survey, not just one or two comments on HN.

[0] http://stateofjs.com/2016/introduction/

Thanks for a great link, but it's only JS – meaning all other backend frameworks were not included in the survey.
Yeah, that is very true unfortunately. I'm really into node though, so js is all I need :)
Basic can mean very different things depending on the purpose, audience and market the app is targeted at.

If you're building simple CRUD apps for a business audience both Rails and Spring Boot would be good choices for instance.

In terms of front-end development I'd suggest vanilla JavaScript and HTML5. Keep things simple. A basic web app doesn't need any complex framework.

That said Angular, React.js and Vue.js are equally valid choices for building complex applications but each of them is way beyond a 'basic web app' scope in my opinion.

For frontend, I prefer PolymerJS with vanilla JS. The way it scopes CSS/HTML/JS is cleaner, and this is the right direction. (I never use ReactJS.. but it might be similar).

For backend, I prefer Play + Scala over Ruby/Python because of the static typing.

(Same question I asked another Polymer person).

How do you communicate between Polymer on the front-end and Play in the backend?

Are you an experienced web programmer and already know how to manage migrations, CDN, REST apis, etc ?

If not, I would still go with Rails. Its massively productive, batteries included... and forces you to learn some practices that you can later take to other frameworks (migrations, asset pipeline, etc).

I dont know of any other framework that forces you to adopt these. On HN, you will find a lot of rhetoric against that - which may be true for experienced programmers.

But for sheer productivity from someone new to all this... Rails really cannot be beaten.

In the JS world, you will spend atleast a couple of days figuring out Requirejs vs AMD vs commonjs vs webpack vs browserify vs npm vs yarn.

I'm not so sure if it is worth it...unless learning JS frameworks was your goal all along.

I can't agree with this more, and with the addition of Turbolinks in recent Rails versions you get the snappiness of a JS front end framework in areas like page load. After building a service oriented architecture with React and Rails I truly realized the benefit of a tightly coupled front end / backend for speed of development and deployment. Building bespoke API's for other clients isn't as much of a headache as it's been made out to be.
(comment deleted)
I think that database management features in particular are a huge benefit for many applications - db generation from code, migrations, and seeding. Once you have more than two environments (dev machine/staging/prod, or more than one developer) moving database changes between environments becomes a big potential source of friction.

I'm always keep in an eye out for a Rails replacement, and a good database story is the first thing that I look for.

I think you can build a simple web app very quickly using Create React App on the frontend, and a REST or GraphQL API on the backend.

One great thing about this architecture is that it can scale as the app gets more complex, since you can just add more components to the UI, and more fields to the GraphQL schema, without needing to re-structure anything.

I work on Apollo, a set of tools to make it easy to create and use a GraphQL API, and we have a hello world client [0] and server [1]:

[0] https://github.com/apollostack/frontpage-react-app [1] https://github.com/apollostack/frontpage-server

There are tradeoffs between: performance, development speed, trainability (documentation), depth and breadth of developer community, long-term viability (foundation, backers), maintenance (upgrade path), API flexibility (decoupling, cohesion), standards compliance, vulnerability/risk (breadth), out of the box usability, accessibility, ...

So, for example, there are WYSIWYG tools which get like the first 70-80% of the serverside and clientside requirements; and then there's a learning curve (how to do the rest of the app as abstractly as the framework developers). ( If said WYSIWYG tools aren't "round-trip" capable, once you've customized any of the actual code, you have to copy paste (e.g. from a diff) in order to preserve your custom changes and keep using the GUI development tool. )

... Case in point: Django admin covers very many use cases (and is already testable, tested), but often we don't think to look at the source of the admin scaffolding app until we've written one-off models, views, and templates.

- Django Class-based Views abstract alot of the work into already-tested components.

- Django REST Framework has OpenAPI (swagger) and a number of 3rd party authentication and authorization integrations available.

- In a frontend framework (MVVM), ARIA (Accessibility standards), the REST adapter and error handling are important (in addition to the aforementioned criteria (long-term viability, upgrade path)) ... and then we want to do realtime updates (with something like COMET, WebSockets, WebRTC)

Similar features in any framework are important for minimizing re-work. "Are there already tests for a majority of these components?"

(comment deleted)
Frontend: TypeScript, React, MobX

There is (in my opinion) no reason not go with TypeScript. It's strictly better than ES6. React and MobX because of their simplicity.

Backend: Go

No particular reason to choose Go other than it's fun. TypeScript with Node is also a good choice.

Edit: I am talking about SPAs.

Recently I've built, as a side project and soon-to-be open source, a micro SPA [1] to learn React+Redux and for the interface I chose Semantic-UI [2]. There's a official React integration [3] that is really good and easy to use, and since I wanted to mix pure HTML pages and the app, it's ideal to use a React UI framework that doesn't bundle all the CSS into the components.

The Semantic UI React integration also doesn't need jQuery, which is a nice bonus.

I agree with the TypeScript suggestion. It's so good, and the VS Code integration is awesome.

[1] https://javascriptobfuscator.herokuapp.com/ [2] http://semantic-ui.com/ [3] http://react.semantic-ui.com/introduction

Meteor is still pretty great. It's an all-in-one (including database) framework that uses JavaScript for both back and front ends. It's build tool also saves you from having to configure things like Babel, Webpack, SASS, etc...

The documentation for beginners is top notch as well: https://www.meteor.com/tutorials https://guide.meteor.com/

There's plenty of options, too. You can throw together a few files and have a simple app going in a very short time (an hour or two), or build highly modular apps with a React or Angular front-end.

For frontend: Polymer/VueJs, for backend Python+Pyramid+SqlAlchemy are great options.

For database Postgresql is your best bet.

How do you communicate between Polymer on the front-end and Pyramid in the backend?
Exactly the same as you would do for any other framework combination. There is nothing specific you need to do to work with them.

Pyramid has great support for REST API building and I'm just using json renderer to serve the data to polymer components that consume them.

It depends how much time you want to spend on it. If it's a simple app you'll never touch again then ms stuff is meant for turn and burn apps without learning anything.

If you want just Templating and always open connections for building backend site builder tools then PHP is your language.

If you want free and scalable with as little code as possible with building files you never have to write again then Python Django restful API and angular2.

If you plan for this to be worked on indefinitely and it'll be customized every day and you know the greatest will stay with you with high risk, then vanilla js and nodejs.

If you want as quick as possible but with a scalable price then reactjs and firebase.

I predict you're going to get a lot of different answers and that you may not find a strong consensus.

My advice is that there is no clear winner. Each technology serves a spectrum of needs, some better than others. If you're experienced enough to know what you need, then vet each technology in terms of what they offer to solve your problem. If not, my advice is to pick something that appears reasonable and go with it; you'll learn a lot, and eventually you'll arrive at the conclusion that all of these things are just tools--your own experience is the strongest thing you bring to the table.

I'm going to go out on a limb and suggest this stack (especially if you're into functional programming):

Haskell + Elm or PureScript + Postgres

The best part about it is that it helps you catch many errors at compile time, instead of having your app crash at run time.

For keeping your Haskell and Elm data types in sync while maintaining sanity, I recommend elm-export [0], which will automatically generate the Elm types and JSON decoders from your Haskell code, using GHC Generics. Watch the author talk about it [1].

Choosing Elm over JS already gives you a head start, but you might hit a productivity wall at some point, and PureScript gives you all that extra power with its advanced type system. Some related discussion here [2].

Check out Matt Parsons' blog [3] for more on Haskell, Elm and PureScript.

Lastly, for database you can use Persistent [4] which gives you a type-safe API for data modelling and data store, and can automatically generate and perform migrations for you.

[0]: https://github.com/krisajenkins/elm-export

[1]: https://www.youtube.com/watch?v=sh4H8yzXnvw

[2]: https://www.reddit.com/r/haskell/comments/569cax/

[3]: http://www.parsonsmatt.org/

[4]: https://hackage.haskell.org/package/persistent

P.S. Do take my suggestions with a grain of salt as I don't have much experience with any of the fancy JS frameworks.

Thanks for the recommendations. I need to study both Elm (never used it) and PureScript (have just played with it). I am almost ready to publish my first Haskell book (my take on getting started the easy way, with a tutorial for a subset of the language and some cookbook style coding recipes to play with). I am thinking of doing a volume II cookbook that covers web development, and other topics. I use scotty and yesod, and experimenting with Elm and PureScript sounds good.
Looking forward to your book! A volume II sounds like a good idea too.

So far I've only used Yesod myself, but Spock looks very promising and I've heard great things about Servant for writing APIs.

Servant looks great. I have only spent a few hours playing with it, but from what I have seen, I like it.
Servant is still _very_ rough around the edges, imo. I like it a lot for mocking APIs [0], but I'd be wary about using it in production for anything other than a small service.

Right now I'm keeping an eye on servant-auth [1] and the GHCJS implementation of servant-client [2], as they're both extremely compelling.

[0] Recently, I needed to test something against a work-in-progress API. I wrote out a rough type-level specification and had servant-quickcheck generate arbitrary data. When I needed to test more concrete data, it was trivial to incrementally move endpoints over to concretely defined stubs.

[1] https://github.com/plow-technologies/servant-auth

[2] https://github.com/LumiGuide/servant/tree/client-ghcjs

The comment section reads like a satire. :) So the conclusion is probably:

"No one really knows."

The people that know aren't talking. It gives them a competitive edge. ;)
1. I would go with VueJS for frontend - see example https://vuejs.org/examples/tree-view.html Definitely can recommend handling of complex state through redux/vuex.

For backend: Go with anything that you are proficient with. If you aren't familiar with anything I recommend starting with RubyOnRails/Sinatra/Django/web2py/Phoenix.

2. Yes - http://bestof.js.org/ See also http://stateofjs.com/2016/introduction/ ,

One more vote for vuejs. Just drop it in your project and start using it, and the documentation is clear and concise.
If I were starting totally clean. I'd use Rails 5 in API mode and React/ReactRouter. Add in Redux if you need more complexity.
Frontend: Typescript, React, Redux

Backend: F# or Elixir

I liked how easy it was to learn Redux. It teaches you functional principles, not only useful for your specific web app but also for your career as a programmer.

If you're building a basic webapp, you shouldn't be using a front-end framework at all!

React has one of the gentler learning curves of the front end frameworks, but it's still a lot more work than just rendering everything server-side and adding whatever minimal effects you need with jQuery.

I second sandGorgon's recommendation to use Rails. PHP is another good option. It's absolutely amazing how many successful new software companies are being built off of WordPress and/or Laravel.

I say this as someone who was using React in February 2014 and who loves to geek out over newer more powerful technologies. The thing is, your users don't care. Groupon was launched as a crappy WordPress site + a mailing list, built way past its breaking point, migrated to Rails, broke again and was a $5B company in 5 years. Many, many startups with harder-core technologists started years earlier still haven't reached where they are now even with a perpetual string of problems and failures from their IPO until now. Teespring started on Rails long after that was cool and they're a juggernaut.

Use something productive and ship it.

> Use something productive and ship it. This! Can't agree with it more.

Your clients don't care if your backend is written in PHP, Rails, or Go. Use whatever is your best tool in order to ship it quickly. It's "acceptable" to have a reasonable amount of fun, but don't waste time learning a whole new stack at the risk of validated learning.

Unless it's supposed to be a fun project to begin with.

I couldn't agree more with this.

However, I'm curious: at what point do you think the flavour-of-the-month JS frameworks actually do make sense for a development team / company? This might just be me being old and set in my webdev ways - I remember when PHP4 arrived on the scene, for goodness' sake - but I do struggle to see the business case for a lot of the current JS-everywhere, a-million-tools-for-everything environment, and I suspect I'm missing something key.