Web "Language" for a Rapid application development

[Kinesis]

Hi Folks,

Been a long time since I stomped around here. I was wondering if anyone could recommend the best web language, free/open source, for producing a rapid prototype application for a demonstration to my senior leaders. The environment I work in is a Windows environment, with no local administrator rights. Now that is a partial limitation, as I could host the prototype on a digital ocean droplet if required.

I have the database, content loaded, created in both sqlite3 and microsoft access.

I am looking for something that I can learn quickly enough to produce a simple webpage with a textbox for data entry, which would be part of the where clause in the query to the database and update the results (on same page) accordingly. Almost identical to how the "search" works here https://hackr.io/. My application would pull product lists back instead of tutorial like this example site.

I was considering flask, as I have python3 with flask installed at work. Just wondered if there was another option.

Thanks in advance for any suggestions.

 

[sdifox]

django and python

 

[Ken g6]

Regardless of the back end, you may find AHAH useful. http://microformats.org/wiki/rest/ahah

 

[purbeast0]

Is this strictly front end? Like you already have the endpoints that you are going to be hitting to pull the data back?

 

[sao123]

this seems like a job for C#/ASP.net WebForms (not MVC) with SQL Express... its plenty fast for prototyping and very easy to learn and get up and functioning fast.

Visual Studio community and SQL Express are both free.

 

[Kinesis]

Is this strictly front end? Like you already have the endpoints that you are going to be hitting to pull the data back?

Strictly front end.

 

[mxnerd]

Not a programmer myself, but always interested in programming topics.

If strictly frontend, then Javascript with vue.js framework, I guess.

Regarding database, I found CouchDB & PouchDB (a CouchDB fork running inside of browser) very interesting.

===

You can even write cross platform Javascript desktop apps with Electron programming.

https://electron.atom.io/

 

[WhiteTiel]

I'm not a programmer either but when my firm needed a platform, guys from a consulting company said that django and python with combination of react is the best. Might look into that. Worked well enough for us.

Edited to avoid potential spam link -- Programming Moderator Ken g6

 

[purbeast0]

Strictly front end.

In that case I'd just pick one of the ones mentioned in here and just go with it. There really is no "right" answer as these frameworks now a days all make it pretty easy.

Personally I'd probably steer clear of React just because it probably has the highest learning curve of the ones mentioned in here. I would just go with something like Bootstrap and that combined with jQuery should get you what you need for rapid prototyping.

 

[Cogman]

I would suggest that whatever you do, try to stick with a javascript frontend library. I wouldn't venture into things like RoR, django, JSPs, Webforms, or whatever. You can often do just about the same job just about as fast with most of these UI libraries.

- Quick and Dirty? Hard to beat a jQuery page.
- More clean and easily expandable? React will handle most of what you want simply and cleanly (and can be easily combined with the likes of jquery).
- More batteries included? I see a lot of positive buzz for vue, but I haven't tried it myself so I can't really vouch for it.
- An "Interesting" combo? Look into clojurescript + react. Lisp + React makes a pretty good combo from what I've heard.

I would STRONGLY suggest that you stay away from Angular. Google's complete revamp of the API with angular 2 was a big slap in the face and not something that you want from a UI library. That level of backwards incompatibility was just insane, who knows what they will do next.

Ember js might be a good thing for a quick prototype, but I don't think I would suggest it for a long lived or large project. Further, it doesn't really play well as an embedded javascript thing.

 

[sao123]

Strictly front end.

I guess I have to question this answer... Strictly Front End says to me, "No Database"
in the OP, it was clearly identified that there was database behind this project.

I have the database, content loaded, created in both sqlite3 and microsoft access.

As soon as backend work needs done, I immediately say C# is the best way to go...
1)It the easiest ways for database calls.
2)Anyone who has an OOP college background (in c++ or Java) has almost all the knowledge they need to get this up and running.
3)Pick a preformatted CSS library such as bootstrap, and this entire project could be done in a few hours, running on IIS with SQL Express.

 

[purbeast0]

I guess I have to question this answer... Strictly Front End says to me, "No Database"
in the OP, it was clearly identified that there was database behind this project.



