Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: What are the best web tools to build basic web apps as of October 2016?
114 points by arikr on Oct 23, 2016 | hide | past | favorite | 82 comments
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?




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.


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.


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.


1. I work with Django, Django Rest Framework, React, works well. I heard that Vue might be an interesting option. Honestly there's a myriad of tools/framework around there, you have to ask yourself what are you trying to achieve? Is it a one shot app you'll build over the week end? Something that you'd like to maintain over time? That may scale? Are you working alone on this or not? Is it an exercise to learn a new stack? I started a startup 4 years ago, asked a friend who's a ruby/rails dev for advice about tech/stack, his answer, yes rails is awesome but as you already know python go for Django as my goal was primarily to get stuff done business-wise not so much to learn cool new tech. So be aware of your options and definitely spend some time to know them but in the end they're just tools, don't forget why you use them in the first place.

2. I stumbled upon http://stackshare.io the other day, I can't vouch for it but seemed nice to have a quick overview of what languages / framework / services are used around.



If you're a committed, heavily-invested user of a specific language, and well into your professional career: use that language.

Otherwise:

If you like Python, Django.

If you like Ruby, Rails.

Otherwise: Flip a coin.

Heads? Rails.

Tails? Django.

A lot of very smart people will tell you that PHP is as good an option as Rails or Django. The problem with PHP is that while the upside for PHP is, as they're observing, just as good as the Rails/Django upside, the downside is way worse.

Counterintuitively: I think you should really know what you're doing as a developer before you decide on PHP. PHP isn't by itself going to teach you to be a better developer. Python will.

Avoid Javascript frameworks until you really understand what you're doing. Also, know ahead of time that "really understanding what you're doing" might result in you continuing to avoid complicated Javascript. A trap I can tell you about from recent experience. :)

Probably don't build front-end web applications in Go.


> the downside is way worse.

Can you explain how the downside is way worse?

> A trap I can tell you about from recent experience. :)

If it's not too much to ask, please share your experience briefly. Like me, a lot of folks here would be interested to hear your thoughts on this topic.


The worse downside: There is a lot more crappy PHP code out there that novice devs will copypasta than there is for other languages. This makes it harder for novices to find the non-crappy PHP code in order to learn from it.

As a result, it is not particularly unusual to come across a PHP app that has been in production (and maintained!) continuously for nearly a decade that have all the SQL and JS inline, for example.


Would an appropriate compromise be to recommend "if you're going to learn with PHP, make sure you use a framework" since using any of Symfony/Laravel/Cake/etc will guide/force you into slightly better habits than writing PHP from scratch would?


Part of the downside I was trying to convey is that a lot of the PHP work available is maintaining or fixing truly horrible applications, and that while skilled PHP developers are as productive as skilled developers in any other language, unskilled/novice developers are much worse as a consequence of learning all the wrong lessons from random code examples that they find through search engines.

It is actually quite difficult to deliberately create a web application in Python that is as bad as one of those "shopping cart with all the HTML, SQL, JS, and CSS interleaved in a single PHP file" examples that a novice will find and learn from. A novice is highly unlikely to manage it through ignorance even if they somehow manage to avoid using a framework.


I think as a PHP developer I jumped to defending PHP without understanding the nuance you were aiming for, sorry about that. I definitely agree with what you're saying.


No worries, the particular cause-and-effect nuance is subtle enough that a lot of people misunderstand it, which suggests that my phrasing is at fault.

And while the attractive nuisance of PHP's Turing-completeness that encourages those anti-patterns is annoying, it isn't entirely unique:

The platform I cut my development teeth on in 1998 (Zope[1], written in Python) also had a template language that was Turing-complete called DTML[2]. It was a painful transition for the community to deprecate DTML in favor of the new Zope Page Templates (ZPT)[3] that implemented a deliberately less powerful syntax[4][5].

The advantage of a less powerful template syntax is that it forces all "business" application logic (as opposed to "view" logic) out of the templates and into Python code.

