dinoreic (u/dinoreic)

dinoreic commented on We moved away from web components – learnings from a Component-First DevTool corbado.com/blog/componen... · Posted by u/vdelitz

p0seidon · a year ago

> Also, if devs "want!" native components for React, Vue, etc., that does not mean Web components are bad, that only means devs want native components for their FW :).

You are right. For transparency, I also work for Corbado and was part of the discussion. I think most of the developers prefer a native component if they have a framework in use. In this case, because of the SSR trend, it's just a bit more difficult to use web components as a base for all of them. Would you not agree? Of course, you could offer native implementation in all variants, but that's very difficult.

dinoreic · a year ago

You are right, and your points on SSR where all good. If SSR is a must have, I do not know how to solve it. I see "riot.js" manages to do it, but I did not go into details.

dinoreic commented on We moved away from web components – learnings from a Component-First DevTool corbado.com/blog/componen... · Posted by u/vdelitz

dinoreic · a year ago

Long article, and I have to say that I do not agree with ~ 90% said.

Problem with web components is that they have a few gotchas, one has to solve it he wants to use them effectively. I agree that SSR is a problem, if it is a problem. Crawlers now render JS, I have not see any benefits of SSR for a long time now.

Also there are a lot of mentions of Shadow DOM. Why would anyone want to use that? It is slower, detached from main process. Just use original DOM and modify it.

Also, if devs "want!" native components for React, Vue, etc., that does not mean Web components are bad, that only means devs want native components for their FW :).

I personally hacked my Web components micro FW in 2 weeks, and started to replace Svelte and Rails/StimulusJS with it. I am every happy, but you need to know how to handle gotchas.

dinoreic commented on Rails 7.1 Released github.com/rails/rails/re... · Posted by u/sathishmanohar

michaelteter · 2 years ago

And chances are, new Rails projects will just be API backends with React frontends.

Also, if trying to do lightweight Javascripty frontends within the framework is important, we might as well just move to Phoenix. Phoenix is arguably better already... it just requires a moderate jump to learn Elixir (which unfortunately looks very much like Ruby but requires a very different approach to writing).

dinoreic · 2 years ago

Phoenix is super fun, but it is in completely different realm than rails :)

What about all the gems Ruby has, does one really have all he needs inside Elixir/Erlang? More complex stuff like NokoGiri, Haml, etc., that works well and is maintained.

dinoreic commented on Rails 7.1 Released github.com/rails/rails/re... · Posted by u/sathishmanohar

dinoreic · 2 years ago

I am Rails dev, and I don't like the fact that Rails in every new version has to REINVENT ALL THE WHEELS, ALL THE TIME. That creates huge problems for Rails devs and stakeholders.

Rails is based on Ruby, which is backend language, and Rails should stay more on backend.

That means

  - session management
  - routing and controllers
  - many API options (REST, json-rpc, ...) + JSON object exporters
  - ORM, Mailing, etc
  - server template renders (ViewCells are still not part of Rails)
  - tasks, logging and other helpers

In the same way Rails adopted rake gem as default task runner, without re-inventing it as "ActiveCliTasks", they could have created standardised connector layer that will exchange objects between backend and frontend.

So no Stimulus, TurboLinks, HotWire and other stuff one HAS TO learn and re-learn between versions. Svelte, Vue and React should have been officially supported with thin connectors. Rails server render layer can easily be integrated in any existing frontend tech, as alternative to React server components insanity.

Also, there is no reason to have to have socket connection to pass HTML between server and client, good old RPC is just fine as 99% of big app scaling problems are Database problems, no need for another layers of complexity one has to ensure it works.

I think, in that way Rails could "shine" far into the future, using its strong points but adopting new frontend stuff on the way, not re-inventing it all the time.

dinoreic commented on Server-side rendering is a better choice for many applications (2020) timr.co/server-side-rende... · Posted by u/krab

xu_ituairo · 2 years ago

Do you mean something similar to Svelte becoming dominant?

dinoreic · 2 years ago

I can't understand how Svelte is not more popular. From first time I saw it 4y ago I thought it was game changer, did not change opinion.

dinoreic commented on An Introduction to APIs zapier.com/resources/guid... · Posted by u/teleforce

dinoreic · 2 years ago

REST is for noobs, JSON RPC is silent pro's choice :)

Make all requests POST and enjoy easy life without useless debates on should creation of resource be on POST or PUT or should you return HTTP status 404 or 200 if resource/document on server is not found (of course if should be 200 because request was a success, 404 should only be used it api method is not found).

I 100% agree with Troy Griffitts beautiful take https://vmrcre.org/web/scribe/home/-/blogs/why-rest-sucks

dinoreic · 2 years ago

Thank you all for the great comments.

I want to emphasize that I was not thinking about JSON RPC as a specific protocol, but more as a JSON format to transfer data, similar to how REST APIs usually do, and some kind of "HTTP method agnostic remote procedure call", it does not have to be JSON RPC standard.

Personally, I am a fan of just having API Class-es + methods that automatically map to API calls with automatic api interface and doc builders. I find that it would be super strange if I had to prefix my internal methods with DELETE or PUT based on do they remove or add to some Array. Using that logic, why do that in APIs.

I just find it super strange that people want to mirror their app logic + error response codes to some protocol like HTTP – ridiculous :) Why not go even lower as TCP and use some of that spec for our client <> server API conn. Many people will laugh, but if you think about it, where is the difference?

dinoreic commented on An Introduction to APIs zapier.com/resources/guid... · Posted by u/teleforce

dinoreic · 2 years ago

REST is for noobs, JSON RPC is silent pro's choice :)

Make all requests POST and enjoy easy life without useless debates on should creation of resource be on POST or PUT or should you return HTTP status 404 or 200 if resource/document on server is not found (of course if should be 200 because request was a success, 404 should only be used it api method is not found).

I 100% agree with Troy Griffitts beautiful take https://vmrcre.org/web/scribe/home/-/blogs/why-rest-sucks

dinoreic commented on Amazon moves employees out of downtown Seattle office due to crime geekwire.com/2022/amazon-... · Posted by u/ghostoftiber

dinoreic · 3 years ago

Ban begging and sleeping on a streets, make huge homeless shelters on outskirts of a city and provide basic healthcare to those people in need.

Is it that complicated and costly compared to this shame? USA people are so strange.

dinoreic commented on Rails is not written in Ruby solnic.codes/2022/02/02/r... · Posted by u/tanyar

overgard · 4 years ago

So like, I guess the thing I don't understand is this: why do people think writing:

some_array.has_my_thing() is better than has_my_thing(some_array). ?

The former, the extension has so many issues, it messes up namespacing, it's unclear where it came from, etc. etc. The latter is just a function. It's not longer, or complex, it's just more straightforward. I really think things where you extend or override built in types is almost always just a bad idea, because the alternative is almost always just as concise and doesn't confuse everyone.

dinoreic · 4 years ago

Because it is baked into the class itself. Ruby is global variables "fiesta", because all classes and modules (and functions that begin with first uppercase letter) and became global once loaded.

Because of that, you can not have 2 parallel versions on the same lib, in the sane app, not possible. You load classes once, and they are accessible everywhere, magic! No need for loader headers as in JS, Python, Java, Go, ...

That said, ruby devs like to have "sane" extensions like to_json. People proffer to write "@object.to_h.to_json" instead of "JSON.parse(@object.to_h)" and not to think about loading json lib. I agree that Rails is abusing this too much.