Live data from Hacker News

A JavaScript-Free Front End

dev.to

71–80 of 215 posts

Re: A JavaScript-Free Front End

#72
post #28

I like the slogan "JavaScript-free"! Finally something to rally around. I don't mind projects which use a tiny bit of hand-coded, vanilla ES6. Would be nice if there were a slogan that included these. Looks like it actually does use JavaScript for the "select2" case. This is exactly the case I'd be happy to special case. edit: added paragraph

http://vanilla-js.com/

It's got a badge and everything.

Re: A JavaScript-Free Front End

#73
post #65

Naive question - but how could you do any interactions (login, add/edit stuff that talks to a server) without using Javascript?

Form posts to the server, just like the old days. Of course, then you need a full page reload every time you edit something.

Not necessarily a full top-level page reload. You can POST to an iframe.

Re: A JavaScript-Free Front End

#74
post #65

Naive question - but how could you do any interactions (login, add/edit stuff that talks to a server) without using Javascript?

Hey, author here.

A lot of things are performed on the server, and then the server responds with a "flash" which is basically a little bar that says "Data saved." or "There was an error: ...".

There are a few places where I used a simple 5-liner to validate a field or something.

Unfortunately there was one place where I needed some heavier JS (for which I used Mithril.js), but it was absolutely required for when you're editing an invoice. You wouldn't want to edit line items and wait for a server response every time you make one change, so I simply determined that this was an area where I had no choice. Mithril simply modifies the DOM inside the element, and then saving is a plain old POST request when you submit the form after you've made all of your changes.

The unfortunate reality is that I couldn't completely free myself from JavaScript, but got a lot closer.

Re: A JavaScript-Free Front End

#75
"Why can't we have a standard search element that filters a list on the client side (similar to how ng-repeat | filter: worked on Angular 1)?"

It's pretty new, but: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/da...

"Wouldn't a standard HTML element for drag-and-drop sorting be awesome?"

There is a standard drag-and-drop API, but unfortunately (bafflingly) it's imperative/event-based, not declarative. Seems like it would be simple for them to add HTML hooks that use the same underlying code.

Re: A JavaScript-Free Front End

#76
Slimvoice - A Webapp Without JavaScript is a series where I document how I rebuilt my app, Slimvoice, using as little JavaScript as possible.

Here's a recurring story in the programming field.

A new variation on technology is highly successful. The field starts using it enthusiastically, but doesn't keep track of the costs and cost/benefit. The new tech gets rather overused. Some people come out with optimizations. (Usually involving what amounts to caching.) Other insightful contrarian people take a minimalist approach. Rinse and repeat.

Once aware, one can spot this cycle happening. It is left as an exercise to the reader, how this can be used to profit.

Re: A JavaScript-Free Front End

#77
post #65

Naive question - but how could you do any interactions (login, add/edit stuff that talks to a server) without using Javascript?

Its generally good practice to start with forms and only start doing fetch requests for things you can demonstrate hamper user experience requiring refreshes.

Re: A JavaScript-Free Front End

#78

Earlier quoted context omitted.

I get the snark, but Java, Rust, Erlang are all better options than an interpreted language for backends IMO

Define better... Scripted languages can be run without the need for a compilation step, if you're scaling horizontally anyway, you can do nearly as well with node, and node can handle 100k+ connections per core with minimalish memory overhead. Functions are first class, functional approaches are easy and flexible, and when you're just passing bytes to another system or database, JS/Node works well. As to interpreted…

Why not C++17 in combination with h2o? I don't know why the compilation step is an issue if compilation and linking takes less than a second which is less time than switching back to the browser. I can pass around lambdas with ease and my lines and functions have become much more succinct with the newer versions especially when dealing with web related stuff. In addition, the https://github.com/nlohmann/json lib make json just work.

No one seems to get that the C++ still works and in nearly all cases is faster, compiles very fast and is very quick to develop with now that everyone has shared their code and since functional algos have been added to the stl. This all happens with the memory safety people require since we have shared and unique pointers and Intel's thread building blocks. My fully featured application is 3.7 MB and takes 12-15 MB of ram to run and handles 100k+ requests per second from my laptop. Those stats aren't even that good with the exception of the rps.

If going fully native isn't your game then how about nginx with the plethora of 3rd party modules that are supplied by other developers? Maybe you just really like js? Maybe js isn't the best but you're going to use it anyway because you know it and other people have already written a lot of your code for you? Maybe you just feel like wasting money on more machines instead of one vps instance and a cache-everything cdn?

You do you I guess.

Re: A JavaScript-Free Front End

#79
post #12

These are handy tricks, even in JS at scale, and I'd recommend their usage if you can (big if, business requirements come first for most of us). That said, I don't really buy into the no JS/purism movement for load/execution speed. For bite-sized apps or simple pages, sure. However, it's completely possible and not that hard to develop full-blown web application suites using full JS for everything (structure, style,…

Seems like once again people just need to pick the right tool for the job. The problem is that people get stuck into one framework and it’s familiar to them so it gets forced into a project it doesn’t make sense for down the road.

Couldn't agree more. Anybody sitting down to start a _serious_ project should spend some time possibly researching and definitely planning, which would hopefully lead to the right decision here.
Post reply on HN