As soon as backend work needs done, I immediately say C# is the best way to go...
1)It the easiest ways for database calls.
2)Anyone who has an OOP college background (in c++ or Java) has almost all the knowledge they need to get this up and running.
3)Pick a preformatted CSS library such as bootstrap, and this entire project could be done in a few hours, running on IIS with SQL Express.

Based on his response to me, it sounds like he will be making ajax calls to the backend to get the data, so all he has to work on is the front end.

Also your 2nd paragraph is completely subjective and relative to what db/technologies he's using. No language/technology is "the easiest for database calls" in such a generic sense.

Even the term "easiest" is completely subjective. I personally would say node is the "easiest" because you can get a backend running in about 30 seconds and you can make all your calls to a mongodb after setting up like 2 variables, writing mongo queries in javascript. Plus there is no data serialization between front and backend - you're working with JSON on both sides.

 

[purbeast0]

dp

 

[beginner99]

Based on his response to me, it sounds like he will be making ajax calls to the backend to get the data, so all he has to work on is the front end.

I think he doesn't know much about tech talk and the fact he mentioned he has local sqlite3 and ms access tells me he needs db access and there is no backbend in place. Hence he needs one.

I vote c# too and front-end depending on complexity might get away with jquery only.

 

[slugg]

I would suggest that whatever you do, try to stick with a javascript frontend library. I wouldn't venture into things like RoR, django, JSPs, Webforms, or whatever. You can often do just about the same job just about as fast with most of these UI libraries.

- Quick and Dirty? Hard to beat a jQuery page.
- More clean and easily expandable? React will handle most of what you want simply and cleanly (and can be easily combined with the likes of jquery).
- More batteries included? I see a lot of positive buzz for vue, but I haven't tried it myself so I can't really vouch for it.
- An "Interesting" combo? Look into clojurescript + react. Lisp + React makes a pretty good combo from what I've heard.

I would STRONGLY suggest that you stay away from Angular. Google's complete revamp of the API with angular 2 was a big slap in the face and not something that you want from a UI library. That level of backwards incompatibility was just insane, who knows what they will do next.

Ember js might be a good thing for a quick prototype, but I don't think I would suggest it for a long lived or large project. Further, it doesn't really play well as an embedded javascript thing.

As usual, I think Cogman is right... except you SHOULD consider the new Angular. There are a lot of complaints about it due to the massive change in API, but if you're starting new and have nothing to port or unlearn, it's a non issue. So that said, it's actually a very complete tool chain and you can get up and running very quickly.

Vue.JS is an underdog, but I did a prototype in it and I was immediately productive. I liked it quite a bit. Just know that it's less popular, so generally harder to find help.

 

[mxnerd]

Author of vue.js is actually from original Google Angular team. He must have seen some problems so he decided to write his own framework. I read some articles that claimed Angular is designed for Java prgrammers. So although the Angular framework is huge , complex and more complete, probably not suitable for smaller projects.

 

[Cogman]

As usual, I think Cogman is right... except you SHOULD consider the new Angular. There are a lot of complaints about it due to the massive change in API, but if you're starting new and have nothing to port or unlearn, it's a non issue. So that said, it's actually a very complete tool chain and you can get up and running very quickly.

Vue.JS is an underdog, but I did a prototype in it and I was immediately productive. I liked it quite a bit. Just know that it's less popular, so generally harder to find help.

My argument with angular is less about what it can do or how supported it is and more about how what they did with angular 2 was really just the wrong way to maintain an API. Completely and totally upending the API destroyed all my trust in them not doing that again. How do you know that what you write today won't be broken tomorrow because they decide they want to do another massive refactor?

To me, breaking the API in such a massive way is an unforgivable sin. I can understand minor breaking changes, but there is just no excuse to totally and completely break your library. At very least, it should have been a slow and gradual evolution into the current angular form rather than some massive redesign.

 

[slugg]

My argument with angular is less about what it can do or how supported it is and more about how what they did with angular 2 was really just the wrong way to maintain an API. Completely and totally upending the API destroyed all my trust in them not doing that again. How do you know that what you write today won't be broken tomorrow because they decide they want to do another massive refactor?

To me, breaking the API in such a massive way is an unforgivable sin. I can understand minor breaking changes, but there is just no excuse to totally and completely break your library. At very least, it should have been a slow and gradual evolution into the current angular form rather than some massive redesign.

Fair enough. Also good points to consider.