Ask HN: What are the best web tools to build basic web apps as of October 2016?
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 ] threadDo 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.
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/
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 backend, I prefer Play + Scala over Ruby/Python because of the static typing.
How do you communicate between Polymer on the front-end and Play in the backend?
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'm always keep in an eye out for a Rails replacement, and a good database story is the first thing that I look for.
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
* Frontend examples: https://github.com/tastejs/todomvc
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?"
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.
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
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 database Postgresql is your best bet.
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.
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.
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.
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.
So far I've only used Yesod myself, but Spock looks very promising and I've heard great things about Servant for writing APIs.
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
"No one really knows."
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/ ,
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.
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.
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.
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.