Unfortunately, for deployed applications this was a lot of extra work that could only be justified in terms of increased maintainability, which was an even harder "sell" to managers back then.

[1] https://www.zope.org

[2] https://docs.zope.org/zope2/zope2book/DTML.html

[3] https://docs.zope.org/zope2/zope2book/ZPT.html

[4] https://en.wikipedia.org/wiki/Template_Attribute_Language


Is there any argument to be made for someone starting their career to look into an emerging web technology like Elixir/Phoenix? I ask this as someone who is trying to decide what language/stack to seriously commit to learning while I try to undo the damage caused by starting out professionally in ColdFusion and PHP.


If I was just starting out, I'd pick Python or Ruby to start with, and do Elixir on the side. I'm not saying that Python or Ruby are the best languages --- they clearly are not. They're just the best the mainstream has to offer.


Gotcha. Thanks for your perspective.


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.


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.


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. ;)


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


React and mobx is like clojurescript's Reagent library, which I think is the next level after react-redux. It's like pseudocode, here's a direct translation of reagent's clock example: https://gist.github.com/lsdafjklsd/096f8657306a86832e6df1109.... This essense lib is just a unified api for mobx and react, I've been using it to teach people javascript. https://github.com/lsdafjklsd/essence


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.


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?


I spent recently some time re-evaluating tech stacks to get back into prototyping apps. My team [1] primarily uses React/Node.js, but from experience it seemed overkill for my needs (IMHO, great at scale but can get in the way of smaller apps).

I settled for Flask[2], SASS (using egg, my own boilerplate/micro-framework [3]) and Vue.js [4].

Simplest to get started with, gets the job done and scale nicely.

[1]: http://wiredcraft.com [2]: http://flask.pocoo.org/ [3]: http://wiredcraft.github.io/egg/ [4]: https://vuejs.org/


React/Redux + Django + Django request framework + Postgres


REST not request.


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 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


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?


I'm a fairly novice programmer and mostly build business applications. I work with Meteor, Django and PHP (Code Igniter).

If you are looking at building basic webapps, I will really recommend Meteor. It is very intuitive, flexible and Javascript across the whole stack. It can easily integrate with Vue and React, which are again JS friendly.

Django is very neat and you can learn how to code within a week looking at the sourcecode of Wagtail.io ... I did it that way.

PHP is very straightforward and pretty much every issue that you run into would perhaps have a solution ready for you on StackOverflow.


Well in my experience I must say: Node.js+Express is the way to go for making simple page-serving servers that can handle many many clients. If you wish to do something more complex with the front-end, I have been using socket.io and also Angular.js. Angular adds to the mix a "controller" that holds a per-client state so that you have your node "server," your angular-based "client" and then the view (which is the browser/html+css).

So, since your question says "basic" I'll leave it at that.


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.


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 :)


I spent 2 weeks times ago learning react. My family was in vacation, no kids no wife... so as a diligent nerd I decided to understand why half of the world is now convinced that css, js, html must live together.

Curiosity, one of the project I want to rewrite is an old .net 2.0 using Ajax 1.0 (someone remember that...) having response.write (literally anything)

The idea was understand also how to combine babel and webpack to work with an external api (couple of weeks before create-react-app that you should check in any case)

I'm not using react in production yet, the application I have are full of data entry and very few nice things like stars and likes or profiles with nice icons but

Spend some time on

VUEJS (use their vue-cli)

react (use create-react-app) and check react router.

If you still don't get them after few weeks html and jquery will always rescue you (at least for next 5 more years)

Backend... cause you are learning ES6... you probably want to check

Expressjs

Passportjs

Express session (maybe using mongo as data storage)

But becauseyou also want basic...

Check out

GitLab pages

Github pages

Both have nice solution for static framework.

Good luck with this.new.world.


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.


I don't know, but unfortunately the answer will be completely different in October 2018.


JavaScript developers will probably have/need a different answer in November 2016


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.


PHP :-)


The issue with your question, I think, is over the exact meaning of the words "best", "basic", "web apps", and "popular".

