6 ms·

Rather than changing express's syntax, I would much rather have a better express boilerplate generator with an opinionated stack with good documentation/justifi

• rorykoehler 9y ago
  Couldn't agree with you more. Have been involved in a few projects this year where a bunch of freelancers who had never worked together were thrown together to get something up and running quickly. The results were slightly horrifying precisely because everyone had their own tooling and way of doing things. Opinionated boilerplate would have solved so many problems for us upfront.
• jypepin 9y ago
  maybe time to make a "node on rails"!
  • abritinthebay 9y ago
    Please no.
    • clintonb 9y ago
      Why not? Figuring out DB access, session storage, i18n, etc. is not core to my business. Why not abstract that into a framework, and let engineers focus on solving their business needs?
      • abritinthebay 9y ago
        Most of the things you mention are already solved in several useful and applicable to different situations methods in JS anyhow. Mega-frameworks are, in my experience, one of the biggest sources of encouraging Bad Practices just because their the favorite idiom of the developers. Rails is infamous for this. Node (and JavaScript) already has a big enough problem encouraging good code practices that a Rails framework would do untold damage. The closest it has now is Express (obviously not the same) and that’s already pretty bad for doing what I mention (vastly superseded by Koa and Hapi anyhow). These things create a very dangerously myopic gravity. The micro module route Node, JS , and npm uses is - I feel - much much more flexible and beneficial long term.
        • jaequery 9y ago
          It's a double edge sword. With so much freedom, there is a high chance an inexperienced dev can wreck your project before it even begins.
          • abritinthebay 9y ago
            That's true even with the large framework though. Rails does very little to protect against that and can make many things worse.
          • clintonb 9y ago
            Bingo! I've seen things go wrong with Backbone. The lack of opinion is great if you have an experienced developer starting the project and defining the filesystem layout and overall architecture. We, unfortunately, did not have that for our marketing site. I actively avoid working on our marketing site for this very reason.
  • ricardobeat 9y ago
    https://sailsjs.com https://sailsjs.com still going strong last time I checked.
• dcosson 9y ago
  Totally a tangent but, don’t use moment.js! It inherits some of the parsing and other quirks from the awfulness that is the JS Date object, the mutability almost certainly will lead to being bit by a couple of bugs before you actually internalize it, and the time zone support is kind of tacked on as an afterthought. I highly recommend js-joda, particularly if you’ll ever be computing/showing things to your users in different time zones. It actually treats dates and times rigorously, and has an api that makes it clear what kinds of operations make sense to do on a zoned vs local datetime and makes things like converting between timezones vs transposing them explicit and simple.
  • always_good 9y ago
    I haven't tried it, but https://date-fns.org/ https://date-fns.org/ looks nice. For example, immutable API and just uses native Date objects.
    • dcosson 9y ago
      Yeah it looks nicely simple & modular, but it probably works best in Node.js since your servers can all be in UTC. In general I see the appeal of using a small shim around a standard library thing rather than re-implementing something totally new, but JS Date is bad enough that you're better off staying away altogether. It's just hard to use correctly since there's no "timezone unaware" object available and it always assumes the local timezone, so users' browsers in different timezones treat them differently. Lots of seemingly simple things (e.g. a time + timezone input picker) are easy to mess up because you end up accidentally implicitly converting things to the local time.
  • cabaalis 9y ago
    I've always been of the opinion that timestamps should be stored UTC datetime or unix timestamp on the server side and then displayed to the proper locale by the client's device. Is this not a good method?
    • mnutt 9y ago
      There are some cases where you not only care about the exact time (unix timestamps are fine for this) but also the timezone in which it was specified. I work on an app where users specify "people in california should see this at 3pm PDT" and get confused when they reload the page and it has been switched to "6pm EDT". As an aside, moment-timezone it a godsend for dealing with timezone discrepancies. I would pay money for it.
• atiffany 9y ago
  Totally agree with you. I miss the opinionated nature of Rails when I work in the JS world.
  • always_good 9y ago
    I think it's always just going to be a different-strokes thing. For example, I left the Rails world hungering for tiny, composable solutions like Clojure's Ring and Node's Koa. I ended up preferring to just see glue code in my git diffs. For me and the small teams I work on, there's a lot of productivity to be gained when you can just look at the code and understand what's going on. You end up with bespoke glue code per application, but the glue is generally simple so I didn't reap much reward from using a framework that tries to hide it at all cost.
  • vnchr 9y ago
    You might like Ember. Very opinionated. Yehuda Katz is one of the creators and core team leader.
