Live data from Hacker News

Don't make me think, or why I switched to Rails from JavaScript SPAs

reviewbunny.app

231–240 of 490 posts

Re: Don't make me think, or why I switched to Rails from JavaScript SPAs

#231

SPAs are the "Google-scale" of frontend tech. YAGNI unless you are Big (or trying to fleece VCs). SPAs are useful where the latency and overall UX of a button press can be translated to some tiny % increase in a KPI through A/B testing, etc. Where you want to track user behavior down to a pixel & microsecond, and wrapping every element in JS is the only way to get there. This is frankly irrelevant to 99% of projects…

SPA's need not be complex nowadays. I use https://lit.dev 's templating engine. When I want something simple, I use just the templating engine not the full web component framework.

Lit's templating engine is just html that is made super efficient to render because only parts that change are re-rendered. There is no inter language to learn like JSX. It uses native browser html parser, native browser templating capabilities ( tag), native event handling and native literal template capabilities of javascript.

I have a simple wrapper class that renders and composes components efficiently and reactively when state changes. The views look like:

  class TestView extends LittleLit {
    static get properties() {
        return {
            paramter: {}
        };
      }
    constructor(){
        super();
        this.el=document.querySelector('#main');//root component attached to the dom

        this.subcomponent=new SomeView();
    }
    render(){
        this.subcomponent.somestate=this.somestate;//propagate state down if necessary.

        let h=html`Hellow ${parameter}${subcomponent.el}`;
        render(h, this.el,{host:this});
    }
  }
To use

  v=new TestView();

  v.parameter='world';//this triggers rendering if the parameter changed.
Here is my whole framework:

  class LittleLit {
    constructor() {
        this.el=document.createElement("div");
        this.refreshScheduled=false;
        this._properties={};

        let properties =this.constructor.properties;
        if(properties!==undefined){
            for (let prop in properties) {
                this.property(prop,properties[prop]);
            }
        }
    }
    refresh(){ //you can call refresh to trigger rendering efficiently
        if(this.refreshScheduled===false){
            this.refreshScheduled=true;
            window.queueMicrotask(()=>this._update());//deduplicated rendering in an efficiently scheduled microtask
        }
    }
    _update(){
        this.render();
        this.refreshScheduled=false;
    }
    property(name,options){
        Object.defineProperty(this, name, {
            set(v){
                if(this._properties!==v){ //refresh only if property changed
                    this._properties[name]=v;
                    this.refresh();
                }
            },
            get(){return this._properties[name];}
        });
    }
}

Most of the power comes from the templating library: https://lit.dev/docs/templates/overview/

Re: Don't make me think, or why I switched to Rails from JavaScript SPAs

#232
Rails and Ruby bake in a lot of really nice, ergonomic features for every day programming, not just larger architectural decisions. For instance I am working on a React Native app in my spare time and so much of Javascript seems tedious. Example is dealing with date ranges.

Contrived example:

  import { isWithinInterval, subDays, addDays } from 'date-fns';

  const today = new Date();

  let range = { 
    start: subDays(today, 1), 
    end: addDays(today, 1)
  }

  isWithinInterval(today, range)
The functions for this kind of calculation has to be imported into any file I want to use them? There seems like a lot of copy pasting of this kind of stuff everywhere in a robust javascript app. I think it's reasonably easy to read and understand, so I don't fault that, it just seems tedious to use tons of libraries that you have to explicitly import everywhere to accomplish simple things. Feels like death by a thousand cuts.

Meanwhile in Ruby (with Rails) this is functionally equivalent and is usable everywhere in the code:

  Range.new(Date.yesterday, Date.tomorrow).include?(Date.today)
edit: fixed some bugs :)

Re: Don't make me think, or why I switched to Rails from JavaScript SPAs

#233

Earlier quoted context omitted.

Yes, I have. With a proper backend language like Go it is trivial to manage concurrent WebSockets and arbitrary data across them.

