DEV Community

Vesa Piittinen
Vesa Piittinen

Posted on

What would you choose if you'd go against the trends?

A new site these days:

  1. Node
  2. Babel
  3. React / Vue
  4. Redux / GraphQL / Saga
  5. CSS-in-JS / Styled Components
  6. Universal Single Page App
  7. Code splitting
  8. TypeScript

This seems like a typical combination that "everyone" wants to have, and what everybody tells everyone else to learn and use.

But if you were given the choice to do otherwise, which techs would you go for instead and why?

In case the above list is what you would choose, what would you choose instead if your most liked half of the choices were banned?

Top comments (15)

Collapse
 
ben profile image
Ben Halpern

The way we built DEV with Ruby on Rails and vanilla at first on the frontend while gradually figuring out identity and path for frontend code is still a pretty great idea for similar use cases.

There are no shortage of Rails-driven sites thriving these days, meaning the technology is getting a lot of resources thrown its way. This has been the case for years, but I feel like the very successful launch of hey.com from the core Rails team of Basecamp is a real boon to the whole ecosystem.

I like Rails the technology, the API, the choices made, but I love the health of the ecosystem these days.

Collapse
 
alexlion profile image
Alex Lion

Come one ! I completely agree, Rails is most robust and mature framework I ever used. Battle-tested by Dev.to, Basecamp team (also Hey), Github...

It's worth it !

Collapse
 
ben profile image
Ben Halpern

Shopify, probably the biggest Rails user/driver from my perspective, is now a 100 billion dollar company and counting.

Collapse
 
gwutama profile image
Galuh Utama • Edited

I‘d write the backend in C++ or rust and optimize it as much as I can just to see how many requests it can handle on a 5 bucks VPS.

Collapse
 
umutakyol profile image
asdsadasf

Vanilla JS for frontend instead of React etc. Vanilla JS gives much more freedome to developer.

Collapse
 
patopitaluga profile image
Patricio Pitaluga

Plain HTML + CSS + Javascript with a very simple building system (something like concatenating the js files into bundles) should be enough for some projects and it's very much "against the trends". Nobody is coding like that.

Collapse
 
momander profile image
Martin Omander • Edited

I use pretty much what's in this list, except not Typescript and Vuex instead of Redux. I didn't know that lineup was popular. First time I've been trendy 🙂
Next I'd love to check out Svelte, for performance, if I can find the time.

Collapse
 
riidom profile image
riidom

For my blog, I first went with GravCMS+UIKit. But it was kinda slow, and while the backend is much less a mess than e.g. Wordpress, it still felt somewhat clunky.

On the second run, I wrote everything by hand, except using htmx.org, which is much faster overall.

Adding posts now involves: Writing it in HTML (thanks to emmet it is not that much worse than markdown, actually), update 2 nav sections manually, create a thumb for each image, and pick one image per post, and create 3 variations in different sizes for it. But that's ok either, I have some ffmpeg for that.
Wouldn't recomment that for frequent posting, but in my case it's ok.

Collapse
 
nicolus profile image
Nicolas Bailly

I just use PHP + Laravel to make websites. It works really really well.

If I need a Single Page App, then PHP + Laravel + Typescript + Angular.

I don't think your list is necessarily the accepted way of making new sites these days, it's just that people and companies who build websites with another stack don't go blogging about it because it's nothing new and everyone already knows it works well.

Collapse
 
alamantus profile image
Robbie Antenesse • Edited

Choo is my personal favorite framework because it's light and easy to understand. Then I always try to find the lightest CSS framework. My all-time favorite CSS framework is Bulma, but it's not very light, so I frequently reach for Picnic instead because it's got enough features and is very light! If I don't need anything fancy, I love the tiny lit+util library and frequently use my fork of it lighter+fuel.

In most of my (admittedly small) use cases, these tiny frameworks are more than plenty, and they tend to produce websites that download less than 100kb while still looking nice! In my opinion, more devs should aim to use smaller libraries and play bandwidth golf—sites that load nearly instantly because they're tiny are the best.

EDIT: Though most of the time I tend to just use vanilla JS and PHP. It tends to be easier and lighter overall!

Collapse
 
yannik_sc profile image
Yannik_Sc

I'm going full vanilla in my projects since I learned, that all major Browsers support ES6 Modules. It's just much faster for me setting a vanilla project having my type="module" on the script tag and just load JavaScript that is really needed. And for all (of my own) projects, that's enough. Adding some Web Components and I'm fine.

Also, when I'm using libraries, I just use small ones with just some functions. Saw a pretty neat library that builds HTML with tagged functions, which really only contains a single function + definitions. However I missed the name. But it was small and still very useful. This is what I want to develop. Plug'n'Play

Collapse
 
guitarino profile image
Kirill Shestakov

Preact instead of React. My own (MobX-like) state management instead of Redux. BEM instead of CSS-in-JS.

Collapse
 
merri profile image
Vesa Piittinen

I have one hobby project where I'm doing good old server side rendering on Deno + Oak + Preact + htm. No bundle building for server, and client JS will most likely be vanilla JS with page specific manually written scripts. CSS will be single file. No minification, no bundling, no code splitting. Doing stuff like that is way overkill for a small traffic service :)

Collapse
 
pontakornth profile image
Pontakorn Paesaeng

Your answer is same as me. I like Svelte and PostCSS in general.

Collapse
 
pomfrit123 profile image
***

Is this like pied piper?