• rpedela 9y ago
  If you already have a database, I recommend storing the session in the database. I personally use connect-pg-simple when using Postgres. In other words, I wouldn't add another major dependency like Redis just for session storage.
• Xeoncross 9y ago
  rate-limiting -> nginx || iptables Never ask PHP/Node/Ruby/Python to do low-level network routing. Your throwing megabytes of memory at a simple connection decision. If you need advanced logic for rate-limiting (not just access counting) then using nginx + memcached/redis as the marker. Have your app mark the ip in memcached/redis so nginx knows not to bother Node/PHP/Ruby/Python next time.
  • always_good 9y ago
    What you propose is only a performance optimization at the expense of operational complexity. Like caching. "Never" doesn't make sense.
    • Xeoncross 9y ago
      I guess you could simply rate-limit your login/signup if your not worried about a DoS and just want to keep people from brute-forcing a password. On the other hand, it's not simply "a performance optimization" as there is no way for node to handle a DDoS without crazy amounts of hardware relative to what iptables|nginx can handle.
      • deleted 9y ago
        [deleted]
      • always_good 9y ago
        You're the one talking about DoS. Notice how "rate-limiting" is a much more generic concept. For example, Hacker News rate-limits the amount of posts you can make in a window of time. That's not because they think you're trying to DoS them.
    • northvillage 9y ago
      This is optimization, might as well go all out and call it caching. "never" won't even apply.
• franciscop 9y ago
  Changing the syntax is really useful to avoid Callback Hell by leveraging async/await: http://callbackhell.com/ http://callbackhell.com/
