J Language web programming - j

Is there a web framework to create websites using J on a server? Last time I checked there was a simple CGI package with tagged J code in line. Are there any plans to offer something more comprehensive?

Related

ServiceStack SharpScript Future

Good day, I've been using ServiceStack for many years, I currently designing and planning a rewrite of an ASP MVC (Razor) project. #Script seems to be an almost perfect fit, without hands-on experience of the technology I have some doubts and questions.
My question is how relevant is #Script today and what is the future plans of this technology. I ask these questions because when I looked at GitHub example I noticed that there is not a lot of activity, and searching the internet I am also not finding a community around it.
As #Script's author I would say that #Script is a complete library for what it's designed for as an embeddable sandboxed .NET scripting and templating language that's ideal for exploratory programming with seamless integration into .NET APIs (including Win32 APIs) that includes a vast built-in library (1000+) of filters that's easily and highly extensible to the point that it's even able to natively support multiple languages (inc. built-in LISP Repl) within the same page that's been a joy to develop with thanks to its built-in Hot Reloading support where changes are instantly visible upon save - so technology-wise IMO it's pretty great.
If we were to compare it to comparable libraries in other languages like the Ruby's Liquid it should be pretty clear that #Script is vastly more capable where it scales from a user-friendly templating language to a powerful scripting language where it's capable of developing entire Windows Desktop Apps that fits in a Gist.
On the activity front, Liquid is also an established library with low activity with only a handful of commits in 2021, the difference is that it's vastly more popular and used in popular products like Jekyll as used in GitHub Pages which ensures it will always have a rich, vibrant ecosystem which is the most important indicator for assessing a technology's longevity.
Technology not as important as ecosystem
However in the end the technology doesn't matter nearly as much as its user base, community and ecosystem behind it which is where #Script is sorely lacking. Unfortunately this is the reality of libraries that compete Microsoft's defaults like Razor which are exclusively promoted for .NET and will always retain the majority of adoption in .NET.
#Script is a "complete" library in that I've added all the features I planned for it and there's basically nothing I can think of to add to it to make it more appealing, but facing the realization of its indefinite lack of adoption I wouldn't recommend using it for large living (i.e. multi-year) Websites, given it will never have the community and adoption enjoyed by other ecosystems since the benefits of a community and ecosystem are ultimately the most important attributes in order to continue investing in a technology.
Continue to be actively supported
Like all of ServiceStack, #Script is still an actively supported library with no outstanding issues so it's safe to use in that any issues will be promptly resolved should you wish to.
Website Development Recommendations
I'd say it's still a fine option for smaller definitively-scoped projects since its compile-time-free and Hot-Reload makes for a very productive Dev UX for server-generated dynamic pages. However even then I'd first evaluate if a static generated framework like Jekyll, Hugo or other popular static generators would be more appropriate since they enjoy a vibrant community and a statically generated site results in a more performant, resilient and cheaper to host and deploy website.
Static Site Generators
Having recently redeveloped the servicestack.net website to split it out into using Jekyll for static content and ServiceStack.Razor for dynamic content, my recommendation for large websites with large static and dynamic components is to use a static site generator for its static content which yields several benefits:
Although it does require a fair bit of overhead to setup as you're effectively maintaining 2 different websites however it greatly benefits if the static content is actively updated as there's a lot less friction to change and update content on a static generated site then a dynamic one and it results in a superior end user UX thanks to CDN Edge caches that's also cheaper to host from free sites like GitHub Pages and Netlify.
In order to preserve existing URLs we needed extra functionality not possible from a static host so our static content is deployed to a S3 bucket where we use CloudFront for CDN edge caching, CF Behaviors for proxying "external static" routes to our .NET5 dynamic website and a CF Function for supporting pretty URLs. For internally deployed websites you'll be able to accomplish similar functionality with reverse proxy and redirect rules.
SPA or Razor
For small websites or mostly dynamic websites that wont benefit from a content site split I'd recommend either an SPA Project Template if you prefer TypeScript and an established SPA FX like Vue, React, Svelte or Angular or Razor or MVC if you instead prefer C# server generated websites.
Progressive Enhancement
My personal preference is for read-heavy dynamic sites to use ServiceStack Razor utilizing API First Development approach so that all writes are made to the same clean ServiceStack APIs that Mobile and Desktop Apps would also call. This typically involves using some kind of progressive enhancement like our Client TypeScript Validation example which utilizes the Form & Validation Binding in #servicestack/client to take over <form> submissions to perform TypeScript API calls and apply any validation errors back to the Form's UI.
The Client jQuery example accomplishes the same thing without the tsc -w watched build step whose form & validation binding utilizes the older jQuery ss-utils.js library but it does mean you'd need to author logic in an older broadly ECMAScript 5 supported version of JS.
Future of #Script
As I don't expect #Script Pages will ever achieve any meaningful adoption required for self-sustained active development, it's unlikely we'll continue in investing in further development for usage in dynamic websites (i.e. the script project template), it's a complete and extensible library so further development isn't strictly necessary as it can be easily extended with your own local Plugins, Methods, Transformers and Blocks. But it does mean we're unlikely to be creating and including new methods/plugins designed for dynamic websites in the library OOB.
Still a critical ServiceStack component
#Script is still a critical component of ServiceStack where it's used to provide integrated SPA templates since it's able to render dynamic websites from static *.html pages in npm dev hot-reload servers which can't use Razor's *.cshtml pages. It's also what makes ServiceStack's Declarative Validation possible where validation rules can be defined on dependency-free DTOs as it allows defining binary-decoupled logic in dep-free attributes. It's also what makes vuedesktop.com Desktop Apps like ServiceStack Studio possible as well as command tools like Post Command - HTTP API Command Line Utils and cross-platform dotnet scripts which makes usage of its internal functionality, so it's going to continue on as a actively developed & supported library.
Good future use-cases of #Script
However I'd limit any #Script usage to where it excels, e.g. as an embeddable scripting .NET sandbox given it's more versatile & flexible than Razor for tasks like Rendering Emails, authoring & rendering Live Documents (e.g. if needing to maintain live user-generated reports in an RDBMS) or as an embeddable Template, JS or LISP DSL or for evaluating adhoc JS/LISP Expressions or .NET logic.
Future replacement project templates
For developing server-generated websites with ServiceStack we're looking at shipping a couple of new templates which encompasses our latest recommendations (e.g. embracing an API First Development style), if they result in a great Dev UX we're looking at:
An Integrated Static generated (e.g. Hugo/Jekyll) + Dynamic Project template
An API First MVC Pages + ServiceStack template with integrated progressive enhancement
Please follow #ServiceStack to get notified as soon as they become available.