On whatever page you're using websockets, you're basically doing what an SPA does. If you click something and the page sends and receives a message via websockets and then updates the DOM, congratulations, you have something that's the same level of complexity as a SPA. Your original post says that this style of interaction only exists to "fleece VCs". But it seems you're doing that, with an additional added layer of…

And SQLite is "basically" doing what Hadoop does.

Except not really, because one is architecturally simple and relatively easy to grok/hack, and the other is big and complex and built specifically for operating at a massive scale and multi-team environment.

We're talking ~200 combined LOC of idiomatic Go+TS & a couple popular libraries vs. an entire SPA framework and its various DSLs.

State synchronization over a long distance is always going to be a balancing act of performance vs. reliability vs. security. It's never simple and outsourcing those decisions to a framework is not always the correct choice as it may bite you later.

Re: Don't make me think, or why I switched to Rails from JavaScript SPAs

#234

Google searches for React and node.js exceed searches for Ruby on Rails by 100% and 50%, respectively [1]. Some people have used this to argue that React/node are more popular than Rails. But I wonder if perhaps this discrepancy appears in Google Trends because it takes more google searches to accomplish the same thing in React/node versus Rails. I feel the Rails ethos of "convention over configuration" allows me to…

There was a lady in one of my previous projects whose job was to maintain the integrity of sensitive financial data (she was doing a lot by hand, as they wanted a human to check every number). In the 2 years or so I worked there, there was not a single mistake from her. I didn't hear much appreciation for her from others, but my CTO used to call her the most important person in the company.

Some tools, some people just work, just do their job quietly and efficiently. They do not get any appreciation, precisely because they are too efficient and go unnoticed. JS is not one of them for sure.

Re: Don't make me think, or why I switched to Rails from JavaScript SPAs

#235

Earlier quoted context omitted.

> There is no such thing as "the node way". And thank fucking god for that. It turns out there's no such thing as "The one way" - it's a choice for a reason: It has consequences and trade-offs that are applicable to your goals. If it turns out your goals are a very simple crud app for a team of under 5 - Rails is probably a great choice. For most everything else, you should probably understand why Rails made the choi…

> And thank fucking god for that. It turns out there's no such thing as "The one way" - it's a choice for a reason: It has consequences and trade-offs that are applicable to your goals. That comes with a downside though, which is that for any given problem there won’t necessarily be an ultra-well-supported “happy path” where every conceivable problem has long been documented along with a solution. To me the lack of h…

If you're just doing something so simple that "every conceivable problem has long been documented along with a solution." then you're using the wrong tool if you're programming anything at all.

Problems that fall into that space are usually better served by simple site builders (Wix/Square/Shopify/Wordpress/etc).

Re: Don't make me think, or why I switched to Rails from JavaScript SPAs

#236

Earlier quoted context omitted.

The issue I have with the JS world is that the most used libraries and frameworks are just "good enough for a small project" and no more than that. * Javascript has such a minimal standard library, you will need to get one or three third-party libraries to augment its core. * React is an excellent view library and nothing more. You will need to get one or three third-party system to turn it into a fully fledged web f…

"Javascript has such a minimal standard library" My hope is that this has been/will continue to change over time, is this a fare statement? Does anyone know if the various working groups (e.g., WHATWG, W3C, etc.) have the goal of making the JavaScript more robust? My vision is that the standard, built-in APIs would serve as a minimum viable platform that you can build simple to moderately complex applications in with…

The working group most in charge of JS is ECMA's TC-39 (TC => Technical Committee) [0]. They've been taking a very deliberate, slow path to expanding the "standard" library because they take a very serious view of backwards compatibility on the web. Some proposals were shifted because of conflicts with ancient versions of things like MooTools still out in the wild, for instance. (This was the so-called "Smooshgate" incident [1].)

This may speed up a bit if the Built-In Modules proposal [2] passes, which would add a deliberate `import` URL for standard modules which would give a cleaner expansion point for new standard libraries over adding more global variables or further expanding the base prototypes (Object.prototype, Array.prototype, etc) in ways that increasingly likely have backwards compatibility issues.

