Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Web frameworks are transforming from runtime libraries into optimizing compilers

tomdale.net

Post reply on HN
Print view View original

221–230 of 231 posts

Re: Web frameworks are transforming from runtime libraries into optimizing compilers

#221

Post by jules »

hbbio wrote: post #173
sambe wrote: post #105

Earlier quoted context omitted.

I was just thinking about Opa the other day - it looked nice but I never used it. People were worried about debugging through the layers of abstraction. Is it still "alive"? You write in the past tense...

It is not really alive as of now. But there is still space for a full stack language and Opa is relevant today. MLstate, the startup behind Opa, shifted to secure communication platforms (built with Opa) and was acquired last year but without Opa itself. Many things we did became hype later (implemented in OCaml, a functional language, JSX before React - I know Jordan played with Opa before building React) and we sti…

What is present in Opa that is missing in other stacks?

Re: Web frameworks are transforming from runtime libraries into optimizing compilers

#222

Post by jules »

atonse wrote: post #131
grondilu wrote: post #76

The author mentions WebAssembly, yet writes at the end : " and a security model that allows us to forget that we run thousands and thousands of untrusted scripts every day." WebAssembly is designed to run in a sandbox. I suppose that does not by itself make it completely safe, but it can not be much worse than the current situation, can it?

I think WebAssembly has a huge expectations problem: What many people think it is: I can compile my JS frameworks as assembly and ship binaries to the browser, that'll run near-native and be more compact. What WebAssembly actually is: a way to compile libraries from other languages in a manner that you can run them in a JS runtime, but with no access to the DOM, etc. (Think of things like shipping a JS based OCR libr…

WebAssembly is not just about compiling libraries to access them from JS. WebAssembly is about compiling other languages to be able to run on the web with reasonable speed. WebAssembly programs will have access to the DOM.

Re: Web frameworks are transforming from runtime libraries into optimizing compilers

#223

Post by harwoodleon »

Touche wrote: post #109
harwoodleon wrote: post #101

Earlier quoted context omitted.

HTML has a UX/UI standard for iterating documents. Applications however, are not explicitly catered for. HTML standards for web application development are a bit like putting F1 wheels on a bus. For example : a dashboard is a common interface pattern, but this would (and should) probably never enter the Document Object space.

I think you're preoccupied by the word "document". There are many ways that applications are catered for. WebSockets are of no use to documents, only applications, as one example.

Websockets are of use to live documents.

Application stacks are different.

The definition is extremely important as the current level of interaction richness was never really envisaged in 1996.

A document is a resource that is available specifically over http or https. An application is something entirely different as it can be served via a huge array of protocols and terminated and rendered entirely differently.

The separation of concerns here is my need, not the terminology.

For example, how much time have programmers spent globally repeatedly creating and implementing a user login and password reset flow?

This is simply not the concern of the Document Object Model and it means that we have to put up with a huge array of home brewed solutions that each have their own weaknesses. Imagine the same effort and logic applied to routers or tcp/ip for that matter. The internet would simply not work or break.

My point is - there has been a land grab over the UI / UX space that has meant standards like web components are marginalised in favour of 'frameworks' and compilers.

Seems like an awful lot of duplicated effort to reach the same result.

Re: Web frameworks are transforming from runtime libraries into optimizing compilers

#224

Post by posterboy »

ccdev wrote: post #182
kylecordes wrote: post #113

Earlier quoted context omitted.

This seems to be something of a trend in the software library and tool world: A problem emerges. Some early, sharp thinkers create tools which attack the problem in a high level, abstract, powerful way... but also with the rough edges that come with being early. These tools get a few adopters, but not that many because it is difficult to see the value versus the obvious rough edges. Then other sharp thinkers, put off…

As someone who had some amateur experience with C++ roughly 10 years ago I felt it was sort of deja vu with JavaScript. Transpilers, aggressive optimization, automation scripts it's nothing that was too unfamiliar with me. Webpack is roughly a library linker. Babel is like GCC Make. Gruntfile ~= makefile. I think it's coming of age but the JS ecosystem is still undergoing growing pains, plus it can be overwhelming to…

Babel is more like cfront, transpiling from a superset to an older base set of language features. Edit: Maybe you meant to compare it to Macro Pre-Processing, which is often set in makefiles. But it's a shim loader.

Re: Web frameworks are transforming from runtime libraries into optimizing compilers

#225

Post by bpicolo »

leeoniya wrote: post #202
paulddraper wrote: post #171

Earlier quoted context omitted.

I think it's about 2x slower.

they're the same in name only. but not in perf and not in output. https://github.com/Rich-Harris/butternut/issues/35

I don't see where in that issue it says output changes from java to js? Other than the runtime option

Re: Web frameworks are transforming from runtime libraries into optimizing compilers

#226

Post by Twirrim »

wutwutwutwut wrote: post #136
hhjkjhkjhhlkj wrote: post #89

Earlier quoted context omitted.