By many measures the best and most popular stack would be mysql, php, html, css, and maybe a little jquery sprinkled on top. It powers an enormous amount of the web, it allows very rapid development, and it's about as cool and hip among the hacker news crowd as a cod liver oil enema, and with good reason!

Of course, you can improve it, but you need to figure out what metric you're looking to improve it on. If you rule out PHP or jquery or whatever, then other answers start to look like the most popular.

> Seems like React frontend

React has a lot of buzz, and it widely used for new projects trying to build web apps with heavy client-side functionality. Of course, there's simply an enormous amount of Backbone, Angular 1, or random jQuery client-side apps out there, plus an even more enormous amount "traditional" webapps with minimal client-side functionality (like hacker news). You have to define your search quite narrowly to make React look like the most popular tech.

> perhaps Vue

In the last couple of weeks Vue has probably got more buzz in terms of people talking about it on HN and /r/javascript than React, yes. From a certain point of view that makes it more popular than React; from basically all other points of views it's much, much less popular. Then again, why do you care about popularity? The wisdom of crowds is probably least useful when judging hype-driven popularity contests.

> and Node being the popular backend?

For small hobby projects among people who mostly know JS and have no particular reason to choose anything else? Yes. And low barriers to entry mean it's used in a large number of projects.

On the other hand, in many ways it is an objectively inferior backend. And in others it's objectively excellent. It really depends what matters to you.

> Is there a site that keeps track of [...] how their popularity progresses?

Depends how you want to measure that. You can use google trends, or compare github stars, or npm downloads, or the number of topics posted about it on /r/javascript, and get different answers.

Realistically though...

...none of it matters. Any vaguely functional stack is good enough; the odds of your project failing because you picked Rails instead of Django, or Mysql instead of Postgres, or Coffeescript instead of Typescript is nil. What does matter is that you pick a vaguely functional stack and start writing code.


Someone sent me this which highlights the complexity of web development these days. Sad but quite amusing:

https://hackernoon.com/how-it-feels-to-learn-javascript-in-2...

This question reminded me of it



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?"


For a basic web app, I would just Flask and just use Jinja templates to render views.


Currently using Sinatra in my latest side project. I realize it's no longer the heyday of Ruby, but for simple apps its easy to get started and enables the possibility of using the vast amounts of Ruby gems in my project.


If you are comfy with Java, consider Ninja Framework for your backend. Dead simple configuration and ramp-up time. All of my sites based on it have been so fast (page loads < 50ms), I have had no need for AJAX at all.


Frontend: React (via create-react-app), good old Bootstrap

Backend: backend as a service like Firebase or Horizon/Rethinkdb. Vendor lock-in is a big concern here but you can get your prototype done so fast with those tools.


> backend as a service like Firebase

Using BaaS things is more like for the prototype/MVP like projects in my opinion.

Edited: though I see title has "basic" word in it, so it's fine.


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.


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.


Crazy suggestion, but if you want basic,I suggest using Shiny with the R language. It is by far the simplest way to get a basic page up and running.


PHP.


My brother!


Turbo Pascal


On a similar note to OP, what are currently the best tools for building scaleable webapps?


The React Convention www.reactjs.co (ReactJS and React Native Redux, the right way)


Does someone use TypeSript on both sides (backned for NodeJS and frontend)?


Angular 2 + Express + Postgres (TypeORM)


Notepad on Windows, vi on Linux.


.net core with react?


1. Interesting applications in October:

CSS ICON: http://cssicon.space - Generate CSS icon.

INITIALIZR: http://initializr.com - Generator HTML5 templates (Classic/Responsive/Bootstrap)

BUDDY GO: https://buddy.works/buddy-go - Git hosting on your server.

LAYERSTYLES: http://layerstyles.org/ - Crate CSS from Photoshop Layer Style.

FFFFALLBACK: http://ffffallback.com - It bascially scans the page’s CSS and creates a clone page where you can test and analyze different fallback fonts.


Basic? PHP + Apache.


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.




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

Search: