Not seeing ClojureScript in there... feels a bit weird... One would think, CLJS is more or less, back-end lang brought to front-end
Back-end languages are coming to the front-end
41–50 of 328 posts
Re: Back-end languages are coming to the front-end
#42See CLOG, the Common Lisp Omnificent GUI - a recent project which is an implementation of this paradigm. https://www.reddit.com/r/lisp/comments/s1itqi/the_common_lis... https://www.reddit.com/r/lisp/comments/sd9wf1/clog_builder_c...
Unfortunate naming.. "I CLOGed my frontend"
"I Reacted my frontend"?
"I AngularJSed my frontend"?
"I VueJSed my frontend"?
I just don't see it.
Re: Back-end languages are coming to the front-end
#43Re: Back-end languages are coming to the front-end
#44Earlier quoted context omitted.
Agree. Specifically on the point of "clear, documented and maintainable" I think this is where languages such as Ruby (and therefore Rails) shines. Since it was "optimized for developer happiness" ( https://news.learnenough.com/ruby-optimized-for-programmer-h... ) it's more likely to be easier to understand, document and maintain.
Unfortunately in practice, there is so much ruby/rails magic going on that most Rails projects end up in terrible shape. It's kind of a catch-22, and tons of companies have overcome it, but rails by far has the "least long term maintainable" defaults. Good for quick prototypes/small teams but bad for large and scaling teams
Re: Back-end languages are coming to the front-end
#45How do these tools work? Are they like ASP.NET Webforms?
The benefit here is that we can get to a place that is almost a SPA without needing to do a whole lot of JavaScript for the Frontend. It also helps that Elixir is built on top of Erlang which gives it a boon to be able to handle a lot of users on one server.
Re: Back-end languages are coming to the front-end
#46When is the world of software going to wake up? All programming languages suck, in one way or another. All frontend/backend paradigms suck, in one way or another. This constant churn of new, new, new is a waste. It gets replaced every few years, meaning all the time, effort and money sucked into it is gone. And engineers re-learn the same lessons over, and over, and over again. All so software engineers can be happy,…
After having been in this industry for 20+ years, I can pretty confidently say the world of software will never wake up. It's just been an endless cycle of adding abstractions, removing them again, using back end languages on the front end, using front end languages on the back end, using relational databases instead of a key value store, using key value stores instead of a relational database, unit tests over integr…
A few decades of programming has taught me that cool technology inevitably turns out to be janky and annoying and half-finished.
Re: Back-end languages are coming to the front-end
#47I am surprised that there are no browsers that can support other languages. My ideal architecture is to have a browser where you can select your front-end language interpreter, as in a Chromium + V8 + CPython + Whatever front-end processor you might want (Brython[0] achieves this, but transpiling to JavaScript).
What doesn't make sense to me is that JavaScript has genuinely been the only language for the front-end, and it has been a monopoly for many years. Of course, there are other great languages like TypeScript, but these end up anyway transpiled to JavaScript, which to me feels like mounting your skyscraper over dunes. Not to hate on JavaScript, but JavaScript has grown too quirky for my tastes and that's why I've been away a lot from front-end development.
There are efforts to fix it, with the new ECMA standards, but I don't feel it's going anywhere unless breaking changes are introduced to modernize the language. The fact that you have to "patch" your scripts with 'strict mode' on the top of the file speaks a lot of being defensive with programming.
WASM is a solution to this, except you're not supposed to write WASM yourself. I want web development to be more straightforward, like the old days, where you didn't have to "compile" or "package" anything, and you just did your thing, and that worked.
--
Re: Back-end languages are coming to the front-end
#48When is the world of software going to wake up? All programming languages suck, in one way or another. All frontend/backend paradigms suck, in one way or another. This constant churn of new, new, new is a waste. It gets replaced every few years, meaning all the time, effort and money sucked into it is gone. And engineers re-learn the same lessons over, and over, and over again. All so software engineers can be happy,…
If you can only see the churn and froth, that doesn't mean there aren't great waves to surf; you might just need to paddle out to a better spot. https://remix.run is a prime example. It's new, and better, and simpler.
It also equalizes the playing field every few years, you become an expert in the latest new thing as there isn't an old guard. Some new web framework comes along, you can invest in that and become leet, where its very difficult to start new in react today and achieve that.
This isn't to say past experience isn't valuable or helps you adopt things more quickly, can make you cynical about the new shiny and sometimes miss out on the actual improvements, even if small. I
Re: Back-end languages are coming to the front-end
#49I love Blazor and I think this concept of using one language to write the front and back-end will be the standard way of doing SPA.
I do dearly hope Blazor works out - I would be so happy to never have to deal with the Javascript/Typescript tooling hell ever again - but I'm not holding my breath. Political shifts inside Microsoft could leave it dead and unsupported like Silverlight tomorrow...
Re: Back-end languages are coming to the front-end
#50I don't think this is really about programming languages. The world of software (and specifically everything network based) is oscillating between fat servers and fat client every few years or so. To me the innovation seems to be orthogonal to this cycle and may actually be accelerated by this continuous change in perspective. Which is good!
This is the irony, Erlang/Elixir, despite being functional language with less and highly restricted access to stateful side effects, is really FANTASTIC at safely holding onto state and persisting it for the user, and making that model digestible for the developer.