TC-39 works all of their proposals in the open on Github [3] and it can be a fascinating process to watch if you are interested in the language's future direction.

[0] https://tc39.es/

[1] https://developers.google.com/web/updates/2018/03/smooshgate

[2] https://github.com/tc39/proposal-built-in-modules

[3] https://github.com/tc39/proposals

Re: Don't make me think, or why I switched to Rails from JavaScript SPAs

#237
post #121

Earlier quoted context omitted.

Agree, and to go further (from the point-of-view of an outsider who is forced to do JS occasionally): * should I use npm or yarn? Why do I see most package authors recommending yarn when npm is the default as far as I know? * should I introduce Typescript to be able to handle complexity better? * which module system? I see lots of "require" VS "import", if it needs to work on browser/node.js/deno, which one?!?! * whi…

The answers to this in 2022: 1. Doesn't matter so much as long as you're using newest versions of either one. Newest yarn has plugin support which is neat. Npm has more stable backing and an open roadmap. Could be some considerations regarding monorepo support, but otherwise either is fine. 2. Yes 3. Use ES6 modules 4. Jest + Cypress 5. Vite

I agree with this persons answer, if your goal is to go full custom. If you want all this setup done for you I suggest NextJS. It should be noted that Deno is not a bundler but an entirely different JS Runtime. The question should be do I use Node or Deno.

Re: Don't make me think, or why I switched to Rails from JavaScript SPAs

#238
post #190

Earlier quoted context omitted.

>Maybe 5-10 years ago, there is no need anymore Is still either create your own or install a random package that brings other 20 as dependencies. Example, you want to show an Alert or Yes/No popup, This are built-in everywhere but n Web world you need to review and install a third party thing, or create your own buggy or incomplete implementation. Maybe you want modal dialogs, this is a standard in GUI tookits but yo…

> As a language JS progressed a lot, so much I am not sure if switching to TS is a good idea or I just need to wait until JS will catch up with TS. Can you elaborate on this? TS is just adding type checking to JS, the only runtime addition are enums. I doubt that JS will incorporate type checking anytime soon. I mostly agree with your other points.

I like to use class in JS to have types, some features are still missing in the major browsers like interfaces, some static stuff (I forgot), I miss the private and protected keywords , my IDE can show me errors for using the wrong types or even from JSDoc documentation but JS needs a standalone compiler/checker that will detect type errors at "compile" time.

Re: Don't make me think, or why I switched to Rails from JavaScript SPAs

#239

Rails and Ruby bake in a lot of really nice, ergonomic features for every day programming, not just larger architectural decisions. For instance I am working on a React Native app in my spare time and so much of Javascript seems tedious. Example is dealing with date ranges. Contrived example: import { isWithinInterval, subDays, addDays } from 'date-fns'; const today = new Date(); let range = { start: subDays(today, 1…

Not copying and pasting that code chunk and wrapping it into a utility function :red-flag: :red-flag: :red-flag:

Re: Don't make me think, or why I switched to Rails from JavaScript SPAs

#240
post #121

Earlier quoted context omitted.

Agree, and to go further (from the point-of-view of an outsider who is forced to do JS occasionally): * should I use npm or yarn? Why do I see most package authors recommending yarn when npm is the default as far as I know? * should I introduce Typescript to be able to handle complexity better? * which module system? I see lots of "require" VS "import", if it needs to work on browser/node.js/deno, which one?!?! * whi…

This really hits home for another JS outsider that likes the language but not the ecosystem. I like to do small personal projects in Node. Simple things like consuming the Google Sheets API feel great, but when I want to expand the scope of the project and start thinking about tests, caching, and "am I doing my modules/imports/package management the RIGHT way" I usually give up or switch to a different stack.

Have you tried Deno? if you hate setup and want it all to just work. I highly suggest it.
Post reply on HN