Ideal programming language

I am new to programming but I would like to create a web app.
Basically, I would like to upload an excel file to that app that will use that file, do some calculation and prompt some forms that I will be able to download. I am thinking about a web app because I would like anybody else to be able to create a session and use the app.
Which language should I use please? I attended 2 semesters of c++ and a data structures class.
thank you for your help
I think any Programming Language suitable for web applications can fulfill the requirement with standard library and external modules
Now for the choice, if the calculations are complex and require extensive Math and Statistic Libraries Python would be ideal ( With Flask or Django for exposing functionalities As a web app)
Otherwise, a light and Cloud-Native language such as Golang would be also nice.

Building an App in SharePoint Online

I have a client that wanted an easier way for his team members to build/update pages on their site, their site is heavily customized with a lot of JavaScript. The issues is that when a team member wanted to add a new section to the page they had consult a dev person to hard code in the desired features. So we decided to create customizable web parts of those features making the site more self-serviceable.
When I first started I found some documentation that said to use visual studios to build the web part using sandbox code, upload it to the site and then they would just need to activate it to deploy it on the site. Buuut unbeknownst to me code based sandbox solutions are no longer supported in Sharepoint and therefore the web parts we built could not be deployed. I was then told that I needed to build it as an Add-in, but as I started building the add-ins I found that the customizable field properties (i.e. ability to change background color, text style/color and banner color) that I want are not implementable as a add-ins.
So now I’m back at square one and I don’t know if it’s even possible to build a web part as a add-in or do I need to go a different route?
Any thoughts or links to sources you can provide would be HUGELY appreciated!
Thanks
Terek
In SharePoint 2016 things have changed a lot from the traditional model which was the classic way of building web parts. The way you worked before is called "classic", the new way is called "modern", and the way to get your dev environment is the following (brace yourself, it is a long answer):
1) In SP2016/Online you will need to configure your dev machine with the following environment, installing the following:
NodeJS Long Term Support version
Yeoman (which will be used to create web parts)
GULP (which will play the role of virtual web server)
Once the three components above are installed, you will install the Yeoman SharePoint Generator to create the SharePoint Web Parts, Yeoman simplifies the process of creating things by delivering templates ready to use and making all the configurations standard, you gonna love this guy!
To configure your machine see the following link:
https://dev.office.com/sharepoint/docs/spfx/set-up-your-development-environment
2) In SP2016/SP Online, you will develop for SPFx (SharePoint Framework), Microsoft has made significant efforts to address the changes and help developers to embark on this new journey by publishing training and educational material at GitHub, YouTube, and on its official website (I will add link below), but for the purpose of helping you, please follow this tutorial, it helped me to learn how to develop Modern Web Parts for SP 2016/Online:
https://dev.office.com/sharepoint/docs/spfx/web-parts/get-started/build-a-hello-world-web-part
3) From the tutorial above, you will get a fully functional Modern Web Part that can be deployed to SP2016/Online, you will see the new modern architecture allows you that old experience of "sandboxing" web parts in a faster way without, thus solving your problem of constant updating/refactoring components in a live production environment. This way now allows you to constantly update the code and see the results in real-time , you will be able to see results on your dev environment by calling: https://localhost:4321/temp/workbench.html and at same time on your SP environment. for example: http://portal.company.com/_layouts/workbench.aspx
Links:
YouTube "SharePoint Framework Tutorials" - it is the step by step tutorial video showing the whole process of creating a web part:
https://www.youtube.com/playlist?list=PLR9nK3mnD-OXvSWvS2zglCzz4iplhVrKq
GitHub repository with the full documentation, samples and extras for the SPFx and PnP (this is another story for another time):
https://github.com/SharePoint
I hope it helps you!