I had to upgrade my phone because it ran out of internal memory and I had to keep removing apps I valued, as they all grew in size. So bloat cost me real money. Just because you don't care doesn't mean others don't. This is one of my pet peeves. Developers building things on high spec machines with fantastic network connections. Your website is impossible for others to use as it is so slow and cumbersome but the devs…

So you think the world is sad?

No, no one does. Any more than they cast nets to catch wishes, phone their mums every time they step on a crack to make sure that her back is okay etc. etc.

It's an expression, an idiom, even.

Re: Web frameworks are transforming from runtime libraries into optimizing compilers

#227

Post by Ajedi32 »

bsimpson wrote: post #219
nostrademons wrote: post #168

Earlier quoted context omitted.

Somewhat relatedly - when a new technology wave gets started, it's usually proprietary, because there are big competitive advantages that can be had by being the only one with possession of a new technology. As details leak out and enterprising independent hackers get interested, commodity or open-source clones emerge, and they get much wider distribution simply because they're cheap or free . The original innovator…

This is a very strange example. Gmail, Closure, and Traceur are all Google products.

And Closure and Traceur are both open source.

Re: Web frameworks are transforming from runtime libraries into optimizing compilers

#228

Post by kalcode »

iamleppert wrote: post #218
kalcode wrote: post #195

Earlier quoted context omitted.

Any type of UX interaction was always messy and not very scalable using older javascript. Sure it was do-able and libraries like jquery, which have been shown to be slow, made it convient and easy to write it. But ultimately it was messy looking code. Sure using the basic built-in UX like a button that post a form or a site that just had images on it was simple. Once you added interactivity and the web became a lot m…

You know, that UI's aren't very complex? You know what's scalable? PAGES. The entirety of the (www) internet is done with HTML content that link to another HTML content. The entire Internet! What would happen if we made the entire Internet a react application? Would that be "scalable"? Please choose your words more precisely!

I think you are really misunderstanding what vanilla javascript and HTML really is.

No UI in plain HTMl is scalable. If you have a UI each piece of code needs to be repeated on each page. Have a ten page website?

You need your footer, nav and whatever side bar on each page. Copy and pasted. What it changed? You need to change each and every page.

How did we get around this? WAY back we used server-rendered HTML. The server would serve different pieces, partials, to a piece of content.

This was done largely to PREVENT ugly and repeated code. Because making a simple UI in HTML/Javascript stack is overly repetitive and complicated.

No one needed to make server-side rendered pages to solve that issue but it did make maintaining that website easier. Eventually you could use server-side rendered pages to send data that was tailored to a user too.

This same problem happened on the front-end. Both the back-end and front-end started to use templating languages to help with these kind of repeated code.

The reality is a server creating the UI of a program and sending it to a user was OVER utilizing a server. All applications on a machine render and put together their UI. They utilize their power/cpu to construct those. So Web has started to move those templating languages to the front-end.

Some use build chains to create their pages other use SPA to contain it into one page. But the responsibility to construct the repeated components of the UI have become the clients-side for many sites. A server-rendered site is overkill for most these apps.

Things like middleman, jekyll, gatsby exist to do these for you. Create static pages that have repeatable components.

Pretending that none of these tools were created to actually solve a problem seems like you are ignoring what it's like to actually write a plain html/javascript website with any type of functioning UI.

Any form of website where you repeat components or interaction requires copying and pasting every time you edit 1 piece for every page or we use tools or server-side technology or frameworks to eliminate this.

If you wish to code in that style, in that world, or pick and choose what technology framework solves these problems (Rails, PHP) but complain out other frameworks that are front-end(React, Vue) then you seem to be closing your eyes to the full-stack development. Cause back-end programmers ran into these issues and solved them with templating engines themselves and now we are just doing that for front-end to solve the same issue.

Re: Web frameworks are transforming from runtime libraries into optimizing compilers

#229

Post by lallysingh »

hasenj wrote: post #142
lallysingh wrote: post #80

Earlier quoted context omitted.

It wouldn't help. If we spent more engineering effort on efficiencies that don't have a substantive effect on consumer response, we're just being inefficient with our time. That will result in less capable software, higher big counts, or higher software prices. Software is written with budgets, and nothing is free.

How would you like it if a car mechanic left extra garbage in your car because he has no time to clean it and you don't know what's underneath the hood anyway so who cares! It's kind of hard to trust someone with that attitude, don't you think? Yet we waste CPU/RAM/Disk space on consumer's devices without hardly giving it a second thought.

This is more like what if Ford/GM left additional material in the car that didn't need to be there? Those are weight/dynamics/fuel optimizations left on the table.

Re: Web frameworks are transforming from runtime libraries into optimizing compilers

#230

Post by chickenfries »

Animats wrote: post #167

Yet all this is doing so little. It's not like many people are using WebGL and canvases to do interesting graphical things. Mostly they're just messing with scrolling, popping things up, and fading things in and out. All this machinery is way overkill for what it's used for. (Especially messing with scrolling, badly.)

Flipboard built their mobile web app in canvas: http://engineering.flipboard.com/2015/02/mobile-web
Post reply on HN