Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 18 submissions in the queue.
posted by janrinok on Wednesday February 09 2022, @11:08PM   Printer-friendly
from the all-the-better-to-track-you-with-my-dear dept.

Move over JavaScript: Back-end languages are coming to the front-end:

In the early days of networked computing, mainframes did all the heavy lifting: users connected to massive machines with video terminals that could do little more than send and receive text. Then in the 1970s, personal computers came along and made it possible to do serious computing on the client-side as servers handled tasks like authentication and storage in many networks. The rise of the internet in the 1990s swung the pendulum back to the server, with web browsers taking on a role not unlike terminals in the mainframe era.

The client-side made a come back over the past decade as developers built "single-page applications" (SPAs) with JavaScript. But a new crop of tools is sending the pendulum swinging back towards the server.

At the vanguard of these tools is Phoenix, a framework for the programming language Elixir, and a feature called LiveView. Using LiveView and a bit of JavaScript, developers can create browser-based interfaces for real-time applications like chat rooms or Twitter-style status updates. All UI elements are rendered on the server first and sent to the browser, ready-to-display. The only JavaScript required is a small amount of code that opens a WebSockets connection that handles sending input from the browser and receiving refreshed HTML/CSS from the server.

Phoenix isn't the first platform to offer a way for back-end developers to create front-end interfaces—Microsoft's ASP.NET Web Forms for Microsoft .NET existed back in 2002—but it did inspire many new tools. Caldara for Node.js, Livewire for the PHP framework Laravel, and StimulusReflex for Ruby on Rails, to name a few. Microsoft, meanwhile, released a new .NET feature called Blazor Server that modernizes the old Web Forms idea.

"My goal is not to get rid of single-page applications, but to obviate them for a large class of applications," Phoenix creator Chris McCord says.

There is a lot more in the full article.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by HiThere on Thursday February 10 2022, @04:13AM (3 children)

    by HiThere (866) Subscriber Badge on Thursday February 10 2022, @04:13AM (#1220132) Journal

    IIUC Elixir is a dialect of Erlang, or possibly "front end" would be a better description. And it's not new.

    --
    Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 1, Informative) by Anonymous Coward on Thursday February 10 2022, @09:16AM (2 children)

    by Anonymous Coward on Thursday February 10 2022, @09:16AM (#1220156)

    Elixir is not a dialect of Erlang. They have a couple of fundamental differences that will make the two forever incompatible. But they both use BEAM as their reference implementation's virtual machine. They have a lot of the same benefits and drawbacks because of that and the underlying "feel," for lack of a better word, is similar too. However, there are some large differences. Because Elixir is sort of the child of Erlang and Ruby, it is more flexible in how you write it (And thank goodness for the pipe operator) and is great for web-facing code. Because it has the benefit of hindsight, it also prevents problems that could arise in Erlang before they happen while the changes introduce problems of its own. Erlang, on the other hand, is more versatile because you can use it for more things thanks to its standard library and interfaces without relying on code flexibility to get there. Erlang also has other benefits Elixir doesn't because it was designed for different use cases, particularly in CPU-bound tasks.

    • (Score: 1, Interesting) by Anonymous Coward on Thursday February 10 2022, @12:59PM (1 child)

      by Anonymous Coward on Thursday February 10 2022, @12:59PM (#1220171)

      Erlang also has other benefits Elixir doesn't because it was designed for different use cases, particularly in CPU-bound tasks.

      IIRC, designed with lightweight threads for use in packet switching and routing. Erlang would be a contender for distributed caches and message queues but what is the advantage of BEAM for the use case of Elixir you're making?

      • (Score: 2, Informative) by Anonymous Coward on Friday February 11 2022, @12:13AM

        by Anonymous Coward on Friday February 11 2022, @12:13AM (#1220377)

        Elixir was originally targeted for client/server architectures, for web applications, and similar constructs. Therefore its reference implementation was written with that in mind. The BEAM VM is great for that kind of workload because of its lightweight threads, distributed concurrency and fault-tolerant (let it crash) design, and soft RT capability. It is in many way similar to the "async" mania that swept through other languages. Except this implementation is mature, well-tested, and scales both directions insanely well. The problem is that because Elixir was written with the assumptions underlying those targeted use cases, it suffers in others. One of those where it really suffers is in tasks that are CPU-bound and not IO-bound. That isn't to say that it is forever a problem or completely intractable, but it is the cost-benefit analysis they made when designing it.

        Perhaps I didn't answer your question, so feel free to rephrase it if I didn't.