ASP.NET Web API Vs/AND/OR NODE API

I have been working with .NET WEB APIs since long and have learnt NODE APIs a bit.
I love working with Javascript and/or C#.
If I look at .NET WEB API, I really can see that things are already developed and taken care by MICROSOFT.
If I look at NODE APIs, I can (at this stage) understand things are working greatly and growing day by day and may be taken care greatly (but I don't know too much about it).
Now being a software developer(.NET), I can play with .NET WEB APIs as I want as I have pretty much experienced with it. .NET WEB API does almost every thing that I want.
Recently,I came across alasql.js(I think its APIs are written in NODE (not sure)). In order to create an excel , I just have to get the list of objects from .NET WEB API, throw it to client end, at client end I will use single line code and it will generate an excel. (So simple. Same thing is possible in C# .and NET WEB API)...
I know NODE is widely used. but at this stage it seems a different platform to me. I'd like to go on with NODE.
I know its amazing if I could run javascript code onto server with NODE.
I know both are great.
But I'm confused with How and When to use them together, individually?

Which scripting language and web server to use for mulltithreading

I am new to web programming
I need to develop a web page running on a server, that needs to show progress status of 10 threads simultaneously. Also I would require SQLite database integration.
Please tell me what are the options available for me for choosing a scripting language and web server [socket] development framework.
Also suggest the most suitable.
Thanks for any help
Python would be an excellent choice. It has SQLite integrated as documented here.
Python also has the following features (and many others) integrated:
threading and synchronization
Networking (sockets)
lots of web server (and web pages, etc) handling options
Here is a page that discusses several different Python web server frameworks. Im not very familiar with it, but Ive heard lots of good things about Django.
Another excellent choice would be Ruby on Rails. Ruby is the scripting language and Rails is the Web Server Framework.

Resources