• midrus 9y ago
  > I would be so happy if someone took away my power to choose and just forced me to use something that will "just work". You are looking for django/ruby on rails.
  • jjjensen90 9y ago
    Or Laravel
  • jazoom 9y ago
    Actually it sounds like OP is looking for something in NodeJS. I'm also interested in a NodeJS version of something like that even though express is very straightforward once you've worked out all the modules you need.
  • clintonb 9y ago
    No, he and others used to more complete (for lack of a better term) frameworks are looking for the Django/Rails equivalent in Node.js. I got my first taste of Node.js development a few months ago (https://engineering.edx.org/serverless-984cee7797e1 https://engineering.edx.org/serverless-984cee7797e1) and found it confusing that so much of what I take for granted in Django is kinda all over the place in Node.js. The one that stood out to me was internationalization (i18n). In Django, I mark my strings, run a couple commands to extract/compile translations, and I'm pretty much done. The most popular options for Node.js involved writing a crawler for my site. It makes no sense me that folks are writing crawlers when the static text is on the disk, marked up, waiting to be parsed. The diversity of the Node.js ecosystem is great because there is clear change and innovation. It's bad, however, because some of that innovation is simply taking things done by other frameworks and poorly implementing them in libraries or other frameworks. The lack of general consensus potentially hurts adoption by those of us who work with Django/Rails and perpetuates the myth of the JS world changing every hour/day/week.
    • always_good 9y ago
      I think you're guilty of the trope that everything should be ported to Node/Javascript. More likely is that the people who want the features of Django/Rails just use Django/Rails, so there's no goldrush to recreate them in Node nor a monolithic community around the attempts so far. The Node ecosystem is like the Clojure ecosystem: all-inclusive frameworks just aren't as popular as library composition.
• Xeoncross 9y ago
  https://feathersjs.com/ https://feathersjs.com/, https://github.com/zeit/next.js/ https://github.com/zeit/next.js/, and https://github.com/jedireza/aqua/ https://github.com/jedireza/aqua/ handle more of this for you without turning into the black-box Meteor.js.
• Can_Not 9y ago
  You're looking for Adonisjs.
• vineet 9y ago
  Isn't Sails just that: https://sailsjs.com/ https://sailsjs.com/
  • azr79 9y ago
    Yes but not with the "just work" part
    • mikermcneil 9y ago
      A lot has changed in v1
    • quickConclusion 9y ago
      what's the part that "just" does not work? I am starting a new project soon and I played with Sails. I really liked it, except I struggled with the user authentication part. Also worried that the momentum of the project seems to have slowed down a bit, Mike does a lot but seems a bit lonely... Or?
      • sotojuan 9y ago
        The problem with Sails is that unlike Rails or Django, it's not very popular. This not only means a lot less documentation and help for you but also help for the maintainer (financial or code-wise). This means a slow rate of development, bug fixes, and updates. I do agree with another poster in that if you want a opinionated just works stack, use Ruby or Python.
• nahtnam 9y ago
  I'm working on something like that in my spare time for myself. I have a bunch of websites and it was quite annoying to have to update the same thing over and over again if there was a bug with one of my middleware so I just extracted out into it's own project. It uses Koa under the hood, but all it essentially does is bring in the most popular Koa middleware and mesh them all together. https://github.com/konstructorjs/konstructor https://github.com/konstructorjs/konstructor It is still in it's very early stages. Thoughts welcome!
• azr79 9y ago
  > I would be so happy if someone took away my power to choose and just forced me to use something that will "just work". That's basically what Google did on the front end with Angular for people who had the exact same problem with React. Maybe we'll see something like this happen on Backend Javascript, I mean there is Sails, but it doesn't "just work" as well as Angular does on the frontend.
  • leke 9y ago
    Isn't that what Meteor did (for the backend), or am I not understanding the problem here?
• WhitneyLand 9y ago
  Software development should be about thinking, creating, solving problems, and yet a large percentage is grunt work that barely requires more than monkey intelligence. In some ways we benefit. Sometimes its harder to replace us not just because of skill, but because of countless layers of byzantine and mundane information we’ve memorized about a system. It just not cost effective to stuff all of that crap into someone else’s brain if you don’t have to. However whenever there is a way to reduce the cruft to productivity ratio, the power is staggering. That’s your “10x” developer right there, someone who gets to actually think a higher percentage of the time.
• deleted 9y ago
  [deleted]
• LrnByTeach 9y ago
  Good list to ponder trade off Node js Express packages , all in one place !!!!! > But still a bunch that I haven't gotten to googling and still need to decide on what to choose: logging (morgan vs winston) validation (express-validator, joi) auth (passport jwt, local, social) session storage (redis vs keeping it in database?) database (mongo/mongoose vs pg/knex/bookshelf/sequelize, graphql) storage (s3 vs gcs) ajax requests (request vs axios) mail (mailgun, sendgrid, mailchimp) error handlers rate limiting geo ip
  • cheapsteak 9y ago
    For those who don't have too too much time to spend comparing stacks, looking at download trends is sometimes a decent heuristic for weeding out which you might not want to throw into a production system yet. Shameless plug for a site I made to help visualize that logging - morgan vs winston - popularities seem similar, although winston has a bit of a lead: https://npmcharts.com/compare/morgan,winston https://npmcharts.com/compare/morgan,winston validation - express-validator vs joi - joi no question: https://npmcharts.com/compare/express-validator,joi https://npmcharts.com/compare/express-validator,joi SQL ORMs - sequelize and knex were neck and neck for a while, but sequelize seems to have pulled ahead in the last couple months. bookshelf is way behind. https://npmcharts.com/compare/knex,bookshelf,sequelize https://npmcharts.com/compare/knex,bookshelf,sequelize
• lwansbrough 9y ago
  Well if you want this and you’ve ever considered using TypeScript for a JS project, you could try C# + ASP.NET Core. IMO it’s probably the best web stack out there. Opinionated, but allows you to stray from those opinions fairly easily. Secure by default. Great support and stability.
• holon 9y ago
  I much prefer frameworks like Adonis (https://dev.adonisjs.com/docs/4.0/installation https://dev.adonisjs.com/docs/4.0/installation) - it feels a lot easier to just strip out what I don't need from an MVC framework, than to end up rebuilding 90% of the same functionality from a bare-bones Express / Koa application.
• incadenza 9y ago
  Yeah, I have a similar feeling. At this point I have a repo that I keep somewhat up to date and then fork the repo for any new projects. Every time I start a new express app I feel like I'm working at the 'wrong level of abstraction' to put it in Dan Abramov's words about the React ecosystem. I end up writing the same boilerplate over and over. The only solution I have is a bare bones repo that I keep up to date myself. Not a great solution, but it's a solution.