HN user
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.
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.
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.
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
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.
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.
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?
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
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.
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.
I think point guy tried to make is, that ton of big companies, that would/could benefit from in-house solution still go for full cloud based one without thinking about alternatives.
I assume readership base per particular publication is lower then before plus when in open market they get lower $ for x views then they used to.
I cant understand how a developer can be aware of existence of Svelte (https://svelte.dev/) and still have React problems.
Just start with creating web components in Svelte, include them in existing React code, and slowly phase out slow, and old tech that React is. This is just frontend lib, why are people so religious about this. You still use Node, JS/TS, etc.
Im I troll? Don't know, but that is just what I did year ago. Now I just laugh when I see articles like this, buy I also feel sad for small entrepreneurs that have to pay big $ for code in "dated tech" - thinking "they are on the edge".
I created Ruby API lib named Joshua, out of frustration with Grape
* Can work in REST or JSON RPC mode.
* Automatic routing + can be mounted as a Rack app, without framework, for unmatched speed and low memory usage
* Automatic documentation builder & Postman import link
* Nearly nothing to learn, pure Ruby classes
* Consistent and predictable request and response flow
* Errors and messages are localized
Location: European Union
Remote: Yes
Willing to relocate: Nope, but I can visit on a monthly basis and stay up to 2 weeks
Technologies: Ruby (on Rails, Solidus), JavaScript (React, Vue, Svelte), PostgreSQL, AWS, HTML/SCSS, HTTP, Microservices
Résumé/CV: https://www.linkedin.com/in/dinoreic/
Email: reic.dino@gmail.com
I'm a seasoned expert with 15+ years of experience building my own web products and helping other companies do the same, both remotely and on-site (US and EU).
For the last 10+ years, I held numerous team lead positions and have worked with both early-stage startups and large established companies. I have a lot of experience with scripting languages, micro-service architectures, server setups, and the web in general.
I'm available for both part and full-time contracts starting next week.
I'm a seasoned expert with 15+ years of experience building my own web products and helping other companies do the same, both remotely and on-site (US and EU).
Specialities: Ruby (on Rails, Solidus), JavaScript (React, Vue, Svelte), PostgreSQL, AWS, HTML/SCSS, HTTP, Microservices
For the last 10+ years, I held numerous team lead positions and have worked with both early-stage startups and large established companies. I have a lot of experience with scripting languages, micro-service architectures, server setups, and the web in general.
I'm available for both part and full-time contracts starting next week.
Get in touch: reic.dino@gmail.com | https://www.linkedin.com/in/dinoreic/